V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  by73  ›  全部回复第 4 页 / 共 7 页
回复总数  140
1  2  3  4  5  6  7  
2019-12-08 23:51:25 +08:00
回复了 zxCoder 创建的主题 Java 关于 Java jni 的问题请教下各位
https://developer.ibm.com/tutorials/j-jni/

这教程很详细,大致就是用 javah 生成对应的头文件,自己实现并编译成库。楼上说的 JNA 似乎也可以,不过我就没用过了。。

另外,C++ 写 Web 也不是不行,大致步骤跟 Java 差不多,操作系统也有 Socket 提供给你,不想重复造轮子也有 Nginx 可以进行扩展,当然前面的选项都比 Java 繁琐多了,C++ 的生态圈太贫瘠了。。
2019-12-02 18:25:11 +08:00
回复了 mrsongopen1 创建的主题 程序员 历经一个多月做了一个博客,请大佬指点
这个主题。。是前一版的 Ghost/Casper 吧 = =
2019-12-02 18:15:49 +08:00
回复了 ml1344677 创建的主题 程序员 请某 211 教授及研究生写的代码 大家品品
学术界向来如此,搞理论的跟搞工程的不一样。。要求学术界代码水平跟工业界持平,难度是等价于要求工业界的理论水平跟学术界持平。就简单来说,大家经常用语言敲代码,但是有谁能认认真真学下去 PL 的?

扯点题外话,我有幸参观过学校 OJ 的源码,那才叫一个“辣眼”,听闻都是每年找几个毕业生(本科)给这个系统缝缝补补,就当毕设了。一群跟我一样没真正耕过田的去耕田,结果多数就是像楼主贴的这种代码一样。

嘛,上级交给你的工作还是要完成的,大家都是为了一口饭。。
看了半天,是希望获得函数实参的名称? emm 似乎不行,Reflection API 能得到变量名称的似乎只有 `Field` 和 `Parameter`,而且 Parameter 的名称多数都会被编译器优化掉,而而且 `Object... vars` 这个是当作一个 Parameter,而而而且 Java 传参是值传递,完全无法从形参得知实参的元信息。。
2019-11-28 12:35:51 +08:00
回复了 cmlanche 创建的主题 程序员 爱了, 又一个个人博客系统 halo,关键还是 springboot 搞的
杀。。杀鸡用牛刀。。

SpringBoot 其实也不是不行,但是附带的东西太多了,这作者打完整个 FatJar 之后变成了 60 MB。。
2019-11-27 09:03:11 +08:00
回复了 RYYang 创建的主题 程序员 我觉得当程序员有点累
996.icu 再看看现在,令人唏嘘,哎
2019-11-25 17:18:05 +08:00
回复了 codepm 创建的主题 程序员 对未来的语言趋势是怎样看的? Python 、Go、NodeJS
现在讨论这个没有太大意义,Java 为啥“流行”?因为库和屎坑。目前转 Go 等新语言的公司,多数都是从头开干的,但这些公司有多少?前面也有人提到性能问题,说实话,不是每个厂性能都要像淘宝阿里一样百万并发,所以语言带来的性能问题其实微乎其微。

所以将来比较长一段时间,只要屎坑没被清理完毕,那么 Java 依然会保持很大优势。并且清理屎坑这种事情需要大公司花费长时间的人力和物力去做,在 Java 还可堪一用的情况下暂时不太可能出现太大转机,非要预测的话,服务端 Go 可能会更好一些,毕竟背后有一个帝国撑腰,现在新项目趋势比较明显。

(这个问题其实感觉和之前的“为什么 CentOS 仍然是主流”有点类似,都是历史包袱太严重,似乎很多问题都可以归结于历史原因?)
@amiwrong123 嘛,这样的话就会跟 lastRet 的定义( Index of element returned by most recent call to next or previous )以及 remove 的定义( Removes from the list the last element that was returned by next or previous )相违背。

我个人觉得这其实更多的是一个设计上的考虑,也不是啥致命的问题,可能当时有考虑到如 `add(); remove();` 这种二义性问题(该删除最近添加的那个还是 next/previous 的那个,你的问题中直接删除这个方案就是后者,回复中提供的代码就是前者),索性直接搞个 IllegalStateException 规避这种状态的发生。
@amiwrong123 emm 我指的影响是对当前状态的影响(因为你问的是 lastRet ),“add 会影响 previous” 指的是 `previous(); add();` 在执行完 add 之后前面 previous 产生的 lastRet 就无效了。就是说在你**首先**执行完 previous 后,lastRet 指向了返回的值,之后你执行 add 往数组前面插值,那么 lastRet 指向的还是原来返回的值而非刚插入的那个,这是我所说的 lastRet 失效。next 和 remove 同理。

