用：Selector與Channel的底層原理與實(shí)戰(zhàn)指南)
做后端這些年要說(shuō)Java NIO里哪個(gè)詞最讓人“上頭”多路復(fù)用Selector / Channel絕對(duì)排前列。聊天室、網(wǎng)關(guān)、消息推送、RPC長(zhǎng)連接只要連接量大這套機(jī)制幾乎繞不開(kāi)。我最早真正理解多路復(fù)用是在一個(gè)IM推送服務(wù)被幾萬(wàn)條長(zhǎng)連接壓出問(wèn)題之后被逼著把BIO換成了NIO然后把Selector從入門啃到能背。簡(jiǎn)單說(shuō)多路復(fù)用就是“用極少的線程去盯住大量的Channel”核心角色就兩個(gè)Channel負(fù)責(zé)通道Selector負(fù)責(zé)幫你盯著這些通道有沒(méi)有動(dòng)靜。這篇文章想按我的實(shí)戰(zhàn)路線把Selector/Channel機(jī)制講透適合正在學(xué)Java網(wǎng)絡(luò)編程、準(zhǔn)備后端面試或者想搞懂Netty底層原理的朋友。1. 從BIO到多路復(fù)用這個(gè)設(shè)計(jì)到底解決了什么問(wèn)題1.1 一個(gè)連接一個(gè)線程的模型為什么撐不住很多Java初學(xué)者是從Socket寫起的ServerSocket一個(gè)accept()來(lái)一個(gè)連接就new一個(gè)Thread去處理。這個(gè)模型在幾十個(gè)連接時(shí)很舒服代碼簡(jiǎn)單直接但在高并發(fā)場(chǎng)景馬上露餡。原因不難理解線程是稀缺資源每個(gè)線程默認(rèn)棧大小在512KB到1MB之間2000個(gè)連接意味著至少1GB的內(nèi)存開(kāi)銷再加上線程上下文切換、頻繁的GC壓力機(jī)器立刻就不穩(wěn)定。我見(jiàn)過(guò)一個(gè)內(nèi)部系統(tǒng)BIO模式下連接數(shù)剛上2000CPU和內(nèi)存一路飆紅最后只能靠加機(jī)器硬扛。但比資源浪費(fèi)更致命的是絕大多數(shù)連接其實(shí)沒(méi)事可做。用戶掛著頁(yè)面、客戶端開(kāi)著長(zhǎng)連接等推送真正在傳輸數(shù)據(jù)的時(shí)間可能不到1%。傳統(tǒng)BIO里這些空閑連接各自占著一條線程傻等這就是巨大的浪費(fèi)。生活里類比就是銀行柜臺(tái)每個(gè)柜員一次只服務(wù)一位客戶這位客戶哪怕只是進(jìn)來(lái)問(wèn)個(gè)路柜員也得陪他等到業(yè)務(wù)結(jié)束。效率低得讓人著急可BIO偏偏就是這么干的。用一張表把兩種模型的差異擺出來(lái)感受會(huì)更直接。模型線程與連接比例空閑連接占用典型支持規(guī)模BIO1 : 1每個(gè)連接占一個(gè)線程幾百到一兩千再高吃力NIO Selector1 : N不占業(yè)務(wù)線程由Selector統(tǒng)一監(jiān)控輕松管理數(shù)萬(wàn)連接所以說(shuō)NIO的多路復(fù)用首先解決的是“連接的管理成本”問(wèn)題。線程不再和連接一一綁定Selector用一個(gè)線程去輪詢成千上萬(wàn)個(gè)連接只有出現(xiàn)可讀、可寫、可接受新連接這些實(shí)際事件主線程才會(huì)干活。做聊天室也好、做網(wǎng)關(guān)也好只要能把這個(gè)“管理等成本”壓下來(lái)連接數(shù)才做得上去。1.2 多路復(fù)用復(fù)用的是“等待能力”回到銀行例子。如果柜員不是一個(gè)人等一個(gè)客戶而是有一個(gè)叫號(hào)員所有客戶都坐著等叫號(hào)員盯著大屏幕上的叫號(hào)信息有客戶“有事件”了號(hào)碼被喊到再通知對(duì)應(yīng)柜員去服務(wù)。NIO的Selector就是這個(gè)叫號(hào)員。它同一個(gè)時(shí)刻能監(jiān)控成百上千個(gè)Channel哪個(gè)SocketChannel可讀了、哪個(gè)ServerSocketChannel來(lái)新連接了它都知道并且把這些就緒的Channel集合返回給你。所以“多路復(fù)用”復(fù)用的不是網(wǎng)卡帶寬而是“等待這件事”。傳統(tǒng)方式是一個(gè)線程等一個(gè)連接等待本身會(huì)吃掉線程資源Selector把很多連接串行地拿去監(jiān)控一個(gè)線程就能完成所有連接的等待和事件分發(fā)。這里面最關(guān)鍵的思想是“有事件才處理沒(méi)事件不打擾”。理解了這一點(diǎn)以后看Netty的EventLoop你會(huì)覺(jué)得特別眼熟。1.3 和AIO對(duì)比為什么主力還是NIOJDK 7就引入了真正的異步IOAIO / NIO.2有AsynchronousSocketChannel、AsynchronousServerSocketChannel用CompletionHandler回調(diào)來(lái)通知結(jié)果。聽(tīng)上去比NIO的多路復(fù)用更“高級(jí)”但真實(shí)生產(chǎn)環(huán)境里Java AIO在Linux上的表現(xiàn)并不比NIO好底層異步機(jī)制在Java層面會(huì)受到很多因素制約而且代碼復(fù)雜度更高、可讀性更差。Netty官方早年也表過(guò)態(tài)Linux上還是更推薦NIO而不是AIO。所以我的經(jīng)驗(yàn)是主線吃透NIO Selector就好AIO作為概念了解即可。實(shí)際后端項(xiàng)目里網(wǎng)關(guān)、IM、推送、RPC框架底層基本都是NIO多路復(fù)用這套模型。后面如果去看Netty源碼你會(huì)發(fā)現(xiàn)它最核心的線程模型就是建立在“一個(gè)死循環(huán)select() 事件分發(fā)”之上的。NIO理解透了等于把Netty的大部分底層邏輯也提前搞明白了。2. 核心細(xì)節(jié)解析Channel、Selector、SelectionKey 怎么配合2.1 Channel在NIO里的真實(shí)角色Channel是個(gè)抽象概念中文叫通道你可以把它理解為“連接兩端的管道”。常見(jiàn)的有四種FileChannel文件IO、SocketChannelTCP客戶端通道、ServerSocketChannelTCP服務(wù)器監(jiān)聽(tīng)通道、DatagramChannelUDP通道。其中FileChannel不能注冊(cè)到Selector因?yàn)槲募蘒O沒(méi)有網(wǎng)絡(luò)連接那種“可讀/可寫事件”機(jī)制能注冊(cè)到Selector的主要是后三種。Channel和傳統(tǒng)流的區(qū)別很大。流是單向的輸入流只能讀輸出流只能寫Channel是雙向的既可以讀也可以寫。但雙不雙向不是重點(diǎn)重點(diǎn)是它可以被Selector監(jiān)控。監(jiān)控的最小單位是Channel而不是字節(jié)流。讀出來(lái)的數(shù)據(jù)統(tǒng)一放到ByteBuffer里要寫出去的數(shù)據(jù)也先裝進(jìn)ByteBuffer再丟給Channel。剛開(kāi)始容易踩的坑是Buffer模式切換ByteBuffer有個(gè)游標(biāo)概念寫完數(shù)據(jù)要調(diào)用flip()切換到讀模式讀完之后要clear()或者compact()清空或壓縮方便下一輪寫入。很多第一次寫NIO的人都是死在“忘記flip()導(dǎo)致讀出來(lái)是空的或者寫完不clear導(dǎo)致數(shù)據(jù)越堆越多”這個(gè)細(xì)節(jié)上。2.2 Selector和SelectionKey的一次協(xié)作流程Selector是NIO多路復(fù)用的核心。它的完整工作流是先創(chuàng)建Selector再把需要監(jiān)控的Channel注冊(cè)進(jìn)去register()方法會(huì)返回一個(gè)SelectionKey。SelectionKey相當(dāng)于一張“標(biāo)簽卡”記錄了這個(gè)Channel對(duì)哪些事件感興趣、當(dāng)前就緒事件集合是什么、以及你可以往上面掛一些附件對(duì)象比如業(yè)務(wù)會(huì)話數(shù)據(jù)。注冊(cè)之后主線程在一個(gè)死循環(huán)里調(diào)用selector.select()有事件就返回然后遍歷selectedKeys()處理每一個(gè)就緒的Channel。這里有一個(gè)高頻錯(cuò)誤selectedKeys()返回的是一個(gè)集合處理完一個(gè)SelectionKey之后必須手動(dòng)從集合里remove掉。如果不remove下一次select()返回后舊key還會(huì)留在集合里同一個(gè)事件會(huì)被反復(fù)處理。我在一個(gè)網(wǎng)關(guān)項(xiàng)目里就碰到過(guò)“反復(fù)讀到舊數(shù)據(jù)”的情況排查了半天最后發(fā)現(xiàn)就是忘了在迭代器里調(diào)用remove()。那之后我養(yǎng)成了一個(gè)習(xí)慣進(jìn)入遍歷后第一步就是iterator.remove()再去處理業(yè)務(wù)。此外SelectionKey提供兩套查詢方法interestOps()是注冊(cè)時(shí)關(guān)注的事件集合readyOps()是本次select()之后真正就緒的事件集合。你可以在代碼里按位判斷也可以用isAcceptable()、isReadable()、isWritable()這類封裝好的方法它們的內(nèi)部本質(zhì)上就是對(duì)常量和readyOps做位運(yùn)算。2.3 四種事件什么時(shí)候該關(guān)注哪一個(gè)先看四種事件分別對(duì)應(yīng)什么場(chǎng)景OP_ACCEPT表示服務(wù)端接收到新連接只在ServerSocketChannel上注冊(cè)通常意味著有客戶端發(fā)起connect()你應(yīng)該調(diào)用accept()把連接接進(jìn)來(lái)OP_CONNECT表示客戶端發(fā)起連接成功只在SocketChannel上注冊(cè)用于配合異步建連場(chǎng)景OP_READ表示通道可讀客戶端發(fā)數(shù)據(jù)或者對(duì)端關(guān)閉連接都會(huì)觸發(fā)OP_WRITE表示通道可寫發(fā)送緩沖區(qū)就緒時(shí)觸發(fā)但這個(gè)事件幾乎沒(méi)有門檻后面要格外小心。我的經(jīng)驗(yàn)是大部分業(yè)務(wù)場(chǎng)景里服務(wù)端只關(guān)心OP_ACCEPT和OP_READOP_WRITE只在需要主動(dòng)下發(fā)大量數(shù)據(jù)、且擔(dān)心發(fā)送緩沖區(qū)寫不進(jìn)去時(shí)才臨時(shí)關(guān)注。因?yàn)門CP發(fā)送緩沖區(qū)通常都是“可寫”的如果常態(tài)注冊(cè)O(shè)P_WRITEselect()幾乎每次都返回可寫事件結(jié)果就是CPU被白白消耗。OP_READ就好比外賣到了會(huì)響的鈴OP_WRITE則是手機(jī)里那個(gè)永遠(yuǎn)在刷新的“運(yùn)力充足”通知后者一旦注冊(cè)上就會(huì)一直騷擾你。2.4 非阻塞模式為什么是硬性前提把Channel注冊(cè)到Selector之前必須先調(diào)用configureBlocking(false)。假如不設(shè)register()會(huì)直接拋出IllegalBlockingModeException。原因是Selector的監(jiān)控機(jī)制依賴非阻塞模式只有非阻塞模式下Channel才不會(huì)因?yàn)橐淮巫x寫操作長(zhǎng)時(shí)間卡住。如果通道阻塞了Selector沒(méi)法在多通道之間自由切換那就回到一個(gè)線程等一個(gè)連接的老路上了。實(shí)際編碼里連ServerSocketChannel.accept()返回的SocketChannel也要單獨(dú)再設(shè)一次configureBlocking(false)。我見(jiàn)過(guò)不少初學(xué)者只在ServerSocketChannel上設(shè)了非阻塞結(jié)果accept出來(lái)的SocketChannel還是阻塞的數(shù)據(jù)讀寫照樣卡線程。這兩個(gè)地方都得記得處理。3. 直接抄作業(yè)手寫一個(gè)NIO聊天室服務(wù)端光講API很容易聽(tīng)完就忘最好的方式是自己動(dòng)手寫一個(gè)能跑的例子。我用NIO寫一個(gè)簡(jiǎn)單的聊天室服務(wù)端支持多個(gè)客戶端連接一個(gè)客戶端發(fā)消息服務(wù)端把消息廣播給其他所有連接。這段代碼精簡(jiǎn)但完整把a(bǔ)ccept、read、write全走一遍。3.1 初始化選擇器和服務(wù)端通道第一步是打架子創(chuàng)建Selector打開(kāi)ServerSocketChannel綁定端口設(shè)非阻塞然后注冊(cè)O(shè)P_ACCEPT事件。這塊代碼是固定模板反復(fù)用、反復(fù)背都不虧。import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.SelectionKey; import java.nio.channels.Selector; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.nio.charset.StandardCharsets; import java.util.Iterator; public class NioChatServer { private Selector selector; private ServerSocketChannel serverChannel; private ByteBuffer readBuffer ByteBuffer.allocate(1024); public void start() throws IOException { // 1. 創(chuàng)建選擇器 selector Selector.open(); // 2. 打開(kāi)服務(wù)端通道 serverChannel ServerSocketChannel.open(); // 3. 綁定端口 serverChannel.bind(new InetSocketAddress(8080)); // 4. 必須設(shè)置為非阻塞 serverChannel.configureBlocking(false); // 5. 注冊(cè)到選擇器只關(guān)注“新連接到來(lái)”事件 serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(NioChatServer started on 8080); loop(); } // 其他方法見(jiàn)下文 }這里的readBuffer是后面讀取客戶端消息用的。ByteBuffer.allocate(1024)對(duì)聊天室這種短消息完全夠用生產(chǎn)環(huán)境要根據(jù)協(xié)議估算最大消息長(zhǎng)度通常還要配合擴(kuò)容邏輯。3.2 事件循環(huán)select() 與 selectedKeys 處理主循環(huán)是所有NIO服務(wù)端的心臟。調(diào)用selector.select()阻塞在這里一旦有事件返回就拿到selectedKeys迭代器逐個(gè)處理。關(guān)鍵點(diǎn)是每次迭代先remove這一步能避免大量重復(fù)處理的詭異問(wèn)題。private void loop() throws IOException { while (true) { // 阻塞等待至少一個(gè)Channel有事件就緒 selector.select(); IteratorSelectionKey iterator selector.selectedKeys().iterator(); while (iterator.hasNext()) { SelectionKey key iterator.next(); // 立刻從集合中移除防止下次重復(fù)處理同一個(gè)key iterator.remove(); handle(key); } } } private void handle(SelectionKey key) throws IOException { if (!key.isValid()) { return; } if (key.isAcceptable()) { accept(key); } else if (key.isReadable()) { read(key); } }這段邏輯對(duì)應(yīng)面試?yán)镒罱?jīng)典的“selector.select()和selectedKeys()流程”你能講清楚“為什么要remove”這個(gè)細(xì)節(jié)面試官基本就知道你不是在背八股。3.3 接入新連接accept 的細(xì)節(jié)處理OP_ACCEPT事件時(shí)因?yàn)镾erverSocketChannel已經(jīng)非阻塞accept()會(huì)立刻返回SocketChannel或者null。null說(shuō)明連接已經(jīng)被系統(tǒng)消費(fèi)掉了忽略即可。拿到SocketChannel后必須再設(shè)成非阻塞然后注冊(cè)O(shè)P_READ事件。private void accept(SelectionKey key) throws IOException { ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); if (client ! null) { // accept出來(lái)的SocketChannel也一定要設(shè)非阻塞 client.configureBlocking(false); // 新連接只關(guān)注可讀事件 client.register(selector, SelectionKey.OP_READ); System.out.println(新客戶端接入 client.getRemoteAddress()); } }為什么新連接不注冊(cè)O(shè)P_ACCEPT因?yàn)樗皇荢erverSocketChannelOP_ACCEPT只在服務(wù)端監(jiān)聽(tīng)通道上有效。新連接一旦建立接下來(lái)最有用的就是OP_READ等著收消息就行。3.4 讀取消息與向其他連接廣播這是核心業(yè)務(wù)邏輯。讀取前要清空Bufferread()把數(shù)據(jù)寫入Buffer之后再flip()切換到讀模式取出字節(jié)。len -1表示客戶端主動(dòng)關(guān)閉要清理連接。讀到的消息構(gòu)造好之后遍歷所有已注冊(cè)的Channel把消息寫給其他SocketChannel。private void read(SelectionKey key) throws IOException { SocketChannel client (SocketChannel) key.channel(); // 切換到寫模式 readBuffer.clear(); int len client.read(readBuffer); if (len -1) { // 客戶端關(guān)閉連接 System.out.println(客戶端斷開(kāi) client.getRemoteAddress()); client.close(); return; } if (len 0) { return; } // 切換到讀模式 readBuffer.flip(); byte[] data new byte[len]; readBuffer.get(data); String msg new String(data, StandardCharsets.UTF_8); System.out.println(收到消息 msg); // 廣播給其他客戶端 String broadcast 客戶端說(shuō) msg; ByteBuffer outBuffer ByteBuffer.wrap(broadcast.getBytes(StandardCharsets.UTF_8)); for (SelectionKey otherKey : selector.keys()) { if (otherKey.channel() instanceof SocketChannel otherKey.isValid()) { SocketChannel target (SocketChannel) otherKey.channel(); if (target ! client) { target.write(outBuffer); } } } // 注意嚴(yán)謹(jǐn)代碼需捕獲write時(shí)產(chǎn)生的IOException并關(guān)閉異常連接 }這段代碼有幾處可以深究。target.write()如果對(duì)端已經(jīng)斷開(kāi)會(huì)拋IOException嚴(yán)謹(jǐn)實(shí)現(xiàn)要try-catch并調(diào)用key.cancel()和channel.close()。廣播是同步寫假設(shè)某個(gè)目標(biāo)通道的發(fā)送緩沖區(qū)滿了write()可能返回0這里沒(méi)有處理未完寫的字節(jié)。真實(shí)項(xiàng)目里需要把“寫不下的數(shù)據(jù)”暫存起來(lái)等OP_WRITE就緒后再寫這也是前面說(shuō)OP_WRITE是“臨時(shí)關(guān)注”的典型場(chǎng)景。selector.keys()拿到的集合包含服務(wù)端通道所以加了instanceof過(guò)濾。3.5 本地自測(cè)方式跑起來(lái)之后怎么驗(yàn)證最方便的辦法是Linux里開(kāi)兩個(gè)終端用nc命令Windows上可以用telnet或者直接用SocketChannel寫個(gè)測(cè)試客戶端。建議直接寫一個(gè)簡(jiǎn)單的Java客戶端順便熟悉一下SocketChannel的用法。import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.SocketChannel; import java.nio.charset.StandardCharsets; public class NioChatClient { public static void main(String[] args) throws Exception { SocketChannel channel SocketChannel.open(); channel.connect(new InetSocketAddress(127.0.0.1, 8080)); channel.write(ByteBuffer.wrap(hello nio.getBytes(StandardCharsets.UTF_8))); ByteBuffer buffer ByteBuffer.allocate(1024); int len channel.read(buffer); while (len 0) { len channel.read(buffer); } if (len 0) { buffer.flip(); byte[] data new byte[len]; buffer.get(data); System.out.println(服務(wù)端返回 new String(data, StandardCharsets.UTF_8)); } channel.close(); } }自測(cè)的重點(diǎn)不是看結(jié)果而是體會(huì)“服務(wù)端循環(huán)里每次select()返回后事件是怎么分布到多個(gè)Channel上的”。開(kāi)著三個(gè)客戶端窗口各發(fā)幾條消息你能明顯感覺(jué)到Selector在統(tǒng)一調(diào)度而不是每個(gè)連接一個(gè)Thread在那里各干各的。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 CPU空轉(zhuǎn)著名的空輪詢問(wèn)題Linux環(huán)境下早期JDK版本的Selector實(shí)現(xiàn)有個(gè)教科書級(jí)的bug即使沒(méi)有任何事件select()也可能提前醒來(lái)返回0。如果程序直接在while里循環(huán)select()就會(huì)形成空輪詢CPU直接被打滿。解決思路是加時(shí)間戳判斷如果連續(xù)多次select()的等待時(shí)間極短且返回0就重建Selector把已注冊(cè)的Channel全部重新注冊(cè)一遍。Netty早期就是這么處理的。遇到“Java進(jìn)程CPU 100%堆棧卻卡在Selector.select()”的情況先往這個(gè)方向排查。4.2 半包/粘包緩沖區(qū)到底怎么管聊天室demo里一次read可能讀到一個(gè)完整消息也可能讀到半個(gè)消息或者兩個(gè)消息黏在一起。這是TCP流式傳輸?shù)奶烊恍袨椴皇荖IO的缺陷。真實(shí)協(xié)議設(shè)計(jì)通常加長(zhǎng)度字段或分隔符比如前4字節(jié)是消息體長(zhǎng)度后面按長(zhǎng)度讀取。處理粘包時(shí)ByteBuffer扮演“積攢區(qū)”的角色讀到的數(shù)據(jù)暫時(shí)不清空等攢夠一個(gè)完整包再消費(fèi)用compact()把沒(méi)讀完的剩余數(shù)據(jù)挪到buffer頭部繼續(xù)等下一次可讀事件。半包和粘包在面試?yán)锍霈F(xiàn)頻率極高而且往往和“ByteBuffer怎么清零”“flip和compact怎么選”一起問(wèn)。我的建議是不要在NIO回調(diào)里直接按“一條消息”來(lái)理解數(shù)據(jù)而是按“字節(jié)流緩沖區(qū)”來(lái)理解邊界自己維護(hù)。想省心就上Netty它自帶LengthFieldBasedFrameDecoder這類解碼器但原理還是這些。4.3 OP_WRITE反復(fù)觸發(fā)為什么CPU會(huì)飆升這個(gè)問(wèn)題我見(jiàn)過(guò)太多次。有人在注冊(cè)的時(shí)候?qū)懗蒘electionKey.OP_READ | SelectionKey.OP_WRITE結(jié)果服務(wù)器就開(kāi)始瘋狂空轉(zhuǎn)。原因很簡(jiǎn)單TCP發(fā)送緩沖區(qū)默認(rèn)很大絕大多數(shù)時(shí)候都是“可寫”的所以O(shè)P_WRITE事件幾乎每次select()都會(huì)命中。正確姿勢(shì)是只在業(yè)務(wù)“發(fā)送緩沖區(qū)可能滿了”的當(dāng)口去注冊(cè)O(shè)P_WRITE寫完后馬上取消這個(gè)興趣集。想看成熟實(shí)踐可以去讀Netty里writeBuffer和flush相關(guān)的源碼它對(duì)這個(gè)事的處理極其細(xì)致。4.4 同名詞Selector帶來(lái)的概念混淆排查問(wèn)題時(shí)我偶爾會(huì)看到有人貼出“no section matches selector”的報(bào)錯(cuò)誤以為是Java NIO的Selector出了問(wèn)題。這類報(bào)錯(cuò)幾乎都來(lái)自前端自動(dòng)化測(cè)試或XPath/CSS選擇器庫(kù)意思是“沒(méi)有節(jié)點(diǎn)命中這個(gè)選擇器”和Java NIO完全不是一回事。Java NIO里常見(jiàn)的異常是IllegalBlockingModeException沒(méi)設(shè)非阻塞就注冊(cè)、CancelledKeyExceptionkey已失效還在用、ClosedSelectorExceptionSelector被關(guān)閉后繼續(xù)select。面試時(shí)能把這幾類異常說(shuō)清楚比背概念更能體現(xiàn)功底。4.5 線程安全selector.wakeup() 要怎么用Selector不是線程安全的常規(guī)做法是單線程阻塞在select()上所有事件都在這個(gè)線程處理。如果業(yè)務(wù)線程想喚醒這個(gè)線程去執(zhí)行動(dòng)態(tài)注冊(cè)、優(yōu)雅關(guān)閉等操作Selector專門提供wakeup()它會(huì)讓正在阻塞的select()立刻返回。這里有個(gè)細(xì)節(jié)如果在別的線程直接調(diào)用Selector的register()會(huì)因?yàn)閞egister內(nèi)部有鎖而卡住正確做法是先在業(yè)務(wù)線程調(diào)用selector.wakeup()讓select線程醒過(guò)來(lái)再由select線程去執(zhí)行注冊(cè)動(dòng)作。這個(gè)知識(shí)點(diǎn)在寫網(wǎng)關(guān)、框架代碼時(shí)特別有用。4.6 關(guān)閉連接時(shí)key 的清理順序當(dāng)客戶端異常斷開(kāi)read()返回-1要依次做三件事key.cancel()、channel.close()、必要時(shí)在下次select()前處理CancelledKeyException。有人只close通道不cancel雖然通道關(guān)閉后key會(huì)失效但仍可能殘留到select返回集合里。正確的清理邏輯要統(tǒng)一封裝一個(gè)closeChannel方法里面try-catch所有IO異常避免因?yàn)橐粋€(gè)壞連接拖垮整個(gè)事件循環(huán)。尤其是做長(zhǎng)連接服務(wù)時(shí)連接的管理和清理往往比數(shù)據(jù)讀寫更容易出bug。最后說(shuō)點(diǎn)個(gè)人體會(huì)。我最初學(xué)NIO時(shí)也背過(guò)“Selector是干嘛的、Channel是干嘛的”但真正記住知識(shí)點(diǎn)是在自己寫完聊天室demo、又把空輪詢和粘包坑踩過(guò)一遍之后。如果你現(xiàn)在準(zhǔn)備面試核心就那么幾條Buffer的flip/clear、四種事件的含義、selectedKeys為什么必須remove、OP_WRITE為什么不能長(zhǎng)期注冊(cè)。把這些講順暢面試官基本不會(huì)再追問(wèn)深了。如果你準(zhǔn)備上生產(chǎn)再補(bǔ)一層連接生命周期管理和半包處理就夠了。這套內(nèi)容后面還能繼續(xù)往Reactor模型、Netty的EventLoop去擴(kuò)展NIO這塊地基打牢了后面看到那些高大上的并發(fā)框架會(huì)發(fā)現(xiàn)底層邏輯其實(shí)一直是同一套。 Java NIO多路復(fù)用：Selector與Channel的底層原理與實(shí)戰(zhàn)指南
做后端這些年要說(shuō)Java NIO里哪個(gè)詞最讓人“上頭”多路復(fù)用Selector / Channel絕對(duì)排前列。聊天室、網(wǎng)關(guān)、消息推送、RPC長(zhǎng)連接只要連接量大這套機(jī)制幾乎繞不開(kāi)。我最早真正理解多路復(fù)用是在一個(gè)IM推送服務(wù)被幾萬(wàn)條長(zhǎng)連接壓出問(wèn)題之后被逼著把BIO換成了NIO然后把Selector從入門啃到能背。簡(jiǎn)單說(shuō)多路復(fù)用就是“用極少的線程去盯住大量的Channel”核心角色就兩個(gè)Channel負(fù)責(zé)通道Selector負(fù)責(zé)幫你盯著這些通道有沒(méi)有動(dòng)靜。這篇文章想按我的實(shí)戰(zhàn)路線把Selector/Channel機(jī)制講透適合正在學(xué)Java網(wǎng)絡(luò)編程、準(zhǔn)備后端面試或者想搞懂Netty底層原理的朋友。1. 從BIO到多路復(fù)用這個(gè)設(shè)計(jì)到底解決了什么問(wèn)題1.1 一個(gè)連接一個(gè)線程的模型為什么撐不住很多Java初學(xué)者是從Socket寫起的ServerSocket一個(gè)accept()來(lái)一個(gè)連接就new一個(gè)Thread去處理。這個(gè)模型在幾十個(gè)連接時(shí)很舒服代碼簡(jiǎn)單直接但在高并發(fā)場(chǎng)景馬上露餡。原因不難理解線程是稀缺資源每個(gè)線程默認(rèn)棧大小在512KB到1MB之間2000個(gè)連接意味著至少1GB的內(nèi)存開(kāi)銷再加上線程上下文切換、頻繁的GC壓力機(jī)器立刻就不穩(wěn)定。我見(jiàn)過(guò)一個(gè)內(nèi)部系統(tǒng)BIO模式下連接數(shù)剛上2000CPU和內(nèi)存一路飆紅最后只能靠加機(jī)器硬扛。但比資源浪費(fèi)更致命的是絕大多數(shù)連接其實(shí)沒(méi)事可做。用戶掛著頁(yè)面、客戶端開(kāi)著長(zhǎng)連接等推送真正在傳輸數(shù)據(jù)的時(shí)間可能不到1%。傳統(tǒng)BIO里這些空閑連接各自占著一條線程傻等這就是巨大的浪費(fèi)。生活里類比就是銀行柜臺(tái)每個(gè)柜員一次只服務(wù)一位客戶這位客戶哪怕只是進(jìn)來(lái)問(wèn)個(gè)路柜員也得陪他等到業(yè)務(wù)結(jié)束。效率低得讓人著急可BIO偏偏就是這么干的。用一張表把兩種模型的差異擺出來(lái)感受會(huì)更直接。模型線程與連接比例空閑連接占用典型支持規(guī)模BIO1 : 1每個(gè)連接占一個(gè)線程幾百到一兩千再高吃力NIO Selector1 : N不占業(yè)務(wù)線程由Selector統(tǒng)一監(jiān)控輕松管理數(shù)萬(wàn)連接所以說(shuō)NIO的多路復(fù)用首先解決的是“連接的管理成本”問(wèn)題。線程不再和連接一一綁定Selector用一個(gè)線程去輪詢成千上萬(wàn)個(gè)連接只有出現(xiàn)可讀、可寫、可接受新連接這些實(shí)際事件主線程才會(huì)干活。做聊天室也好、做網(wǎng)關(guān)也好只要能把這個(gè)“管理等成本”壓下來(lái)連接數(shù)才做得上去。1.2 多路復(fù)用復(fù)用的是“等待能力”回到銀行例子。如果柜員不是一個(gè)人等一個(gè)客戶而是有一個(gè)叫號(hào)員所有客戶都坐著等叫號(hào)員盯著大屏幕上的叫號(hào)信息有客戶“有事件”了號(hào)碼被喊到再通知對(duì)應(yīng)柜員去服務(wù)。NIO的Selector就是這個(gè)叫號(hào)員。它同一個(gè)時(shí)刻能監(jiān)控成百上千個(gè)Channel哪個(gè)SocketChannel可讀了、哪個(gè)ServerSocketChannel來(lái)新連接了它都知道并且把這些就緒的Channel集合返回給你。所以“多路復(fù)用”復(fù)用的不是網(wǎng)卡帶寬而是“等待這件事”。傳統(tǒng)方式是一個(gè)線程等一個(gè)連接等待本身會(huì)吃掉線程資源Selector把很多連接串行地拿去監(jiān)控一個(gè)線程就能完成所有連接的等待和事件分發(fā)。這里面最關(guān)鍵的思想是“有事件才處理沒(méi)事件不打擾”。理解了這一點(diǎn)以后看Netty的EventLoop你會(huì)覺(jué)得特別眼熟。1.3 和AIO對(duì)比為什么主力還是NIOJDK 7就引入了真正的異步IOAIO / NIO.2有AsynchronousSocketChannel、AsynchronousServerSocketChannel用CompletionHandler回調(diào)來(lái)通知結(jié)果。聽(tīng)上去比NIO的多路復(fù)用更“高級(jí)”但真實(shí)生產(chǎn)環(huán)境里Java AIO在Linux上的表現(xiàn)并不比NIO好底層異步機(jī)制在Java層面會(huì)受到很多因素制約而且代碼復(fù)雜度更高、可讀性更差。Netty官方早年也表過(guò)態(tài)Linux上還是更推薦NIO而不是AIO。所以我的經(jīng)驗(yàn)是主線吃透NIO Selector就好AIO作為概念了解即可。實(shí)際后端項(xiàng)目里網(wǎng)關(guān)、IM、推送、RPC框架底層基本都是NIO多路復(fù)用這套模型。后面如果去看Netty源碼你會(huì)發(fā)現(xiàn)它最核心的線程模型就是建立在“一個(gè)死循環(huán)select() 事件分發(fā)”之上的。NIO理解透了等于把Netty的大部分底層邏輯也提前搞明白了。2. 核心細(xì)節(jié)解析Channel、Selector、SelectionKey 怎么配合2.1 Channel在NIO里的真實(shí)角色Channel是個(gè)抽象概念中文叫通道你可以把它理解為“連接兩端的管道”。常見(jiàn)的有四種FileChannel文件IO、SocketChannelTCP客戶端通道、ServerSocketChannelTCP服務(wù)器監(jiān)聽(tīng)通道、DatagramChannelUDP通道。其中FileChannel不能注冊(cè)到Selector因?yàn)槲募蘒O沒(méi)有網(wǎng)絡(luò)連接那種“可讀/可寫事件”機(jī)制能注冊(cè)到Selector的主要是后三種。Channel和傳統(tǒng)流的區(qū)別很大。流是單向的輸入流只能讀輸出流只能寫Channel是雙向的既可以讀也可以寫。但雙不雙向不是重點(diǎn)重點(diǎn)是它可以被Selector監(jiān)控。監(jiān)控的最小單位是Channel而不是字節(jié)流。讀出來(lái)的數(shù)據(jù)統(tǒng)一放到ByteBuffer里要寫出去的數(shù)據(jù)也先裝進(jìn)ByteBuffer再丟給Channel。剛開(kāi)始容易踩的坑是Buffer模式切換ByteBuffer有個(gè)游標(biāo)概念寫完數(shù)據(jù)要調(diào)用flip()切換到讀模式讀完之后要clear()或者compact()清空或壓縮方便下一輪寫入。很多第一次寫NIO的人都是死在“忘記flip()導(dǎo)致讀出來(lái)是空的或者寫完不clear導(dǎo)致數(shù)據(jù)越堆越多”這個(gè)細(xì)節(jié)上。2.2 Selector和SelectionKey的一次協(xié)作流程Selector是NIO多路復(fù)用的核心。它的完整工作流是先創(chuàng)建Selector再把需要監(jiān)控的Channel注冊(cè)進(jìn)去register()方法會(huì)返回一個(gè)SelectionKey。SelectionKey相當(dāng)于一張“標(biāo)簽卡”記錄了這個(gè)Channel對(duì)哪些事件感興趣、當(dāng)前就緒事件集合是什么、以及你可以往上面掛一些附件對(duì)象比如業(yè)務(wù)會(huì)話數(shù)據(jù)。注冊(cè)之后主線程在一個(gè)死循環(huán)里調(diào)用selector.select()有事件就返回然后遍歷selectedKeys()處理每一個(gè)就緒的Channel。這里有一個(gè)高頻錯(cuò)誤selectedKeys()返回的是一個(gè)集合處理完一個(gè)SelectionKey之后必須手動(dòng)從集合里remove掉。如果不remove下一次select()返回后舊key還會(huì)留在集合里同一個(gè)事件會(huì)被反復(fù)處理。我在一個(gè)網(wǎng)關(guān)項(xiàng)目里就碰到過(guò)“反復(fù)讀到舊數(shù)據(jù)”的情況排查了半天最后發(fā)現(xiàn)就是忘了在迭代器里調(diào)用remove()。那之后我養(yǎng)成了一個(gè)習(xí)慣進(jìn)入遍歷后第一步就是iterator.remove()再去處理業(yè)務(wù)。此外SelectionKey提供兩套查詢方法interestOps()是注冊(cè)時(shí)關(guān)注的事件集合readyOps()是本次select()之后真正就緒的事件集合。你可以在代碼里按位判斷也可以用isAcceptable()、isReadable()、isWritable()這類封裝好的方法它們的內(nèi)部本質(zhì)上就是對(duì)常量和readyOps做位運(yùn)算。2.3 四種事件什么時(shí)候該關(guān)注哪一個(gè)先看四種事件分別對(duì)應(yīng)什么場(chǎng)景OP_ACCEPT表示服務(wù)端接收到新連接只在ServerSocketChannel上注冊(cè)通常意味著有客戶端發(fā)起connect()你應(yīng)該調(diào)用accept()把連接接進(jìn)來(lái)OP_CONNECT表示客戶端發(fā)起連接成功只在SocketChannel上注冊(cè)用于配合異步建連場(chǎng)景OP_READ表示通道可讀客戶端發(fā)數(shù)據(jù)或者對(duì)端關(guān)閉連接都會(huì)觸發(fā)OP_WRITE表示通道可寫發(fā)送緩沖區(qū)就緒時(shí)觸發(fā)但這個(gè)事件幾乎沒(méi)有門檻后面要格外小心。我的經(jīng)驗(yàn)是大部分業(yè)務(wù)場(chǎng)景里服務(wù)端只關(guān)心OP_ACCEPT和OP_READOP_WRITE只在需要主動(dòng)下發(fā)大量數(shù)據(jù)、且擔(dān)心發(fā)送緩沖區(qū)寫不進(jìn)去時(shí)才臨時(shí)關(guān)注。因?yàn)門CP發(fā)送緩沖區(qū)通常都是“可寫”的如果常態(tài)注冊(cè)O(shè)P_WRITEselect()幾乎每次都返回可寫事件結(jié)果就是CPU被白白消耗。OP_READ就好比外賣到了會(huì)響的鈴OP_WRITE則是手機(jī)里那個(gè)永遠(yuǎn)在刷新的“運(yùn)力充足”通知后者一旦注冊(cè)上就會(huì)一直騷擾你。2.4 非阻塞模式為什么是硬性前提把Channel注冊(cè)到Selector之前必須先調(diào)用configureBlocking(false)。假如不設(shè)register()會(huì)直接拋出IllegalBlockingModeException。原因是Selector的監(jiān)控機(jī)制依賴非阻塞模式只有非阻塞模式下Channel才不會(huì)因?yàn)橐淮巫x寫操作長(zhǎng)時(shí)間卡住。如果通道阻塞了Selector沒(méi)法在多通道之間自由切換那就回到一個(gè)線程等一個(gè)連接的老路上了。實(shí)際編碼里連ServerSocketChannel.accept()返回的SocketChannel也要單獨(dú)再設(shè)一次configureBlocking(false)。我見(jiàn)過(guò)不少初學(xué)者只在ServerSocketChannel上設(shè)了非阻塞結(jié)果accept出來(lái)的SocketChannel還是阻塞的數(shù)據(jù)讀寫照樣卡線程。這兩個(gè)地方都得記得處理。3. 直接抄作業(yè)手寫一個(gè)NIO聊天室服務(wù)端光講API很容易聽(tīng)完就忘最好的方式是自己動(dòng)手寫一個(gè)能跑的例子。我用NIO寫一個(gè)簡(jiǎn)單的聊天室服務(wù)端支持多個(gè)客戶端連接一個(gè)客戶端發(fā)消息服務(wù)端把消息廣播給其他所有連接。這段代碼精簡(jiǎn)但完整把a(bǔ)ccept、read、write全走一遍。3.1 初始化選擇器和服務(wù)端通道第一步是打架子創(chuàng)建Selector打開(kāi)ServerSocketChannel綁定端口設(shè)非阻塞然后注冊(cè)O(shè)P_ACCEPT事件。這塊代碼是固定模板反復(fù)用、反復(fù)背都不虧。import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.SelectionKey; import java.nio.channels.Selector; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.nio.charset.StandardCharsets; import java.util.Iterator; public class NioChatServer { private Selector selector; private ServerSocketChannel serverChannel; private ByteBuffer readBuffer ByteBuffer.allocate(1024); public void start() throws IOException { // 1. 創(chuàng)建選擇器 selector Selector.open(); // 2. 打開(kāi)服務(wù)端通道 serverChannel ServerSocketChannel.open(); // 3. 綁定端口 serverChannel.bind(new InetSocketAddress(8080)); // 4. 必須設(shè)置為非阻塞 serverChannel.configureBlocking(false); // 5. 注冊(cè)到選擇器只關(guān)注“新連接到來(lái)”事件 serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(NioChatServer started on 8080); loop(); } // 其他方法見(jiàn)下文 }這里的readBuffer是后面讀取客戶端消息用的。ByteBuffer.allocate(1024)對(duì)聊天室這種短消息完全夠用生產(chǎn)環(huán)境要根據(jù)協(xié)議估算最大消息長(zhǎng)度通常還要配合擴(kuò)容邏輯。3.2 事件循環(huán)select() 與 selectedKeys 處理主循環(huán)是所有NIO服務(wù)端的心臟。調(diào)用selector.select()阻塞在這里一旦有事件返回就拿到selectedKeys迭代器逐個(gè)處理。關(guān)鍵點(diǎn)是每次迭代先remove這一步能避免大量重復(fù)處理的詭異問(wèn)題。private void loop() throws IOException { while (true) { // 阻塞等待至少一個(gè)Channel有事件就緒 selector.select(); IteratorSelectionKey iterator selector.selectedKeys().iterator(); while (iterator.hasNext()) { SelectionKey key iterator.next(); // 立刻從集合中移除防止下次重復(fù)處理同一個(gè)key iterator.remove(); handle(key); } } } private void handle(SelectionKey key) throws IOException { if (!key.isValid()) { return; } if (key.isAcceptable()) { accept(key); } else if (key.isReadable()) { read(key); } }這段邏輯對(duì)應(yīng)面試?yán)镒罱?jīng)典的“selector.select()和selectedKeys()流程”你能講清楚“為什么要remove”這個(gè)細(xì)節(jié)面試官基本就知道你不是在背八股。3.3 接入新連接accept 的細(xì)節(jié)處理OP_ACCEPT事件時(shí)因?yàn)镾erverSocketChannel已經(jīng)非阻塞accept()會(huì)立刻返回SocketChannel或者null。null說(shuō)明連接已經(jīng)被系統(tǒng)消費(fèi)掉了忽略即可。拿到SocketChannel后必須再設(shè)成非阻塞然后注冊(cè)O(shè)P_READ事件。private void accept(SelectionKey key) throws IOException { ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); if (client ! null) { // accept出來(lái)的SocketChannel也一定要設(shè)非阻塞 client.configureBlocking(false); // 新連接只關(guān)注可讀事件 client.register(selector, SelectionKey.OP_READ); System.out.println(新客戶端接入 client.getRemoteAddress()); } }為什么新連接不注冊(cè)O(shè)P_ACCEPT因?yàn)樗皇荢erverSocketChannelOP_ACCEPT只在服務(wù)端監(jiān)聽(tīng)通道上有效。新連接一旦建立接下來(lái)最有用的就是OP_READ等著收消息就行。3.4 讀取消息與向其他連接廣播這是核心業(yè)務(wù)邏輯。讀取前要清空Bufferread()把數(shù)據(jù)寫入Buffer之后再flip()切換到讀模式取出字節(jié)。len -1表示客戶端主動(dòng)關(guān)閉要清理連接。讀到的消息構(gòu)造好之后遍歷所有已注冊(cè)的Channel把消息寫給其他SocketChannel。private void read(SelectionKey key) throws IOException { SocketChannel client (SocketChannel) key.channel(); // 切換到寫模式 readBuffer.clear(); int len client.read(readBuffer); if (len -1) { // 客戶端關(guān)閉連接 System.out.println(客戶端斷開(kāi) client.getRemoteAddress()); client.close(); return; } if (len 0) { return; } // 切換到讀模式 readBuffer.flip(); byte[] data new byte[len]; readBuffer.get(data); String msg new String(data, StandardCharsets.UTF_8); System.out.println(收到消息 msg); // 廣播給其他客戶端 String broadcast 客戶端說(shuō) msg; ByteBuffer outBuffer ByteBuffer.wrap(broadcast.getBytes(StandardCharsets.UTF_8)); for (SelectionKey otherKey : selector.keys()) { if (otherKey.channel() instanceof SocketChannel otherKey.isValid()) { SocketChannel target (SocketChannel) otherKey.channel(); if (target ! client) { target.write(outBuffer); } } } // 注意嚴(yán)謹(jǐn)代碼需捕獲write時(shí)產(chǎn)生的IOException并關(guān)閉異常連接 }這段代碼有幾處可以深究。target.write()如果對(duì)端已經(jīng)斷開(kāi)會(huì)拋IOException嚴(yán)謹(jǐn)實(shí)現(xiàn)要try-catch并調(diào)用key.cancel()和channel.close()。廣播是同步寫假設(shè)某個(gè)目標(biāo)通道的發(fā)送緩沖區(qū)滿了write()可能返回0這里沒(méi)有處理未完寫的字節(jié)。真實(shí)項(xiàng)目里需要把“寫不下的數(shù)據(jù)”暫存起來(lái)等OP_WRITE就緒后再寫這也是前面說(shuō)OP_WRITE是“臨時(shí)關(guān)注”的典型場(chǎng)景。selector.keys()拿到的集合包含服務(wù)端通道所以加了instanceof過(guò)濾。3.5 本地自測(cè)方式跑起來(lái)之后怎么驗(yàn)證最方便的辦法是Linux里開(kāi)兩個(gè)終端用nc命令Windows上可以用telnet或者直接用SocketChannel寫個(gè)測(cè)試客戶端。建議直接寫一個(gè)簡(jiǎn)單的Java客戶端順便熟悉一下SocketChannel的用法。import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.SocketChannel; import java.nio.charset.StandardCharsets; public class NioChatClient { public static void main(String[] args) throws Exception { SocketChannel channel SocketChannel.open(); channel.connect(new InetSocketAddress(127.0.0.1, 8080)); channel.write(ByteBuffer.wrap(hello nio.getBytes(StandardCharsets.UTF_8))); ByteBuffer buffer ByteBuffer.allocate(1024); int len channel.read(buffer); while (len 0) { len channel.read(buffer); } if (len 0) { buffer.flip(); byte[] data new byte[len]; buffer.get(data); System.out.println(服務(wù)端返回 new String(data, StandardCharsets.UTF_8)); } channel.close(); } }自測(cè)的重點(diǎn)不是看結(jié)果而是體會(huì)“服務(wù)端循環(huán)里每次select()返回后事件是怎么分布到多個(gè)Channel上的”。開(kāi)著三個(gè)客戶端窗口各發(fā)幾條消息你能明顯感覺(jué)到Selector在統(tǒng)一調(diào)度而不是每個(gè)連接一個(gè)Thread在那里各干各的。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 CPU空轉(zhuǎn)著名的空輪詢問(wèn)題Linux環(huán)境下早期JDK版本的Selector實(shí)現(xiàn)有個(gè)教科書級(jí)的bug即使沒(méi)有任何事件select()也可能提前醒來(lái)返回0。如果程序直接在while里循環(huán)select()就會(huì)形成空輪詢CPU直接被打滿。解決思路是加時(shí)間戳判斷如果連續(xù)多次select()的等待時(shí)間極短且返回0就重建Selector把已注冊(cè)的Channel全部重新注冊(cè)一遍。Netty早期就是這么處理的。遇到“Java進(jìn)程CPU 100%堆棧卻卡在Selector.select()”的情況先往這個(gè)方向排查。4.2 半包/粘包緩沖區(qū)到底怎么管聊天室demo里一次read可能讀到一個(gè)完整消息也可能讀到半個(gè)消息或者兩個(gè)消息黏在一起。這是TCP流式傳輸?shù)奶烊恍袨椴皇荖IO的缺陷。真實(shí)協(xié)議設(shè)計(jì)通常加長(zhǎng)度字段或分隔符比如前4字節(jié)是消息體長(zhǎng)度后面按長(zhǎng)度讀取。處理粘包時(shí)ByteBuffer扮演“積攢區(qū)”的角色讀到的數(shù)據(jù)暫時(shí)不清空等攢夠一個(gè)完整包再消費(fèi)用compact()把沒(méi)讀完的剩余數(shù)據(jù)挪到buffer頭部繼續(xù)等下一次可讀事件。半包和粘包在面試?yán)锍霈F(xiàn)頻率極高而且往往和“ByteBuffer怎么清零”“flip和compact怎么選”一起問(wèn)。我的建議是不要在NIO回調(diào)里直接按“一條消息”來(lái)理解數(shù)據(jù)而是按“字節(jié)流緩沖區(qū)”來(lái)理解邊界自己維護(hù)。想省心就上Netty它自帶LengthFieldBasedFrameDecoder這類解碼器但原理還是這些。4.3 OP_WRITE反復(fù)觸發(fā)為什么CPU會(huì)飆升這個(gè)問(wèn)題我見(jiàn)過(guò)太多次。有人在注冊(cè)的時(shí)候?qū)懗蒘electionKey.OP_READ | SelectionKey.OP_WRITE結(jié)果服務(wù)器就開(kāi)始瘋狂空轉(zhuǎn)。原因很簡(jiǎn)單TCP發(fā)送緩沖區(qū)默認(rèn)很大絕大多數(shù)時(shí)候都是“可寫”的所以O(shè)P_WRITE事件幾乎每次select()都會(huì)命中。正確姿勢(shì)是只在業(yè)務(wù)“發(fā)送緩沖區(qū)可能滿了”的當(dāng)口去注冊(cè)O(shè)P_WRITE寫完后馬上取消這個(gè)興趣集。想看成熟實(shí)踐可以去讀Netty里writeBuffer和flush相關(guān)的源碼它對(duì)這個(gè)事的處理極其細(xì)致。4.4 同名詞Selector帶來(lái)的概念混淆排查問(wèn)題時(shí)我偶爾會(huì)看到有人貼出“no section matches selector”的報(bào)錯(cuò)誤以為是Java NIO的Selector出了問(wèn)題。這類報(bào)錯(cuò)幾乎都來(lái)自前端自動(dòng)化測(cè)試或XPath/CSS選擇器庫(kù)意思是“沒(méi)有節(jié)點(diǎn)命中這個(gè)選擇器”和Java NIO完全不是一回事。Java NIO里常見(jiàn)的異常是IllegalBlockingModeException沒(méi)設(shè)非阻塞就注冊(cè)、CancelledKeyExceptionkey已失效還在用、ClosedSelectorExceptionSelector被關(guān)閉后繼續(xù)select。面試時(shí)能把這幾類異常說(shuō)清楚比背概念更能體現(xiàn)功底。4.5 線程安全selector.wakeup() 要怎么用Selector不是線程安全的常規(guī)做法是單線程阻塞在select()上所有事件都在這個(gè)線程處理。如果業(yè)務(wù)線程想喚醒這個(gè)線程去執(zhí)行動(dòng)態(tài)注冊(cè)、優(yōu)雅關(guān)閉等操作Selector專門提供wakeup()它會(huì)讓正在阻塞的select()立刻返回。這里有個(gè)細(xì)節(jié)如果在別的線程直接調(diào)用Selector的register()會(huì)因?yàn)閞egister內(nèi)部有鎖而卡住正確做法是先在業(yè)務(wù)線程調(diào)用selector.wakeup()讓select線程醒過(guò)來(lái)再由select線程去執(zhí)行注冊(cè)動(dòng)作。這個(gè)知識(shí)點(diǎn)在寫網(wǎng)關(guān)、框架代碼時(shí)特別有用。4.6 關(guān)閉連接時(shí)key 的清理順序當(dāng)客戶端異常斷開(kāi)read()返回-1要依次做三件事key.cancel()、channel.close()、必要時(shí)在下次select()前處理CancelledKeyException。有人只close通道不cancel雖然通道關(guān)閉后key會(huì)失效但仍可能殘留到select返回集合里。正確的清理邏輯要統(tǒng)一封裝一個(gè)closeChannel方法里面try-catch所有IO異常避免因?yàn)橐粋€(gè)壞連接拖垮整個(gè)事件循環(huán)。尤其是做長(zhǎng)連接服務(wù)時(shí)連接的管理和清理往往比數(shù)據(jù)讀寫更容易出bug。最后說(shuō)點(diǎn)個(gè)人體會(huì)。我最初學(xué)NIO時(shí)也背過(guò)“Selector是干嘛的、Channel是干嘛的”但真正記住知識(shí)點(diǎn)是在自己寫完聊天室demo、又把空輪詢和粘包坑踩過(guò)一遍之后。如果你現(xiàn)在準(zhǔn)備面試核心就那么幾條Buffer的flip/clear、四種事件的含義、selectedKeys為什么必須remove、OP_WRITE為什么不能長(zhǎng)期注冊(cè)。把這些講順暢面試官基本不會(huì)再追問(wèn)深了。如果你準(zhǔn)備上生產(chǎn)再補(bǔ)一層連接生命周期管理和半包處理就夠了。這套內(nèi)容后面還能繼續(xù)往Reactor模型、Netty的EventLoop去擴(kuò)展NIO這塊地基打牢了后面看到那些高大上的并發(fā)框架會(huì)發(fā)現(xiàn)底層邏輯其實(shí)一直是同一套。