# re: Java NIO trick and trap——編寫高性能NIO網(wǎng)絡(luò)框架 回復(fù) 更多評論
2010-11-22 18:25 by
好東西,學(xué)習(xí)學(xué)習(xí),謝謝.
# re: Java NIO trick and trap 回復(fù) 更多評論
2010-11-24 16:32 by
首先感謝大俠分享。粗略看了一遍，有兩個問題要請教一下：
1）Reactor數(shù)目 一節(jié)中提到 Netty 的 Reactor 數(shù)目為：1 + 2 * CPU，但是我從 Netty 代碼中找不到相關(guān)的論證，或許是我搞錯了，希望作者能幫我核實一下；
2）SO_TCPNODELAY 選項開啟之后，小的數(shù)據(jù)會延遲發(fā)送，導(dǎo)致網(wǎng)絡(luò)數(shù)據(jù)傳輸延時特別大，我在開發(fā)中得到的延時是 40 ms，我一度以為是 JDK 的 bug，我在網(wǎng)上也看到有人反映這個問題，如果作者覺得有必要可以把這個也列為一個 TRAP。
# re: Java NIO trick and trap 回復(fù) 更多評論
2010-11-24 18:38 by
@simaliu
1、查看NioServerSocketChannelFactory類的構(gòu)造函數(shù)，SelectorUtil.DEFAULT_IO_THREADS常量。
2、這個我不認為是nio的trap，而是網(wǎng)絡(luò)編程需要注意的問題，感謝你的分享。
# re: Java NIO trick and trap 回復(fù) 更多評論
2010-11-25 10:13 by
@simaliu
1 + 2 * CPU
這個參數(shù)在garbage里面非常常用。呵呵
# re: Java NIO trick and trap 回復(fù) 更多評論
2011-06-29 10:51 by
我是初學(xué)java nio的，有個問題請教一下lz
在減少wakeup調(diào)用那一章，也就是35頁
為了性能考慮，當queue為空時，為什么把要寫入的數(shù)據(jù)加入到queue中，而不是直接write？？如果write不完在考慮加入到queue中，然后注冊事件，最后wakeup
通常情況下write是寫入到tcp的緩沖區(qū)，那一塊好歹有個4-8k（根據(jù)不同的操作系統(tǒng)設(shè)置可能會有不同），通常是能成功的
以上實際是我在做c開發(fā)時候的一點經(jīng)驗，不知道轉(zhuǎn)移到j(luò)ava之后是否繼續(xù)有價值，肯定lz斧正，感謝。
# re: Java NIO trick and trap 回復(fù) 更多評論
2011-12-13 18:57 by
這篇ppt太好了，我這段時間一直在看xmemcached.yan4j的代碼，正在為有些細節(jié)頭疼，這份ppt剛好把我的疑問解決了，例如：
1、為什么新寫B(tài)uffer實現(xiàn)
2、AtomicBoolean wakeup來減少Selector.wakeup調(diào)用（弱弱的問，Selector.wakeup如果多次調(diào)用，只有一次起作用，底層實現(xiàn)有個boolean變量來做記錄操作狀態(tài)，代碼中AtomicBoolean wakeup也是用作記錄操作狀態(tài)，會不會多余？）
3、注冊Channel和更新interest 通過if(isReactorThread())來決定是否放入隊列的原因
4、各種socket參數(shù)的優(yōu)化
5、網(wǎng)絡(luò)延遲狀態(tài)下通過臨時Selector寫數(shù)據(jù)(grizzly)的方式
……
# re: Java NIO trick and trap 回復(fù) 更多評論
2011-12-13 18:59 by
樓主的大量細節(jié)優(yōu)化是yanf4j與mina比對測試勝出的根本原因吧，多謝你的分析
# re: Java NIO trick and trap 回復(fù) 更多評論
2014-01-07 16:35 by
自己本來想給團隊分享一下nio的，看了dennis的ppt后，發(fā)現(xiàn)自己準備的太淺了。