1. 從一次線上故障說(shuō)起為什么我要回頭啃Netty的NIO底座前兩年我接手過(guò)一個(gè)即時(shí)通訊服務(wù)的性能優(yōu)化項(xiàng)目單機(jī)壓測(cè)的時(shí)候QPS死活上不去CPU占用率卻高得離譜。當(dāng)時(shí)第一反應(yīng)是業(yè)務(wù)代碼寫得有問(wèn)題排查了一圈發(fā)現(xiàn)線程池配置、鎖競(jìng)爭(zhēng)、序列化都沒(méi)毛病。最后用火焰圖一照大量時(shí)間耗在了傳統(tǒng)阻塞IO的線程上下文切換上。那一刻我才真正意識(shí)到很多人用Netty只是停留在“會(huì)調(diào)API”的層面對(duì)底層的Buffer、Channel、Selector這三件套的理解其實(shí)是模糊的。而恰恰是這三個(gè)組件決定了Netty為什么能扛住高并發(fā)。這篇文章我想把Netty的NIO核心組件徹底講透。不是那種照著源碼念一遍的講法而是結(jié)合我自己踩過(guò)的坑、調(diào)過(guò)的參數(shù)、看過(guò)的線上數(shù)據(jù)把Buffer、Channel、Selector這三個(gè)東西的來(lái)龍去脈、設(shè)計(jì)取舍、實(shí)操要點(diǎn)全部攤開(kāi)。適合已經(jīng)用過(guò)Netty但對(duì)底層一知半解的開(kāi)發(fā)者也適合剛接觸NIO、想搞清楚“為什么不用傳統(tǒng)IO”的朋友。讀完你至少能做到知道每個(gè)組件解決什么問(wèn)題、參數(shù)怎么調(diào)、坑在哪里、出問(wèn)題怎么排查。2. NIO三件套的整體設(shè)計(jì)思路拆解2.1 為什么傳統(tǒng)BIO在高并發(fā)場(chǎng)景下必然吃力要理解NIO的價(jià)值得先看清楚BIO的問(wèn)題在哪。傳統(tǒng)阻塞IO的模型是一個(gè)線程對(duì)應(yīng)一個(gè)連接read操作沒(méi)數(shù)據(jù)就卡在那里等accept沒(méi)新連接也卡著等。這個(gè)模型在連接數(shù)少的時(shí)候很直觀代碼也好寫。但連接數(shù)一上來(lái)比如同時(shí)維持幾千個(gè)連接你就得開(kāi)幾千個(gè)線程。每個(gè)線程占1MB左右的?？臻g光內(nèi)存就吃掉幾個(gè)G更別說(shuō)線程切換的開(kāi)銷了。我實(shí)測(cè)過(guò)一個(gè)簡(jiǎn)單的Echo服務(wù)BIO模型在500并發(fā)連接時(shí)上下文切換次數(shù)每秒能到幾萬(wàn)次CPU的sy系統(tǒng)態(tài)占比超過(guò)40%。這就是典型的“線程比活還多”的浪費(fèi)。NIO的核心思路是把“等待”這件事從線程身上剝離出來(lái)交給操作系統(tǒng)的一個(gè)機(jī)制去統(tǒng)一管理這個(gè)機(jī)制就是IO多路復(fù)用而Selector就是Java層面對(duì)它的封裝。2.2 Buffer、Channel、Selector三者的協(xié)作關(guān)系這三個(gè)組件不是孤立的它們構(gòu)成了一個(gè)完整的數(shù)據(jù)流轉(zhuǎn)閉環(huán)。我用一個(gè)生活化的類比來(lái)解釋把Channel想象成一條快遞管道數(shù)據(jù)是包裹Buffer是你家門口的快遞柜包裹必須先放進(jìn)柜子你才能取Selector則是小區(qū)門口的保安他同時(shí)盯著幾百條管道哪條管道有包裹到了就通知你去對(duì)應(yīng)的柜子取。具體到數(shù)據(jù)流客戶端發(fā)來(lái)的數(shù)據(jù)操作系統(tǒng)先讀到內(nèi)核緩沖區(qū)然后通過(guò)Channel“搬運(yùn)”到用戶態(tài)的Buffer里你從Buffer里讀數(shù)據(jù)做業(yè)務(wù)處理。反過(guò)來(lái)寫數(shù)據(jù)時(shí)你把數(shù)據(jù)寫進(jìn)Buffer再通過(guò)Channel刷出去。Selector的作用是讓你一個(gè)線程就能監(jiān)控多個(gè)Channel的就緒狀態(tài)不用為每個(gè)Channel開(kāi)一個(gè)線程去死等。這個(gè)協(xié)作關(guān)系是理解整個(gè)NIO的鑰匙后面所有的細(xì)節(jié)都是圍繞它展開(kāi)的。2.3 Netty在這三者之上做了什么增強(qiáng)原生JDK的NIO API其實(shí)挺難用的Buffer的flip、rewind、clear這幾個(gè)方法經(jīng)常把人繞暈Selector的空輪詢bug也是出了名的。Netty沒(méi)有直接用JDK的ByteBuffer而是自己實(shí)現(xiàn)了ByteBuf把讀寫指針?lè)蛛x讀的時(shí)候不用flip寫的時(shí)候自動(dòng)擴(kuò)容還支持池化復(fù)用。Channel方面Netty抽象出了ChannelPipeline和ChannelHandler把數(shù)據(jù)流轉(zhuǎn)變成了一條責(zé)任鏈。Selector這塊Netty用EventLoop把Selector的輪詢和任務(wù)執(zhí)行整合在一起還通過(guò)反射替換了Selector的實(shí)現(xiàn)來(lái)規(guī)避空輪詢問(wèn)題。所以學(xué)Netty的NIO組件我的建議是分兩層看先搞懂JDK原生NIO的Buffer、Channel、Selector各自是什么、怎么用再看Netty在它們基礎(chǔ)上做了哪些封裝和優(yōu)化。跳過(guò)第一層直接看Netty很多設(shè)計(jì)你會(huì)覺(jué)得莫名其妙只停留在第一層又用不好Netty。下面我按這個(gè)思路逐個(gè)拆。3. Buffer詳解數(shù)據(jù)的中轉(zhuǎn)站到底怎么用3.1 Buffer的核心屬性與讀寫模式切換Buffer本質(zhì)上就是一塊內(nèi)存區(qū)域但它比普通數(shù)組多了幾個(gè)關(guān)鍵屬性capacity容量、position當(dāng)前位置、limit限制位、mark標(biāo)記位。這四個(gè)屬性的組合決定了Buffer當(dāng)前處于什么狀態(tài)。capacity是固定的創(chuàng)建時(shí)就定死了position表示下一個(gè)要讀或?qū)懙奈恢胠imit表示讀或?qū)懙倪吔鏼ark是臨時(shí)記錄position用的。新手最容易懵的是讀寫模式的切換。你往Buffer里寫數(shù)據(jù)時(shí)position不斷后移limit等于capacity。寫完之后要讀必須調(diào)用flip()這個(gè)方法把limit設(shè)為當(dāng)前position然后把position歸零。讀完數(shù)據(jù)要重新寫調(diào)用clear()position歸零limit恢復(fù)為capacity。如果只讀了一部分想重讀用rewind()position歸零但limit不動(dòng)。我見(jiàn)過(guò)太多人因?yàn)橥薴lip導(dǎo)致讀不到數(shù)據(jù)或者讀完之后沒(méi)clear導(dǎo)致下次寫入位置錯(cuò)亂。記住一個(gè)口訣寫轉(zhuǎn)讀用flip讀完重寫用clear重讀一遍用rewind。這三個(gè)方法搞清楚了Buffer就掌握了一半。3.2 堆內(nèi)內(nèi)存與堆外內(nèi)存的選擇邏輯ByteBuffer.allocate()分配的是堆內(nèi)內(nèi)存allocateDirect()分配的是堆外內(nèi)存。這兩者的區(qū)別不是紙面上的概念而是直接影響性能的。堆內(nèi)內(nèi)存的讀寫就是操作Java對(duì)象速度快但要做IO操作時(shí)JVM需要把數(shù)據(jù)從堆內(nèi)拷貝到堆外多了一次拷貝。堆外內(nèi)存可以直接被操作系統(tǒng)訪問(wèn)省掉了這次拷貝但分配和回收的成本高而且不受JVM堆管理用不好容易內(nèi)存泄漏。我的經(jīng)驗(yàn)是頻繁創(chuàng)建銷毀的小Buffer用堆內(nèi)長(zhǎng)期復(fù)用的大Buffer用堆外。Netty默認(rèn)用PooledByteBufAllocator底層就是池化的堆外內(nèi)存通過(guò)內(nèi)存池復(fù)用來(lái)抵消分配成本。如果你自己寫NIO代碼建議對(duì)大的、生命周期長(zhǎng)的Buffer用DirectByteBuffer并且一定要手動(dòng)復(fù)用不要每次new。注意DirectByteBuffer的回收依賴GC如果分配速度超過(guò)回收速度會(huì)觸發(fā)Full GC嚴(yán)重時(shí)直接OOM。生產(chǎn)環(huán)境一定要限制堆外內(nèi)存大小通過(guò)-XX:MaxDirectMemorySize參數(shù)控制。3.3 Netty ByteBuf的讀寫指針?lè)蛛x設(shè)計(jì)Netty的ByteBuf把讀指針和寫指針?lè)珠_(kāi)了readerIndex和writerIndex各管各的讀的時(shí)候不用flip寫的時(shí)候也不用clear。這個(gè)設(shè)計(jì)看起來(lái)只是省了幾個(gè)方法調(diào)用實(shí)際上解決了一個(gè)大問(wèn)題讀寫可以交錯(cuò)進(jìn)行不需要頻繁切換模式。比如你在解碼一個(gè)協(xié)議包的時(shí)候可能需要先讀頭部判斷長(zhǎng)度再讀body中間還可能回退幾個(gè)字節(jié)重新讀用JDK的ByteBuffer做這些操作會(huì)非常別扭。ByteBuf還支持動(dòng)態(tài)擴(kuò)容寫滿了自動(dòng)擴(kuò)默認(rèn)最大到Integer.MAX_VALUE。它還提供了slice()、duplicate()、retainedSlice()等零拷貝的視圖方法可以在不復(fù)制數(shù)據(jù)的情況下操作部分內(nèi)容。這些特性讓Netty在處理粘包拆包、協(xié)議解析時(shí)非常順手。3.4 Buffer使用中的常見(jiàn)陷阱與實(shí)操建議第一個(gè)坑是忘記考慮字節(jié)序。JDK的ByteBuffer默認(rèn)是大端序Big EndianNetty的ByteBuf默認(rèn)也是大端。但有些協(xié)議用的是小端序讀出來(lái)的數(shù)字會(huì)完全不對(duì)。解決辦法是顯式調(diào)用order(ByteOrder.LITTLE_ENDIAN)切換。第二個(gè)坑是Buffer復(fù)用時(shí)的狀態(tài)殘留。如果你把Buffer放進(jìn)對(duì)象池復(fù)用下次取出來(lái)之前一定要clear()或者至少把position和limit重置否則殘留的mark或者limit會(huì)導(dǎo)致詭異的問(wèn)題。我遇到過(guò)一次線上事故就是因?yàn)閺?fù)用的Buffer沒(méi)有重置mark導(dǎo)致某次讀取時(shí)回退到了錯(cuò)誤的位置解析出來(lái)的數(shù)據(jù)錯(cuò)位。第三個(gè)坑是DirectBuffer的監(jiān)控。堆外內(nèi)存不歸JVM堆管常規(guī)的堆監(jiān)控看不到。建議用Netty自帶的PlatformDependent工具類或者JMX來(lái)監(jiān)控堆外內(nèi)存使用量設(shè)置合理的告警閾值。4. Channel詳解數(shù)據(jù)通道的抽象與實(shí)現(xiàn)4.1 Channel的核心接口與生命周期Channel在NIO里代表一個(gè)連接可以是網(wǎng)絡(luò)連接的SocketChannel也可以是文件操作的FileChannel。它的核心方法就幾個(gè)read(ByteBuffer)、write(ByteBuffer)、close()、isOpen()。但就是這幾個(gè)方法配合Selector使用的時(shí)候有很多講究。Channel有四種狀態(tài)open、connected、closed、registered。open表示通道創(chuàng)建了connected表示連接建立了對(duì)SocketChannel而言closed表示關(guān)閉了registered表示注冊(cè)到了某個(gè)Selector上。這四個(gè)狀態(tài)的轉(zhuǎn)換順序和時(shí)機(jī)直接決定了你的事件處理邏輯是否正確。比如你收到一個(gè)read事件但Channel可能已經(jīng)處于半關(guān)閉狀態(tài)了這時(shí)候讀操作會(huì)返回-1你得正確處理這個(gè)返回值不能當(dāng)成正常數(shù)據(jù)。4.2 ServerSocketChannel與SocketChannel的分工服務(wù)端啟動(dòng)的時(shí)候先創(chuàng)建一個(gè)ServerSocketChannel綁定端口注冊(cè)到Selector上監(jiān)聽(tīng)ACCEPT事件。當(dāng)有客戶端連接進(jìn)來(lái)accept()方法返回一個(gè)SocketChannel這個(gè)SocketChannel代表和這個(gè)客戶端的連接再把它注冊(cè)到Selector上監(jiān)聽(tīng)READ事件。之后這個(gè)連接上的數(shù)據(jù)讀寫都通過(guò)這個(gè)SocketChannel進(jìn)行。這里有個(gè)容易忽略的點(diǎn)accept返回的SocketChannel默認(rèn)是阻塞的必須顯式調(diào)用configureBlocking(false)設(shè)為非阻塞否則注冊(cè)到Selector上會(huì)直接拋異常。我見(jiàn)過(guò)好幾個(gè)新手卡在這里報(bào)錯(cuò)信息又不直觀排查半天。另外ServerSocketChannel可以同時(shí)注冊(cè)到多個(gè)Selector上嗎答案是可以但一般沒(méi)必要。一個(gè)Selector負(fù)責(zé)accept多個(gè)Selector負(fù)責(zé)讀寫這是主從Reactor模式的基礎(chǔ)Netty的bossGroup和workerGroup就是這么分工的。4.3 Channel的注冊(cè)機(jī)制與SelectionKeyChannel注冊(cè)到Selector上會(huì)返回一個(gè)SelectionKey這個(gè)Key是Channel和Selector之間的紐帶。Key上可以附加一個(gè)Attachment對(duì)象通常用來(lái)存這個(gè)Channel對(duì)應(yīng)的會(huì)話狀態(tài)、緩沖區(qū)等。Netty里就是把Channel本身作為Attachment存進(jìn)去這樣事件觸發(fā)時(shí)能直接拿到Channel。SelectionKey有四個(gè)常量表示感興趣的事件OP_READ、OP_WRITE、OP_CONNECT、OP_ACCEPT。你可以用位運(yùn)算組合多個(gè)事件。比如key.interestOps(SelectionKey.OP_READ | SelectionKey.OP_WRITE)。但要注意OP_WRITE大多數(shù)時(shí)候都是就緒的因?yàn)橹灰l(fā)送緩沖區(qū)有空位就可以寫。如果你一直注冊(cè)著OP_WRITESelector會(huì)一直返回這個(gè)事件導(dǎo)致CPU空轉(zhuǎn)。正確的做法是需要寫的時(shí)候才注冊(cè)O(shè)P_WRITE寫完立刻取消。4.4 Netty Channel的增強(qiáng)Pipeline與Handler機(jī)制Netty的Channel比JDK的Channel復(fù)雜得多它內(nèi)部綁定了一條ChannelPipelinePipeline上掛了一串ChannelHandler。數(shù)據(jù)進(jìn)來(lái)先經(jīng)過(guò)入站Handler鏈出去經(jīng)過(guò)出站Handler鏈。這個(gè)設(shè)計(jì)把網(wǎng)絡(luò)層的字節(jié)流處理和業(yè)務(wù)層的邏輯處理徹底解耦了。舉個(gè)例子一個(gè)典型的服務(wù)端Pipeline可能是這樣的ByteToMessageDecoder把字節(jié)流解碼成消息對(duì)象- IdleStateHandler檢測(cè)空閑連接- 業(yè)務(wù)Handler處理具體請(qǐng)求。每個(gè)Handler只關(guān)心自己的事職責(zé)單一組合靈活。這種設(shè)計(jì)比在JDK NIO里寫一個(gè)大大的if-else要優(yōu)雅得多也更容易維護(hù)和測(cè)試。4.5 Channel使用中的性能考量與注意事項(xiàng)第一個(gè)注意點(diǎn)是Channel的關(guān)閉要優(yōu)雅。直接close()可能會(huì)導(dǎo)致發(fā)送緩沖區(qū)里的數(shù)據(jù)丟失。正確的做法是先shutdownOutput()等對(duì)方讀完再關(guān)閉。Netty提供了ChannelFuture和closeFuture來(lái)支持異步關(guān)閉可以注冊(cè)監(jiān)聽(tīng)器在關(guān)閉完成后做清理。第二個(gè)注意點(diǎn)是寫操作的背壓?jiǎn)栴}。如果對(duì)方接收慢你的發(fā)送緩沖區(qū)會(huì)堆積最終導(dǎo)致OOM。Netty通過(guò)Channel.isWritable()和寫緩沖區(qū)水位線WRITE_BUFFER_WATER_MARK來(lái)感知背壓你可以在寫之前判斷isWritable不可寫的時(shí)候暫停發(fā)送等channelWritabilityChanged回調(diào)再繼續(xù)。第三個(gè)注意點(diǎn)是Channel是線程安全的嗎JDK的SocketChannel本身不是線程安全的多個(gè)線程同時(shí)讀寫會(huì)出問(wèn)題。Netty的Channel通過(guò)EventLoop保證了所有IO操作都在同一個(gè)線程上執(zhí)行所以你不需要加鎖但也不能在Handler里做耗時(shí)操作否則會(huì)阻塞整個(gè)EventLoop上的其他Channel。5. Selector詳解多路復(fù)用的核心引擎5.1 Selector的工作原理與IO多路復(fù)用模型Selector的本質(zhì)是操作系統(tǒng)提供的IO多路復(fù)用機(jī)制的Java封裝。在Linux上底層是epoll在Windows上是IOCP的模擬在Mac上是kqueue。它的工作方式是你把多個(gè)Channel注冊(cè)到Selector上然后調(diào)用select()方法這個(gè)方法會(huì)阻塞直到至少有一個(gè)Channel就緒或者超時(shí)或者被喚醒。返回后你遍歷selectedKeys()拿到就緒的Channel逐個(gè)處理。這個(gè)模型的核心優(yōu)勢(shì)是一個(gè)線程管理多個(gè)連接。假設(shè)你有10000個(gè)連接但同一時(shí)刻只有100個(gè)有數(shù)據(jù)可讀那么用Selector的話一個(gè)線程輪詢一次就能找到這100個(gè)處理完繼續(xù)輪詢。而B(niǎo)IO模型下10000個(gè)線程都在阻塞等待只有100個(gè)有活干其余9900個(gè)都在浪費(fèi)資源。5.2 select、poll、epoll的差異與選擇這三個(gè)是Linux下IO多路復(fù)用的三種實(shí)現(xiàn)。select和poll的區(qū)別不大都是把文件描述符集合從用戶態(tài)拷貝到內(nèi)核態(tài)然后內(nèi)核遍歷檢查。它們的瓶頸在于文件描述符數(shù)量有限制select默認(rèn)1024每次調(diào)用都要全量拷貝和遍歷連接數(shù)多了性能急劇下降。epoll解決了這些問(wèn)題它用紅黑樹(shù)管理文件描述符不需要每次全量拷貝用就緒鏈表存儲(chǔ)就緒的事件不需要全量遍歷沒(méi)有文件描述符數(shù)量限制。所以高并發(fā)場(chǎng)景下epoll是絕對(duì)的首選。JDK在Linux上默認(rèn)就是用epoll你可以通過(guò)-Djava.nio.channels.spi.SelectorProvider參數(shù)查看或指定。5.3 Selector的空輪詢問(wèn)題與Netty的解決方案JDK的Selector有一個(gè)著名的空輪詢bug在某些情況下select()方法會(huì)立即返回但selectedKeys()是空的沒(méi)有任何就緒的Channel。如果代碼里沒(méi)有正確處理這種情況就會(huì)陷入死循環(huán)CPU直接飆到100%。這個(gè)bug在JDK 6u4到JDK 7u4之間比較嚴(yán)重后來(lái)雖然修了但在某些內(nèi)核版本和特定場(chǎng)景下仍會(huì)出現(xiàn)。Netty的解決方案很巧妙它在NioEventLoop里記錄了select操作的次數(shù)和耗時(shí)如果發(fā)現(xiàn)連續(xù)多次select都立即返回且沒(méi)有就緒事件就認(rèn)為觸發(fā)了空輪詢?nèi)缓笾亟⊿elector把原來(lái)注冊(cè)的Channel全部遷移到新的Selector上。這個(gè)邏輯在select()方法的循環(huán)里通過(guò)一個(gè)selectCnt計(jì)數(shù)器來(lái)控制。閾值默認(rèn)是512次可以通過(guò)系統(tǒng)屬性調(diào)整。5.4 Selector的喚醒機(jī)制與wakeup的坑Selector.select()是阻塞的有時(shí)候你需要從其他線程喚醒它比如有新任務(wù)要提交到EventLoop上執(zhí)行。這時(shí)候調(diào)用selector.wakeup()就能讓select()立即返回。但wakeup()有個(gè)坑如果調(diào)用wakeup()的時(shí)候select()并沒(méi)有在阻塞那么下一次select()會(huì)立即返回一次相當(dāng)于“消費(fèi)”掉了這次喚醒。這會(huì)導(dǎo)致一次無(wú)意義的空輪詢。Netty處理這個(gè)問(wèn)題的方式是在wakeup之后設(shè)置一個(gè)標(biāo)記下次select之前檢查這個(gè)標(biāo)記如果發(fā)現(xiàn)是多余的喚醒就跳過(guò)。這個(gè)細(xì)節(jié)在寫自定義NIO框架的時(shí)候很容易忽略導(dǎo)致CPU空轉(zhuǎn)。5.5 Selector的實(shí)操配置與調(diào)優(yōu)建議第一個(gè)建議是合理設(shè)置select的超時(shí)時(shí)間。如果設(shè)成0就是無(wú)限阻塞直到有事件才返回。如果設(shè)成正數(shù)就是最多阻塞那么久。Netty默認(rèn)用1秒的超時(shí)這樣即使沒(méi)有IO事件也能定期醒來(lái)處理定時(shí)任務(wù)和系統(tǒng)任務(wù)。如果你自己寫建議設(shè)一個(gè)合理的超時(shí)不要用0。第二個(gè)建議是selectedKeys()的清理。每次處理完一個(gè)Key必須調(diào)用iterator.remove()否則這個(gè)Key會(huì)一直留在集合里下次select返回時(shí)還會(huì)被處理。這個(gè)錯(cuò)誤非常常見(jiàn)表現(xiàn)就是同一個(gè)事件被反復(fù)處理。第三個(gè)建議是Selector的關(guān)閉。程序退出或者重建Selector時(shí)要遍歷所有注冊(cè)的Key取消注冊(cè)并關(guān)閉對(duì)應(yīng)的Channel最后再關(guān)閉Selector本身。否則會(huì)留下文件描述符泄漏。6. 三件套協(xié)同工作的完整實(shí)操流程6.1 服務(wù)端啟動(dòng)的完整代碼骨架下面這段代碼是我自己寫的一個(gè)最小NIO服務(wù)端骨架去掉了業(yè)務(wù)邏輯只保留三件套的協(xié)作流程。你可以直接拿去改。public class NioServer { public static void main(String[] args) throws IOException { // 1. 創(chuàng)建Selector Selector selector Selector.open(); // 2. 創(chuàng)建ServerSocketChannel并配置非阻塞 ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.bind(new InetSocketAddress(8080)); // 3. 注冊(cè)ACCEPT事件 serverChannel.register(selector, SelectionKey.OP_ACCEPT); // 4. 創(chuàng)建Buffer用于讀寫 ByteBuffer readBuffer ByteBuffer.allocateDirect(1024); while (true) { // 5. 阻塞等待就緒事件超時(shí)1秒 int readyCount selector.select(1000); if (readyCount 0) { continue; } // 6. 遍歷就緒的Key IteratorSelectionKey it selector.selectedKeys().iterator(); while (it.hasNext()) { SelectionKey key it.next(); it.remove(); // 必須移除否則重復(fù)處理 if (key.isAcceptable()) { // 處理新連接 ServerSocketChannel ssc (ServerSocketChannel) key.channel(); SocketChannel clientChannel ssc.accept(); clientChannel.configureBlocking(false); clientChannel.register(selector, SelectionKey.OP_READ); System.out.println(新連接: clientChannel.getRemoteAddress()); } else if (key.isReadable()) { // 處理讀事件 SocketChannel clientChannel (SocketChannel) key.channel(); readBuffer.clear(); int len clientChannel.read(readBuffer); if (len -1) { // 連接關(guān)閉 key.cancel(); clientChannel.close(); continue; } readBuffer.flip(); byte[] data new byte[readBuffer.remaining()]; readBuffer.get(data); System.out.println(收到: new String(data)); // 回寫數(shù)據(jù) ByteBuffer writeBuffer ByteBuffer.wrap(echo: .getBytes()); clientChannel.write(writeBuffer); } } } } }這段代碼雖然簡(jiǎn)單但包含了三件套協(xié)作的所有關(guān)鍵點(diǎn)Selector的創(chuàng)建和輪詢、Channel的注冊(cè)和事件處理、Buffer的讀寫和flip。你可以基于它擴(kuò)展成支持多客戶端、支持協(xié)議解析的完整服務(wù)。6.2 參數(shù)計(jì)算Buffer大小與Selector超時(shí)怎么定Buffer的大小不是拍腦袋定的。我的經(jīng)驗(yàn)公式是Buffer大小 單條消息最大長(zhǎng)度 × 2。為什么要乘2因?yàn)門CP是流式的一次read可能讀到半條消息也可能讀到一條半。留出余量可以避免頻繁擴(kuò)容。如果消息長(zhǎng)度差異很大建議用Netty的LengthFieldBasedFrameDecoder來(lái)動(dòng)態(tài)處理。Selector的超時(shí)時(shí)間要根據(jù)業(yè)務(wù)來(lái)定。如果服務(wù)需要處理定時(shí)任務(wù)比如心跳檢測(cè)超時(shí)時(shí)間應(yīng)該小于心跳間隔。比如心跳是5秒一次超時(shí)可以設(shè)1秒這樣每秒醒來(lái)一次檢查有沒(méi)有需要發(fā)送的心跳。如果純IO服務(wù)沒(méi)有定時(shí)任務(wù)超時(shí)可以設(shè)長(zhǎng)一點(diǎn)比如5秒減少無(wú)意義的喚醒。6.3 實(shí)操現(xiàn)場(chǎng)一次粘包問(wèn)題的排查記錄有一次線上服務(wù)出現(xiàn)數(shù)據(jù)錯(cuò)亂客戶端發(fā)的是JSON服務(wù)端解析出來(lái)偶爾會(huì)多出半截或者少半截。抓包看數(shù)據(jù)本身沒(méi)問(wèn)題那就是服務(wù)端讀取的問(wèn)題。排查發(fā)現(xiàn)代碼里每次read之后直接當(dāng)成完整消息處理了沒(méi)有考慮TCP粘包。TCP是字節(jié)流協(xié)議沒(méi)有消息邊界。發(fā)送方連續(xù)發(fā)兩條消息接收方可能一次read就讀到兩條拼在一起的數(shù)據(jù)也可能分兩次讀到一條消息的兩半。解決辦法有三種固定長(zhǎng)度、分隔符、長(zhǎng)度字段。我最后用的是長(zhǎng)度字段方案消息頭4個(gè)字節(jié)表示body長(zhǎng)度先讀4字節(jié)再根據(jù)長(zhǎng)度讀body。用Netty的話直接上LengthFieldBasedFrameDecoder指定長(zhǎng)度字段偏移和長(zhǎng)度就行。6.4 性能壓測(cè)三件套配置對(duì)吞吐量的影響我做過(guò)一組對(duì)比測(cè)試環(huán)境是4核8G的機(jī)器客戶端用JMeter模擬1000并發(fā)服務(wù)端分別用BIO和NIO。BIO在500并發(fā)時(shí)響應(yīng)時(shí)間開(kāi)始明顯上升1000并發(fā)時(shí)大量超時(shí)。NIO在1000并發(fā)下依然穩(wěn)定平均響應(yīng)時(shí)間在10ms以內(nèi)。進(jìn)一步調(diào)優(yōu)發(fā)現(xiàn)幾個(gè)關(guān)鍵點(diǎn)Buffer用DirectBuffer比HeapBuffer吞吐量高約15%Selector超時(shí)從0改成1秒后CPU占用率從30%降到15%EventLoop線程數(shù)設(shè)置為CPU核數(shù)的2倍時(shí)吞吐量最高再多反而下降。這些數(shù)據(jù)不一定適用于所有場(chǎng)景但方向可以參考。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案CPU 100%空轉(zhuǎn)Selector空輪詢jstack看線程棧是否在select循環(huán)重建Selector或升級(jí)JDK讀不到數(shù)據(jù)忘記flip檢查Buffer的position和limit讀之前調(diào)用flip()數(shù)據(jù)錯(cuò)亂粘包/拆包抓包對(duì)比收發(fā)數(shù)據(jù)加長(zhǎng)度字段或分隔符連接泄漏Channel未關(guān)閉lsof查看文件描述符數(shù)量確保close()被調(diào)用寫數(shù)據(jù)丟失緩沖區(qū)未flush檢查write后是否flush調(diào)用flush()或shutdownOutput()內(nèi)存溢出DirectBuffer泄漏監(jiān)控堆外內(nèi)存限制MaxDirectMemorySize事件重復(fù)處理selectedKeys未remove檢查迭代器remove調(diào)用每次處理完remove7.2 獨(dú)家避坑技巧第一個(gè)技巧用strace跟蹤系統(tǒng)調(diào)用。當(dāng)你不確定Selector底層在干什么的時(shí)候strace -e epoll_wait,epoll_ctl -p pid可以看到實(shí)際的epoll調(diào)用情況。如果epoll_wait頻繁返回0說(shuō)明有空輪詢?nèi)绻鹐poll_ctl調(diào)用異常多說(shuō)明Channel注冊(cè)/注銷太頻繁。第二個(gè)技巧給EventLoop線程起名字。Netty默認(rèn)的線程名是nioEventLoopGroup-2-1這種看不出是哪個(gè)服務(wù)。建議在創(chuàng)建EventLoopGroup時(shí)傳入ThreadFactory把線程名改成有意義的比如order-service-io-1。這樣jstack的時(shí)候一眼就能定位。第三個(gè)技巧監(jiān)控Selector的selectedKeys數(shù)量。正常情況下這個(gè)數(shù)量應(yīng)該和并發(fā)量正相關(guān)如果突然飆升到幾千可能是某個(gè)Channel一直就緒但沒(méi)被處理導(dǎo)致堆積?？梢栽贓ventLoop里加個(gè)定時(shí)任務(wù)打印這個(gè)指標(biāo)。7.3 一個(gè)真實(shí)的內(nèi)存泄漏排查過(guò)程有個(gè)服務(wù)運(yùn)行幾天后堆外內(nèi)存持續(xù)增長(zhǎng)最終OOM。用jmap看堆內(nèi)正常用NMTNative Memory Tracking看堆外一直在漲。排查代碼發(fā)現(xiàn)有個(gè)地方在異常分支里創(chuàng)建了DirectByteBuffer但沒(méi)有釋放而且這個(gè)分支被頻繁觸發(fā)。DirectByteBuffer的回收依賴Cleaner而Cleaner的執(zhí)行又依賴GC堆內(nèi)壓力不大的時(shí)候GC不頻繁導(dǎo)致堆外內(nèi)存遲遲不釋放。解決辦法有兩個(gè)一是用Netty的ByteBuf代替DirectByteBufferNetty有引用計(jì)數(shù)用完release()就能立即回收二是如果非要用DirectByteBuffer在finally塊里顯式調(diào)用Cleaner或者用反射調(diào)用free()方法。我最后改成了Netty的PooledByteBufAllocator問(wèn)題解決。8. 從NIO三件套到Netty的進(jìn)階路線如果你已經(jīng)把Buffer、Channel、Selector這三塊搞明白了接下來(lái)可以往幾個(gè)方向深入。第一個(gè)方向是Reactor模式理解單Reactor單線程、單Reactor多線程、主從Reactor多線程這三種模型的差異以及Netty為什么選擇主從Reactor。第二個(gè)方向是零拷貝研究Netty的CompositeByteBuf、FileRegion、以及Linux的sendfile系統(tǒng)調(diào)用是怎么減少數(shù)據(jù)拷貝的。第三個(gè)方向是內(nèi)存池看Netty的PooledByteBufAllocator怎么用jemalloc的思想管理內(nèi)存怎么做到高并發(fā)下的高效分配和回收。我自己走下來(lái)的體會(huì)是NIO三件套是地基Netty是建在地基上的大樓。地基不牢樓越高越危險(xiǎn)。很多人上來(lái)就學(xué)Netty的API用起來(lái)沒(méi)問(wèn)題但一旦遇到性能瓶頸或者詭異bug就束手無(wú)策了?；仡^把三件套啃透你會(huì)發(fā)現(xiàn)Netty的很多設(shè)計(jì)都是順理成章的排查問(wèn)題也有了方向。最后分享一個(gè)我常用的調(diào)試手段在EventLoop的run方法里加一段日志記錄每次select的耗時(shí)和就緒Key的數(shù)量。正常情況下select耗時(shí)應(yīng)該接近超時(shí)時(shí)間就緒Key數(shù)量波動(dòng)不大。如果select耗時(shí)接近0且Key數(shù)量為0那就是空輪詢?nèi)绻鸎ey數(shù)量持續(xù)很高那就是處理速度跟不上就緒速度需要考慮增加EventLoop線程或者優(yōu)化Handler邏輯。這個(gè)簡(jiǎn)單的監(jiān)控幫我定位過(guò)好幾次線上問(wèn)題比任何高級(jí)工具都直接。