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