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