add 之后执行 previous/next 当然都没问题啦,你图片里的 cursor 挺明确的了。
2019-11-23 17:28:29 +08:00
回复了 fhyuncai 创建的主题 Linux iptables 如何在内网转发包时转发源 ip
这个似乎是动态的 NAT ?一般来说 NAT 都会直接修改报文的源 IP 地址和端口的。。可能你要换种方式吧
其实嘛,考虑下如果去掉后,`next/previous(); add(); set/remove();` 到底会是怎样的结果。总的来说,因为 remove/add 之后都会改变整个迭代器的状态,导致 lastRet 失效(就是原来调用的 next 或者 previous 不再能指向正确的结果了,remove 会影响 next,而 add 会影响 previous )
2019-11-23 14:19:48 +08:00
回复了 imbushuo 创建的主题 分享创造 在计算器上跑 Windows
很强,原来现在的图形计算器都上 ARM 了!想起来以前我那部 TI84 慢的想打人。。
2019-11-23 12:37:32 +08:00
回复了 Hanggi 创建的主题 程序员 百度盘为什么不光明正大地承认自己限速呢?
冲会员可以,我不能忍受的是百度那个辣鸡客户端,开了会员还非要去下一个客户端才能完整体验全部功能,相对于忍受百度客户端的“流氓”性,我宁愿多花点时间研究“白嫖”。。
@iXingo 对,本质上就是让另一个线程去处理。至少 java.nio.channels 是这样做的,如果你带了一个回调函数,那么

> The completion handler for an I/O operation initiated on a channel bound to a group is guaranteed to be invoked by one of the pooled threads in the group.

(摘自 JavaDoc ),就是说你的回调函数会在 I/O 结束之后被异步处理的线程调用。
@by73 噢对了,Java/Netty 的 NIO 指的是 New I/O,具体而言指的是异步 I/O,而不是 Non-blocking,因为 I/O 阻塞的话语权不在它们那。
我所知道的(碍于知识水平可能有误),阻塞与非阻塞是针对 I/O 传输到内存这部分而言,阻塞 I/O 在传输时全程需要 CPU 干预;非阻塞 I/O 在传输时 CPU 可以干别的事,直到像 DMA 这样的控制器给 CPU 发个完成的中断,再调用到操作系统的中断处理程序。

而同步和异步则是针对进程 /线程而言的,假如调用 Files.readAllLines(),那么当前线程就会处于挂起状态,直到上面的阻塞 /非阻塞 I/O 把数据传递到内存之后才被恢复,这个过程其实对 CPU 没有影响,只是对你的线程有影响;异步就是当前线程不再等待 I/O 传输的完成,只是发起一个 I/O 请求和请求完之后要做的事情,然后交给另一个线程去负责(这样阻塞也就只会阻塞另外那个线程,不会影响当前线程的执行)。异步本质上可以理解为多线程。

所以综上,回答题主的问题,非阻塞 I/O 提升的时间主要是数据传输到内存的这段 CPU 时间,这样 CPU 就能处理其他的进程;另外,异步 I/O 的价值在于“小而多”的请求,典型例子就是 HTTP,因为 I/O 特别多,如果每个线程都要去等待这些 I/O 完成,肯定会浪费其他非 I/O 的时间,将这些 I/O 交给另一个线程,自己就“解放了”;而对于 I/O 密集的任务来说,异步 I/O 没啥大优势,当 I/O 占很大一部分时,非 I/O 部分的运行时间就可以忽略了,基本上都是在排队阻塞、传输、调回调函数,整个系统的并发度也就降到了跟同步差不多的水平(大家都是在等 I/O )。

(注意这里的所有解释都是针对 I/O 传输的过程,因为等待 I/O 到来这件事必须要等待,像 Socket.accept() 或者 listen() 都是要强行阻塞的)

(熬夜过程可能脑子不太清醒,见谅,也希望能指出错误)
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3167 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 12:52 · PVG 20:52 · LAX 04:52 · JFK 07:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.