1. 從一次線上故障說起為什么我要回頭啃Netty的NIO底座前兩年我接手過一個(gè)即時(shí)通訊服務(wù)的性能優(yōu)化項(xiàng)目單機(jī)壓測(cè)的時(shí)候QPS死活上不去CPU占用率卻高得離譜。當(dāng)時(shí)第一反應(yīng)是業(yè)務(wù)代碼寫得有問題排查了一圈發(fā)現(xiàn)線程池配置、鎖競(jìng)爭(zhēng)、序列化都沒毛病。最后用火焰圖一照大量時(shí)間耗在了傳統(tǒng)阻塞IO的線程上下文切換上。那一刻我才真正意識(shí)到很多人用Netty只是停留在“會(huì)調(diào)API”的層面對(duì)底層的Buffer、Channel、Selector這三件套的理解其實(shí)是模糊的。而恰恰是這三個(gè)組件決定了Netty為什么能扛住高并發(fā)。這篇文章我想把Netty的NIO核心組件徹底講透。不是那種照著源碼念一遍的講法而是結(jié)合我自己踩過的坑、調(diào)過的參數(shù)、看過的線上數(shù)據(jù)把Buffer、Channel、Selector這三個(gè)東西的來龍去脈、設(shè)計(jì)取舍、實(shí)操要點(diǎn)全部攤開。適合已經(jīng)用過Netty但對(duì)底層一知半解的開發(fā)者也適合剛接觸NIO、想搞清楚“為什么不用傳統(tǒng)IO”的朋友。讀完你至少能做到知道每個(gè)組件解決什么問題、參數(shù)怎么調(diào)、坑在哪里、出問題怎么排查。2. NIO三件套的整體設(shè)計(jì)思路拆解2.1 為什么傳統(tǒng)BIO在高并發(fā)場(chǎng)景下必然吃力要理解NIO的價(jià)值得先看清楚BIO的問題在哪。傳統(tǒng)阻塞IO的模型是一個(gè)線程對(duì)應(yīng)一個(gè)連接read操作沒數(shù)據(jù)就卡在那里等accept沒新連接也卡著等。這個(gè)模型在連接數(shù)少的時(shí)候很直觀代碼也好寫。但連接數(shù)一上來比如同時(shí)維持幾千個(gè)連接你就得開幾千個(gè)線程。每個(gè)線程占1MB左右的棧空間光內(nèi)存就吃掉幾個(gè)G更別說線程切換的開銷了。我實(shí)測(cè)過一個(gè)簡(jiǎn)單的Echo服務(wù)BIO模型在500并發(fā)連接時(shí)上下文切換次數(shù)每秒能到幾萬次CPU的sy系統(tǒng)態(tài)占比超過40%。這就是典型的“線程比活還多”的浪費(fèi)。NIO的核心思路是把“等待”這件事從線程身上剝離出來交給操作系統(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è)生活化的類比來解釋把Channel想象成一條快遞管道數(shù)據(jù)是包裹Buffer是你家門口的快遞柜包裹必須先放進(jìn)柜子你才能取Selector則是小區(qū)門口的保安他同時(shí)盯著幾百條管道哪條管道有包裹到了就通知你去對(duì)應(yīng)的柜子取。具體到數(shù)據(jù)流客戶端發(fā)來的數(shù)據(jù)操作系統(tǒng)先讀到內(nèi)核緩沖區(qū)然后通過Channel“搬運(yùn)”到用戶態(tài)的Buffer里你從Buffer里讀數(shù)據(jù)做業(yè)務(wù)處理。反過來寫數(shù)據(jù)時(shí)你把數(shù)據(jù)寫進(jìn)Buffer再通過Channel刷出去。Selector的作用是讓你一個(gè)線程就能監(jiān)控多個(gè)Channel的就緒狀態(tài)不用為每個(gè)Channel開一個(gè)線程去死等。這個(gè)協(xié)作關(guān)系是理解整個(gè)NIO的鑰匙后面所有的細(xì)節(jié)都是圍繞它展開的。2.3 Netty在這三者之上做了什么增強(qiáng)原生JDK的NIO API其實(shí)挺難用的Buffer的flip、rewind、clear這幾個(gè)方法經(jīng)常把人繞暈Selector的空輪詢bug也是出了名的。Netty沒有直接用JDK的ByteBuffer而是自己實(shí)現(xiàn)了ByteBuf把讀寫指針分離讀的時(shí)候不用flip寫的時(shí)候自動(dòng)擴(kuò)容還支持池化復(fù)用。Channel方面Netty抽象出了ChannelPipeline和ChannelHandler把數(shù)據(jù)流轉(zhuǎn)變成了一條責(zé)任鏈。Selector這塊Netty用EventLoop把Selector的輪詢和任務(wù)執(zhí)行整合在一起還通過反射替換了Selector的實(shí)現(xiàn)來規(guī)避空輪詢問題。所以學(xué)Netty的NIO組件我的建議是分兩層看先搞懂JDK原生NIO的Buffer、Channel、Selector各自是什么、怎么用再看Netty在它們基礎(chǔ)上做了哪些封裝和優(yōu)化。跳過第一層直接看Netty很多設(shè)計(jì)你會(huì)覺得莫名其妙只停留在第一層又用不好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)。我見過太多人因?yàn)橥薴lip導(dǎo)致讀不到數(shù)據(jù)或者讀完之后沒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)訪問省掉了這次拷貝但分配和回收的成本高而且不受JVM堆管理用不好容易內(nèi)存泄漏。我的經(jīng)驗(yàn)是頻繁創(chuàng)建銷毀的小Buffer用堆內(nèi)長(zhǎng)期復(fù)用的大Buffer用堆外。Netty默認(rèn)用PooledByteBufAllocator底層就是池化的堆外內(nèi)存通過內(nèi)存池復(fù)用來抵消分配成本。如果你自己寫NIO代碼建議對(duì)大的、生命周期長(zhǎng)的Buffer用DirectByteBuffer并且一定要手動(dòng)復(fù)用不要每次new。注意DirectByteBuffer的回收依賴GC如果分配速度超過回收速度會(huì)觸發(fā)Full GC嚴(yán)重時(shí)直接OOM。生產(chǎn)環(huán)境一定要限制堆外內(nèi)存大小通過-XX:MaxDirectMemorySize參數(shù)控制。3.3 Netty ByteBuf的讀寫指針分離設(shè)計(jì)Netty的ByteBuf把讀指針和寫指針分開了readerIndex和writerIndex各管各的讀的時(shí)候不用flip寫的時(shí)候也不用clear。這個(gè)設(shè)計(jì)看起來只是省了幾個(gè)方法調(diào)用實(shí)際上解決了一個(gè)大問題讀寫可以交錯(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使用中的常見陷阱與實(shí)操建議第一個(gè)坑是忘記考慮字節(jié)序。JDK的ByteBuffer默認(rèn)是大端序Big EndianNetty的ByteBuf默認(rèn)也是大端。但有些協(xié)議用的是小端序讀出來的數(shù)字會(huì)完全不對(duì)。解決辦法是顯式調(diào)用order(ByteOrder.LITTLE_ENDIAN)切換。第二個(gè)坑是Buffer復(fù)用時(shí)的狀態(tài)殘留。如果你把Buffer放進(jìn)對(duì)象池復(fù)用下次取出來之前一定要clear()或者至少把position和limit重置否則殘留的mark或者limit會(huì)導(dǎo)致詭異的問題。我遇到過一次線上事故就是因?yàn)閺?fù)用的Buffer沒有重置mark導(dǎo)致某次讀取時(shí)回退到了錯(cuò)誤的位置解析出來的數(shù)據(jù)錯(cuò)位。第三個(gè)坑是DirectBuffer的監(jiān)控。堆外內(nèi)存不歸JVM堆管常規(guī)的堆監(jiān)控看不到。建議用Netty自帶的PlatformDependent工具類或者JMX來監(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)聽ACCEPT事件。當(dāng)有客戶端連接進(jìn)來accept()方法返回一個(gè)SocketChannel這個(gè)SocketChannel代表和這個(gè)客戶端的連接再把它注冊(cè)到Selector上監(jiān)聽READ事件。之后這個(gè)連接上的數(shù)據(jù)讀寫都通過這個(gè)SocketChannel進(jìn)行。這里有個(gè)容易忽略的點(diǎn)accept返回的SocketChannel默認(rèn)是阻塞的必須顯式調(diào)用configureBlocking(false)設(shè)為非阻塞否則注冊(cè)到Selector上會(huì)直接拋異常。我見過好幾個(gè)新手卡在這里報(bào)錯(cuò)信息又不直觀排查半天。另外ServerSocketChannel可以同時(shí)注冊(cè)到多個(gè)Selector上嗎答案是可以但一般沒必要。一個(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ì)象通常用來存這個(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)來先經(jīng)過入站Handler鏈出去經(jīng)過出站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來支持異步關(guān)閉可以注冊(cè)監(jiān)聽器在關(guān)閉完成后做清理。第二個(gè)注意點(diǎn)是寫操作的背壓?jiǎn)栴}。如果對(duì)方接收慢你的發(fā)送緩沖區(qū)會(huì)堆積最終導(dǎo)致OOM。Netty通過Channel.isWritable()和寫緩沖區(qū)水位線WRITE_BUFFER_WATER_MARK來感知背壓你可以在寫之前判斷isWritable不可寫的時(shí)候暫停發(fā)送等channelWritabilityChanged回調(diào)再繼續(xù)。第三個(gè)注意點(diǎn)是Channel是線程安全的嗎JDK的SocketChannel本身不是線程安全的多個(gè)線程同時(shí)讀寫會(huì)出問題。Netty的Channel通過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ù)輪詢。而BIO模型下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解決了這些問題它用紅黑樹管理文件描述符不需要每次全量拷貝用就緒鏈表存儲(chǔ)就緒的事件不需要全量遍歷沒有文件描述符數(shù)量限制。所以高并發(fā)場(chǎng)景下epoll是絕對(duì)的首選。JDK在Linux上默認(rèn)就是用epoll你可以通過-Djava.nio.channels.spi.SelectorProvider參數(shù)查看或指定。5.3 Selector的空輪詢問題與Netty的解決方案JDK的Selector有一個(gè)著名的空輪詢bug在某些情況下select()方法會(huì)立即返回但selectedKeys()是空的沒有任何就緒的Channel。如果代碼里沒有正確處理這種情況就會(huì)陷入死循環(huán)CPU直接飆到100%。這個(gè)bug在JDK 6u4到JDK 7u4之間比較嚴(yán)重后來雖然修了但在某些內(nèi)核版本和特定場(chǎng)景下仍會(huì)出現(xiàn)。Netty的解決方案很巧妙它在NioEventLoop里記錄了select操作的次數(shù)和耗時(shí)如果發(fā)現(xiàn)連續(xù)多次select都立即返回且沒有就緒事件就認(rèn)為觸發(fā)了空輪詢?nèi)缓笾亟⊿elector把原來注冊(cè)的Channel全部遷移到新的Selector上。這個(gè)邏輯在select()方法的循環(huán)里通過一個(gè)selectCnt計(jì)數(shù)器來控制。閾值默認(rèn)是512次可以通過系統(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()并沒有在阻塞那么下一次select()會(huì)立即返回一次相當(dāng)于“消費(fèi)”掉了這次喚醒。這會(huì)導(dǎo)致一次無意義的空輪詢。Netty處理這個(gè)問題的方式是在wakeup之后設(shè)置一個(gè)標(biāo)記下次select之前檢查這個(gè)標(biāo)記如果發(fā)現(xiàn)是多余的喚醒就跳過。這個(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就是無限阻塞直到有事件才返回。如果設(shè)成正數(shù)就是最多阻塞那么久。Netty默認(rèn)用1秒的超時(shí)這樣即使沒有IO事件也能定期醒來處理定時(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ò)誤非常常見表現(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來動(dòng)態(tài)處理。Selector的超時(shí)時(shí)間要根據(jù)業(yè)務(wù)來定。如果服務(wù)需要處理定時(shí)任務(wù)比如心跳檢測(cè)超時(shí)時(shí)間應(yīng)該小于心跳間隔。比如心跳是5秒一次超時(shí)可以設(shè)1秒這樣每秒醒來一次檢查有沒有需要發(fā)送的心跳。如果純IO服務(wù)沒有定時(shí)任務(wù)超時(shí)可以設(shè)長(zhǎng)一點(diǎn)比如5秒減少無意義的喚醒。6.3 實(shí)操現(xiàn)場(chǎng)一次粘包問題的排查記錄有一次線上服務(wù)出現(xiàn)數(shù)據(jù)錯(cuò)亂客戶端發(fā)的是JSON服務(wù)端解析出來偶爾會(huì)多出半截或者少半截。抓包看數(shù)據(jù)本身沒問題那就是服務(wù)端讀取的問題。排查發(fā)現(xiàn)代碼里每次read之后直接當(dāng)成完整消息處理了沒有考慮TCP粘包。TCP是字節(jié)流協(xié)議沒有消息邊界。發(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ì)吞吐量的影響我做過一組對(duì)比測(cè)試環(huán)境是4核8G的機(jī)器客戶端用JMeter模擬1000并發(fā)服務(wù)端分別用BIO和NIO。BIO在500并發(fā)時(shí)響應(yīng)時(shí)間開始明顯上升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. 常見問題與排查技巧實(shí)錄7.1 問題速查表問題現(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說明有空輪詢?nèi)绻鹐poll_ctl調(diào)用異常多說明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一直就緒但沒被處理導(dǎo)致堆積?？梢栽贓ventLoop里加個(gè)定時(shí)任務(wù)打印這個(gè)指標(biāo)。7.3 一個(gè)真實(shí)的內(nèi)存泄漏排查過程有個(gè)服務(wù)運(yùn)行幾天后堆外內(nèi)存持續(xù)增長(zhǎng)最終OOM。用jmap看堆內(nèi)正常用NMTNative Memory Tracking看堆外一直在漲。排查代碼發(fā)現(xiàn)有個(gè)地方在異常分支里創(chuàng)建了DirectByteBuffer但沒有釋放而且這個(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問題解決。8. 從NIO三件套到Netty的進(jìn)階路線如果你已經(jīng)把Buffer、Channel、Selector這三塊搞明白了接下來可以往幾個(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ā)下的高效分配和回收。我自己走下來的體會(huì)是NIO三件套是地基Netty是建在地基上的大樓。地基不牢樓越高越危險(xiǎn)。很多人上來就學(xué)Netty的API用起來沒問題但一旦遇到性能瓶頸或者詭異bug就束手無策了?；仡^把三件套啃透你會(huì)發(fā)現(xiàn)Netty的很多設(shè)計(jì)都是順理成章的排查問題也有了方向。最后分享一個(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)控幫我定位過好幾次線上問題比任何高級(jí)工具都直接。