1. 從一次面試問答說起這三個(gè)IO模型到底在聊什么“AIO、BIO 和 NIO 的區(qū)別是什么”——如果你準(zhǔn)備過頭幾個(gè)月的Java后端面試這個(gè)問題一定不陌生。它幾乎是JVM網(wǎng)絡(luò)編程里最高頻的送分題但有意思的是真正能把三者講透的候選人并不多。大部分人的回答停在“BIO是阻塞的、NIO是非阻塞的、AIO是異步的”這種口訣層面一追問到“為什么Netty不用AIO”“NIO和AIO各自的底層實(shí)現(xiàn)是什么”就露餡了。我先給個(gè)整體定位BIOBlocking I/O、NIONon-blocking I/O、AIOAsynchronous I/O是Java在不同版本和不同應(yīng)用場(chǎng)景下提供給開發(fā)者的三種I/O處理模型。它們解決的問題不一樣設(shè)計(jì)哲學(xué)不一樣適配的業(yè)務(wù)場(chǎng)景也不一樣。實(shí)際項(xiàng)目中大部分常規(guī)Web服務(wù)用的是BIO或者說Servlet容器傳統(tǒng)的連接處理方式高性能網(wǎng)關(guān)、RPC框架底層幾乎都是NIO模型而AIO雖然一度被寄予厚望但在Linux平臺(tái)上的落地表現(xiàn)并不理想反而在Windows上有過一段相對(duì)靠譜的實(shí)現(xiàn)。這篇文章我不只給你對(duì)比表格我會(huì)把三種模型的核心機(jī)制拆開講把“阻塞、非阻塞、異步”這幾個(gè)詞背后的線程模型、系統(tǒng)調(diào)用、底層數(shù)據(jù)結(jié)構(gòu)講清楚再結(jié)合面試場(chǎng)景給你一套可以直接背下來、也能扛住追問的回答框架。無論你是準(zhǔn)備面試的Java開發(fā)還是想搞清楚手頭項(xiàng)目的I/O模型選型這篇文章都適用。2. 先把概念拎清楚阻塞、非阻塞與異步之間不是一回事2.1 “阻塞”和“同步”不是一個(gè)維度上的概念我在面試別人時(shí)發(fā)現(xiàn)一個(gè)高頻誤區(qū)很多人把“同步/異步”和“阻塞/非阻塞”混在一起一上來就說“NIO是異步的”。這個(gè)說法是錯(cuò)的。NIO的全稱是Non-blocking I/O它在本質(zhì)上仍然是同步I/O只是線程不需要一直卡在系統(tǒng)調(diào)用上等待數(shù)據(jù)就緒。要理解AIO和BIO、NIO的區(qū)別第一步就是把這四個(gè)詞拆開。阻塞與非阻塞討論的是“發(fā)起I/O請(qǐng)求的線程在數(shù)據(jù)還沒準(zhǔn)備好之前是否會(huì)被掛起”。阻塞模式下線程發(fā)起read()調(diào)用后如果內(nèi)核緩沖區(qū)里沒有數(shù)據(jù)這個(gè)線程就進(jìn)入等待狀態(tài)直到數(shù)據(jù)到達(dá)才算完非阻塞模式下read()調(diào)用會(huì)立刻返回如果沒有數(shù)據(jù)就返回一個(gè)標(biāo)志比如-1或者0線程可以去做別的事過一會(huì)再來看。同步與異步討論的是“數(shù)據(jù)從內(nèi)核復(fù)制到用戶緩沖區(qū)這一步由誰來完成以及完成之后怎么通知應(yīng)用程序”。同步I/O里真正的數(shù)據(jù)拷貝是發(fā)生在read()/write()系統(tǒng)調(diào)用內(nèi)部的應(yīng)用程序主動(dòng)等這個(gè)調(diào)用返回異步I/O里應(yīng)用程序發(fā)起aio_read()之后立刻返回內(nèi)核把數(shù)據(jù)準(zhǔn)備好并且復(fù)制到用戶緩沖區(qū)之后再通過信號(hào)或回調(diào)函數(shù)通知應(yīng)用“數(shù)據(jù)已經(jīng)到位你直接拿來用就行”。所以組合出來是四種模型同步阻塞BIO就是這一類、同步非阻塞NIO、異步阻塞現(xiàn)實(shí)中幾乎沒有這個(gè)組合因?yàn)楫惒奖旧砭褪桥浜匣卣{(diào)用的、異步非阻塞AIO。BIO、NIO、AIO這三個(gè)簡(jiǎn)稱并不是嚴(yán)格按這個(gè)四象限劃分的Java里它們更多代表了一套完整的API體系和編程范式但搞清楚底層歸屬之后很多困惑就迎刃而解了。2.2 BIO線程死等數(shù)據(jù)一對(duì)一服務(wù)BIO是Java 1.0就有的傳統(tǒng)I/O模型。Socket編程里服務(wù)端用ServerSocket.accept()接受客戶端連接然后為每個(gè)連接分配一個(gè)線程這個(gè)線程從accept()到read()到write()全程阻塞。我來還原一下最經(jīng)典的服務(wù)端代碼長(zhǎng)什么樣ServerSocket serverSocket new ServerSocket(8080); while (true) { Socket socket serverSocket.accept(); // 阻塞在這里直到有客戶端連進(jìn)來 new Thread(() - { InputStream in socket.getInputStream(); BufferedReader reader new BufferedReader(new InputStreamReader(in)); String line; while ((line reader.readLine()) ! null) { // 處理請(qǐng)求 System.out.println(line); } }).start(); }這段代碼的問題顯而易見如果客戶端連接后不發(fā)送數(shù)據(jù)或者發(fā)送得很慢讀線程就會(huì)一直阻塞在readLine()上線程資源被白白占用。一個(gè)線程同時(shí)只能服務(wù)一個(gè)連接而JVM默認(rèn)的線程棧大小是1MB左右即便一臺(tái)服務(wù)器能開的線程數(shù)量有一定彈性當(dāng)連接數(shù)上升到幾千、上萬時(shí)線程切換的開銷和內(nèi)存占用就會(huì)把進(jìn)程拖垮。這個(gè)模型的好處是簡(jiǎn)單、可靠、代碼直觀。對(duì)于連接數(shù)少、單個(gè)連接傳輸數(shù)據(jù)量大的場(chǎng)景比如企業(yè)內(nèi)部管理系統(tǒng)、傳統(tǒng)數(shù)據(jù)庫(kù)連接池BIO反而是最合適的。很多老項(xiàng)目的TCP服務(wù)仍然在用BIO不是因?yàn)樗鼈兟浜蠖且驗(yàn)闃I(yè)務(wù)規(guī)模根本不需要上NIO。2.3 NIO一個(gè)線程輪詢管理大量連接NIO是Java 1.4引入的一套新I/O API核心組件是Channel通道、Buffer緩沖區(qū)、Selector選擇器。和BIO面向流不同NIO面向緩沖區(qū)數(shù)據(jù)總是從Channel讀入Buffer或者從Buffer寫入Channel。最關(guān)鍵的是Selector。它底層在Linux上對(duì)應(yīng)epoll機(jī)制在Windows上對(duì)應(yīng)select機(jī)制作用是讓一個(gè)線程可以同時(shí)監(jiān)控多個(gè)Channel上的I/O事件。當(dāng)某個(gè)Channel上有數(shù)據(jù)可讀、可以寫、有新的連接到達(dá)時(shí)Selector會(huì)返回對(duì)應(yīng)的事件集合線程只需要遍歷這個(gè)集合逐個(gè)處理即可。Selector selector Selector.open(); ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); serverChannel.configureBlocking(false); serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { selector.select(); // 阻塞等待直到至少有一個(gè)事件就緒 SetSelectionKey keys selector.selectedKeys(); IteratorSelectionKey it keys.iterator(); while (it.hasNext()) { SelectionKey key it.next(); if (key.isAcceptable()) { SocketChannel channel serverChannel.accept(); channel.configureBlocking(false); channel.register(selector, SelectionKey.OP_READ); } else if (key.isReadable()) { // 從channel讀取數(shù)據(jù)到buffer } it.remove(); } }就這樣一個(gè)線程就能管理成千上萬個(gè)連接。線程不再死等某一個(gè)連接的數(shù)據(jù)而是空閑時(shí)阻塞在selector.select()上事件到來時(shí)統(tǒng)一處理。這個(gè)模型最大的價(jià)值是省線程連接數(shù)再多線程數(shù)量基本可控系統(tǒng)吞吐量被打通了一個(gè)量級(jí)?，F(xiàn)代高性能網(wǎng)絡(luò)框架的底層基礎(chǔ)就是NIO。Netty的 boss 線程、worker 線程模型本質(zhì)上就是基于NIO事件循環(huán)做擴(kuò)展的。2.4 AIO內(nèi)核全部干完活回調(diào)通知AIO是Java 7引入的異步I/O模型也叫NIO.2。它的設(shè)計(jì)目標(biāo)是更進(jìn)一步應(yīng)用程序發(fā)起一個(gè)異步讀操作之后連“監(jiān)控事件是否就緒”這步都不用管了內(nèi)核把數(shù)據(jù)從socket緩沖區(qū)復(fù)制到用戶緩沖區(qū)之后直接通過回調(diào)或者Future通知應(yīng)用程序去處理。AsynchronousServerSocketChannel server AsynchronousServerSocketChannel.open(); server.bind(new InetSocketAddress(8080)); server.accept(null, new CompletionHandlerAsynchronousSocketChannel, Void() { Override public void completed(AsynchronousSocketChannel channel, Void attachment) { server.accept(null, this); // 繼續(xù)接受下一個(gè)連接 ByteBuffer buffer ByteBuffer.allocate(1024); channel.read(buffer, null, new CompletionHandlerInteger, Void() { Override public void completed(Integer result, Void attachment) { // 數(shù)據(jù)已經(jīng)在內(nèi)核復(fù)制完成后被放到buffer里這里直接處理 } Override public void failed(Throwable exc, Void attachment) { // 處理異常 } }); } Override public void failed(Throwable exc, Void attachment) { // 處理異常 } });這段代碼有兩個(gè)特點(diǎn)一是沒有顯式的select阻塞二是所有I/O的結(jié)果通過CompletionHandler回調(diào)送達(dá)。從編程范式上說AIO是一種事件驅(qū)動(dòng)的異步回調(diào)模型它比NIO更進(jìn)一步把線程從I/O等待中徹底解放出來。理論上是這樣但現(xiàn)實(shí)中AIO在Linux平臺(tái)上的表現(xiàn)讓人一言難盡。Linux內(nèi)核的異步I/O實(shí)現(xiàn)io_uring是現(xiàn)代版本早期的AIO基于epoll模擬成熟度不足Java的AIO實(shí)現(xiàn)底層在Linux上仍然依賴epoll事件通知本質(zhì)上沒有做到真正的內(nèi)核級(jí)異步性能相比NIO沒有明顯優(yōu)勢(shì)反而因?yàn)榛卣{(diào)編程復(fù)雜度更高、調(diào)試更困難導(dǎo)致它在中后端框架中幾乎沒有被廣泛使用。Netty的作者在官方文檔里也表達(dá)過對(duì)AIO的保留態(tài)度這也是Netty在Linux平臺(tái)上仍然堅(jiān)持NIO模型的重要原因。3. 三個(gè)模型的機(jī)制拆解從線程模型到底層系統(tǒng)調(diào)用的完整對(duì)比3.1 線程模型差異一對(duì)一、一對(duì)多、還是完全不需要等我來把三種模型的線程模型放到一起看這是面試時(shí)最直接的答題線索。BIO是“一連接一線程”。建立一個(gè)連接就創(chuàng)建一個(gè)線程線程內(nèi)部從頭到尾處理這個(gè)連接上的所有讀寫。連接數(shù)等于線程數(shù)線程數(shù)受操作系統(tǒng)資源限制一般幾百到幾千就到頭了。這個(gè)模型天然適合短連接、低并發(fā)場(chǎng)景因?yàn)槊總€(gè)連接的存活時(shí)間很短線程復(fù)用率雖然低但創(chuàng)建銷毀線程的成本分?jǐn)傁聛硪策€能接受。NIO是“一線程多連接”。一個(gè)線程運(yùn)行著事件循環(huán)通過Selector同時(shí)管理成千上萬個(gè)連接。事件到來時(shí)才處理沒有事件時(shí)線程阻塞在select調(diào)用上不消耗CPU。這個(gè)模型的核心思想是把“連接”和“處理線程”解耦連接只是注冊(cè)在Selector上的一個(gè)事件源處理線程是共享的。AIO是“連接與線程完全無關(guān)”。應(yīng)用程序發(fā)出讀寫請(qǐng)求后立即返回不需要線程去輪詢或等待數(shù)據(jù)就緒后由內(nèi)核觸發(fā)回調(diào)。如果這時(shí)候一定要給它分配一個(gè)線程概念那么“回調(diào)執(zhí)行線程”是內(nèi)核或框架的線程池提供的業(yè)務(wù)線程本身全程不參與等待。面試官問你“怎么理解線程模型”你直接把這段話梳理清楚回答基本就穩(wěn)了。3.2 底層系統(tǒng)調(diào)用與數(shù)據(jù)結(jié)構(gòu)差異講完線程模型我建議你順帶把底層實(shí)現(xiàn)提一嘴這會(huì)明顯拉開和其他候選人的差距。BIO在Linux上走的是傳統(tǒng)的read()/write()系統(tǒng)調(diào)用配合socket的阻塞模式。進(jìn)程調(diào)用read()后如果數(shù)據(jù)沒有準(zhǔn)備好操作系統(tǒng)會(huì)把這個(gè)進(jìn)程的狀態(tài)設(shè)為睡眠TASK_INTERRUPTIBLE把它掛到socket的等待隊(duì)列上直到數(shù)據(jù)到達(dá)或超時(shí)。這個(gè)過程中CPU被讓出去了線程占用的內(nèi)存大概1MB但是不消耗CPU資源。NIO在Linux上走的是epoll這一組系統(tǒng)調(diào)用。程序先把需要監(jiān)控的文件描述符通過epoll_ctl注冊(cè)到內(nèi)核的事件表里然后調(diào)用epoll_wait阻塞等待。事件表里只要有任何一個(gè)fd就緒epoll_wait就會(huì)返回可處理的事件列表。這里有個(gè)關(guān)鍵區(qū)別epoll返回的是“就緒事件”本身而不需要程序再去遍歷所有連接去挨個(gè)檢查狀態(tài)時(shí)間復(fù)雜度從O(n)降到了O(就緒事件數(shù))。這也是epoll在大規(guī)模連接場(chǎng)景下遠(yuǎn)勝select/poll的地方。AIO在Windows上走的是IOCPInput/Output Completion Port這是Windows內(nèi)核原生的異步I/O實(shí)現(xiàn)完成端口會(huì)在線程池里調(diào)度一個(gè)線程來執(zhí)行完成回調(diào)它的設(shè)計(jì)是完善的。但在Linux上AIO那套系統(tǒng)調(diào)用aio_read()對(duì)socket的支持并不好Java的AIO實(shí)現(xiàn)實(shí)際上往Linux上還是會(huì)落到epoll那一套把“可讀”事件當(dāng)作“異步完成”的替代信號(hào)。所以本質(zhì)上在Linux上跑Java AIO底層依然是NIO的實(shí)現(xiàn)邏輯只是封裝層面多了一層回調(diào)。這個(gè)事實(shí)能解釋為什么AIO在Linux上性能上不去。我把關(guān)鍵差異整理成一張表面試前可以反復(fù)看維度BIONIOAIO全稱Blocking I/ONon-blocking I/OAsynchronous I/O引入版本JDK 1.0JDK 1.4JDK 1.7線程模型一連接一線程一線程多連接Selector異步回調(diào)不需要業(yè)務(wù)線程等待阻塞點(diǎn)read/write/accept全阻塞阻塞于selector.select()無阻塞點(diǎn)數(shù)據(jù)就緒后程序自己去讀程序輪詢就緒事件后自己讀內(nèi)核復(fù)制完成回調(diào)直接拿數(shù)據(jù)底層實(shí)現(xiàn)(Linux)read/write阻塞調(diào)用epoll事件驅(qū)動(dòng)epoll模擬未真正異步底層實(shí)現(xiàn)(Windows)read/write阻塞調(diào)用selectIOCP原生異步適用場(chǎng)景連接數(shù)少、并發(fā)低高并發(fā)、連接數(shù)多、IO密集型高并發(fā)且對(duì)異步編程有明確需求的場(chǎng)景編程復(fù)雜度簡(jiǎn)單中等較高代表框架傳統(tǒng)Servlet容器Netty、Mina、Tomcat NIO模式早期某些文件I/O場(chǎng)景3.3 緩沖區(qū)處理差異流式還是塊式BIO的操作單位是字節(jié)流你從InputStream里一個(gè)字節(jié)一個(gè)字節(jié)讀或者用BufferedReader按行讀數(shù)據(jù)在stream里是連續(xù)流動(dòng)的沒有邊界的概念。這種設(shè)計(jì)對(duì)文本協(xié)議比較友好但網(wǎng)絡(luò)傳輸中的數(shù)據(jù)經(jīng)常是分幀的可能出現(xiàn)半包、粘包問題需要業(yè)務(wù)代碼自己去做邊界判斷。NIO和AIO的操作單位是Buffer數(shù)據(jù)在Channel和Buffer之間批量移動(dòng)。Buffer有很多類型ByteBuffer、CharBuffer、IntBuffer等等其中ByteBuffer用得最多。你在讀數(shù)據(jù)時(shí)需要手動(dòng)控制position當(dāng)前讀寫位置、limit有效數(shù)據(jù)邊界、capacity緩沖區(qū)容量這三個(gè)核心指針讀寫切換時(shí)要調(diào)用flip()、clear()、compact()等方法。這個(gè)設(shè)計(jì)比流式處理復(fù)雜但性能上限也更高因?yàn)閿?shù)據(jù)是按塊而不是按字節(jié)移動(dòng)的減少了系統(tǒng)調(diào)用次數(shù)。舉個(gè)小例子從Channel讀數(shù)據(jù)到Buffer的典型操作ByteBuffer buffer ByteBuffer.allocate(1024); int bytesRead socketChannel.read(buffer); // 內(nèi)核把數(shù)據(jù)拷貝到buffer if (bytesRead 0) { buffer.flip(); // 從寫模式切換為讀模式 while (buffer.hasRemaining()) { System.out.print((char) buffer.get()); } buffer.clear(); // 清空準(zhǔn)備下次寫入 }flip()這句看著簡(jiǎn)單但很多初學(xué)者在這里踩坑。如果不調(diào)用flip()就直接get()讀出來的數(shù)據(jù)可能是空的或者是不完整的數(shù)據(jù)因?yàn)閜osition還停留在寫入的末尾位置讀取操作沒有從有效數(shù)據(jù)起始位置開始。4. 面試場(chǎng)景實(shí)戰(zhàn)如何把回答組織得既有深度又能扛住追問4.1 開場(chǎng)回答概念差異速答面試官問出這個(gè)問題的時(shí)候他首先想聽的是一個(gè)干凈利落的定義性回答。我建議你按這個(gè)順序說“這三個(gè)是Java提供的三種I/O模型。BIO是同步阻塞I/O傳統(tǒng)的Socket編程一個(gè)連接對(duì)應(yīng)一個(gè)線程線程在讀寫時(shí)阻塞并發(fā)能力受限于線程數(shù)量。NIO是同步非阻塞I/O核心是Channel、Buffer、Selector這三件套一個(gè)線程通過Selector管理多個(gè)連接數(shù)據(jù)準(zhǔn)備好后線程再去讀適合高連接數(shù)場(chǎng)景。AIO是異步非阻塞I/O也叫NIO.2應(yīng)用發(fā)起讀寫后立刻返回內(nèi)核完成數(shù)據(jù)復(fù)制后通過回調(diào)通知應(yīng)用進(jìn)一步省掉了線程對(duì)I/O事件的等待。在Linux平臺(tái)上實(shí)際落地效果不如NIO所以Netty等主流框架默認(rèn)不用AIO?！边@段話大概40秒把三種模型的定義、核心機(jī)制、實(shí)際落地差異全說到了。說完之后面試官大概率會(huì)順著往下追問這時(shí)候就到了展示深度的時(shí)候。4.2 被追問“為什么不推薦AIO”時(shí)怎么答這是最容易踩坑的問題。如果你只是簡(jiǎn)單說“AIO性能不如NIO”面試官會(huì)覺得你沒認(rèn)真研究過。正確姿勢(shì)是把原因拆成兩層第一層是Linux內(nèi)核的異步I/O機(jī)制不夠成熟。早期的Linux AIO系統(tǒng)調(diào)用aio_read()對(duì)文件描述符支持有限對(duì)socket支持更差后續(xù)雖然有io_uring這種現(xiàn)代異步框架但Java的運(yùn)行時(shí)和第三方框架并沒有第一時(shí)間跟進(jìn)適配。Java的AIO在Linux上的實(shí)現(xiàn)是繞道epoll模擬出來的既然底層還是epoll那一套那它和NIO的性能差距很難拉開還多了一層回調(diào)封裝的開銷和復(fù)雜度。第二層是編程模型的復(fù)雜性。AIO把控制權(quán)完全交給回調(diào)代碼的執(zhí)行流程變得不連貫異常處理也被分散到failed方法里一旦業(yè)務(wù)邏輯復(fù)雜調(diào)試和排錯(cuò)的成本很高。NIO雖然也復(fù)雜但它的代碼邏輯至少在同一個(gè)線程內(nèi)是順序可讀的出事之后可以通過日志定位到某一次事件處理的循環(huán)里。權(quán)衡下來工程團(tuán)隊(duì)更愿意選擇NIO而不是AIO。4.3 被追問“Netty為什么不用AIO”時(shí)怎么答這個(gè)問題是上一問的延伸但更貼合實(shí)際框架選型。Netty的定位是高性能網(wǎng)絡(luò)應(yīng)用框架它要在所有主流操作系統(tǒng)上提供一致的性能表現(xiàn)。在Windows上AIO有IOCP支撐性能確實(shí)好但在Linux上AIO名不副實(shí)。如果Netty全盤采用AIO就意味著不同平臺(tái)要走兩套底層而且Linux作為服務(wù)器端的主力系統(tǒng)反而表現(xiàn)最弱這不符合Netty的跨平臺(tái)高性能目標(biāo)。另外還要提一個(gè)設(shè)計(jì)點(diǎn)Netty的線程模型是從Reactor模式演化來的事件循環(huán)和NIO的Selector機(jī)制天然契合。NIO的事件驅(qū)動(dòng)模型可以很好地配合Netty的pipeline機(jī)制在框架層面把編解碼、業(yè)務(wù)處理鏈路串聯(lián)起來。AIO的回調(diào)模型雖然也能實(shí)現(xiàn)pipeline但會(huì)把執(zhí)行線程的調(diào)度權(quán)交給操作系統(tǒng)線程池框架對(duì)線程模型的控制力度減弱反而不利于精細(xì)調(diào)優(yōu)。4.4 被追問“BIO、NIO、AIO分別適合什么場(chǎng)景”時(shí)怎么答這個(gè)問題考的是工程判斷力不是背定義。我給的參考回答B(yǎng)IO適合連接數(shù)不多、單連接持續(xù)傳輸?shù)膱?chǎng)景。典型例子是傳統(tǒng)的JDBC連接池連接數(shù)可能只有幾十到幾百每個(gè)連接的使用頻率高線程阻塞等待數(shù)據(jù)庫(kù)響應(yīng)也不是多大的問題。再比如企業(yè)內(nèi)部的管理后臺(tái)、設(shè)備控制網(wǎng)關(guān)這些系統(tǒng)并發(fā)量低用BIO代碼簡(jiǎn)單、穩(wěn)定可靠線上問題也好排查。NIO適合連接數(shù)大、單連接請(qǐng)求頻率不高或者請(qǐng)求量和連接數(shù)不完全匹配的場(chǎng)景。典型例子是網(wǎng)關(guān)服務(wù)、IM長(zhǎng)連接服務(wù)、消息推送服務(wù)。幾萬個(gè)設(shè)備維持一個(gè)TCP長(zhǎng)連接隨時(shí)可能有消息進(jìn)來如果用BIO線程數(shù)根本撐不住NIO的一個(gè)事件循環(huán)線程就能扛住幾萬個(gè)連接的調(diào)度。AIO適合對(duì)異步編程有明確需求且使用Windows平臺(tái)的場(chǎng)景或者某些高吞吐的文件I/O場(chǎng)景。比如基于NIO.2的異步文件讀寫在本地文件復(fù)制、日志寫入這類場(chǎng)景下AIO的表現(xiàn)比NIO直接輪詢要好因?yàn)槲募蘒/O的完成時(shí)間不確定用回調(diào)通知更加自然。但網(wǎng)絡(luò)編程領(lǐng)域AIO在主流服務(wù)器上確實(shí)沒有站穩(wěn)腳跟。4.5 面試官常挖的坑accept()和read()的阻塞細(xì)節(jié)有時(shí)候面試官會(huì)把問題引到具體方法層面比如“accept()是阻塞的嗎那為什么NIO里accept不阻塞”這個(gè)問題很多人在回答時(shí)語義含糊。我來理清楚BIO的ServerSocket.accept()是阻塞的調(diào)用線程會(huì)一直等待直到有客戶端發(fā)起連接。NIO的ServerSocketChannel.accept()默認(rèn)是非阻塞的但在實(shí)際代碼中我們通常先把channel注冊(cè)到Selector上然后調(diào)用selector.select()阻塞等待OP_ACCEPT事件。也就是說NIO里的線程并不是被accept()方法阻塞而是被select()方法阻塞這個(gè)區(qū)別很重要。它意味著線程等待的不再是某一個(gè)連接事件而是一批注冊(cè)好的事件源中任意一個(gè)發(fā)生變化事件粒度從“連接”細(xì)化為“連接、讀、寫、連接關(guān)閉”等具體操作。至于NIO的read操作SocketChannel.read()在非阻塞模式下也會(huì)立即返回如果數(shù)據(jù)沒準(zhǔn)備好就返回0讀到末尾返回-1。處理時(shí)要注意區(qū)分這兩種返回值0表示暫時(shí)沒有數(shù)據(jù)-1表示對(duì)端關(guān)閉了連接邏輯處理完全不同。5. 實(shí)操經(jīng)驗(yàn)手寫一個(gè)簡(jiǎn)易NIO長(zhǎng)連接服務(wù)踩過的坑5.1 從0到1的完整實(shí)現(xiàn)思路光說不練假把式面試之前我強(qiáng)烈建議你親手寫一個(gè)NIO服務(wù)端Demo哪怕只是用來加深理解也值。我來分享一個(gè)我去年寫過的簡(jiǎn)易長(zhǎng)連接服務(wù)包含了服務(wù)端接收連接、處理客戶端數(shù)據(jù)的完整邏輯。先搭骨架一個(gè)ServerSocketChannel監(jiān)聽端口配置為非阻塞模式注冊(cè)到Selector上監(jiān)聽OP_ACCEPT事件循環(huán)里調(diào)用selector.select()等待事件處理可接受事件時(shí)把新的SocketChannel注冊(cè)為OP_READ處理可讀事件時(shí)從Channel讀數(shù)據(jù)到ByteBuffer。我給出一個(gè)可以運(yùn)行的版本去掉異常處理簡(jiǎn)化了代碼但核心流程完整public class NioServer { public static void main(String[] args) throws IOException { Selector selector Selector.open(); ServerSocketChannel server ServerSocketChannel.open(); server.bind(new InetSocketAddress(9000)); server.configureBlocking(false); server.register(selector, SelectionKey.OP_ACCEPT); System.out.println(server start on 9000); while (true) { selector.select(); // 阻塞直到有事件 IteratorSelectionKey keys selector.selectedKeys().iterator(); while (keys.hasNext()) { SelectionKey key keys.next(); keys.remove(); if (key.isAcceptable()) { SocketChannel channel server.accept(); channel.configureBlocking(false); channel.register(selector, SelectionKey.OP_READ); System.out.println(new connection: channel.getRemoteAddress()); } else if (key.isReadable()) { SocketChannel channel (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); int len channel.read(buffer); if (len 0) { buffer.flip(); byte[] bytes new byte[buffer.remaining()]; buffer.get(bytes); System.out.println(receive: new String(bytes)); // 簡(jiǎn)單回顯 ByteBuffer writeBuf ByteBuffer.wrap((ack: new String(bytes)).getBytes()); channel.write(writeBuf); } else if (len -1) { // 對(duì)端關(guān)閉取消key并關(guān)閉channel key.cancel(); channel.close(); } } } } } }5.2 我在寫這個(gè)Demo時(shí)踩過的三個(gè)大坑第一個(gè)坑沒有調(diào)用keys.remove()或者selectedKeys的清理。selector.selectedKeys()返回的是本次事件的就緒集合處理完一個(gè)事件后必須從集合中移除對(duì)應(yīng)的SelectionKey否則下次select()時(shí)這個(gè)key還會(huì)存在于集合里造成重復(fù)處理同一個(gè)事件輕則重復(fù)讀數(shù)據(jù)重則NullPointerException。這是NIO新手最容易犯的問題。第二個(gè)坑對(duì)OP_READ事件處理中read()返回0的情況處理不當(dāng)。只要channel配置為非阻塞模式read()返回0是正?，F(xiàn)象表示當(dāng)前沒有數(shù)據(jù)可讀。我在早期版本里把返回0也當(dāng)作異常去關(guān)閉連接結(jié)果客戶端一空閑就被服務(wù)端斷開。正確的邏輯是len 0就處理數(shù)據(jù)len -1才關(guān)閉連接len 0不做任何事。第三個(gè)坑客戶端數(shù)據(jù)半包的處理。上面這個(gè)Demo在數(shù)據(jù)量很小時(shí)沒問題但當(dāng)客戶端一次性發(fā)送超過1024字節(jié)的數(shù)據(jù)時(shí)一次read()可能只讀走前1024字節(jié)剩下數(shù)據(jù)會(huì)在下次select()時(shí)繼續(xù)觸發(fā)OP_READ。如果業(yè)務(wù)協(xié)議是完整的消息你就需要自己維護(hù)一個(gè)累積緩沖區(qū)把不完整的消息暫存起來等完整幀到達(dá)后再解析。這就是Netty里ByteToMessageDecoder要解決的粘包拆包問題實(shí)際項(xiàng)目中你不會(huì)想自己造的。5.3 用telnet驗(yàn)證服務(wù)的正確姿勢(shì)寫完之后怎么驗(yàn)證最簡(jiǎn)單的辦法是用telnet工具連上去手動(dòng)輸入數(shù)據(jù)telnet 127.0.0.1 9000連上之后隨便輸入一行字符串按下回車服務(wù)端控制臺(tái)會(huì)打印“receive: 你輸入的內(nèi)容”并返回“ack: 你輸入的內(nèi)容”。多開幾個(gè)telnet窗口你會(huì)發(fā)現(xiàn)一個(gè)服務(wù)端線程就能同時(shí)處理所有連接的數(shù)據(jù)。這就是NIO“一個(gè)線程管理多連接”最直觀的體驗(yàn)。如果你所在環(huán)境沒有telnet也可以用Python一行命令臨時(shí)模擬TCP客戶端python3 -c import socket;ssocket.socket();s.connect((127.0.0.1,9000));s.send(bhello);print(s.recv(1024))5.4 如果換成AIO實(shí)現(xiàn)同一個(gè)服務(wù)要怎么寫我把同樣的回顯服務(wù)用AIO重寫了一遍你感受一下編程風(fēng)格的差異public class AIOServer { public static void main(String[] args) throws IOException, InterruptedException { AsynchronousServerSocketChannel server AsynchronousServerSocketChannel.open(); server.bind(new InetSocketAddress(9001)); System.out.println(aio server start on 9001); server.accept(null, new CompletionHandlerAsynchronousSocketChannel, Void() { Override public void completed(AsynchronousSocketChannel channel, Void attachment) { // 立刻為下一個(gè)連接注冊(cè)accept回調(diào) server.accept(null, this); ByteBuffer buffer ByteBuffer.allocate(1024); channel.read(buffer, null, new CompletionHandlerInteger, Void() { Override public void completed(Integer result, Void attachment) { if (result 0) { buffer.flip(); byte[] bytes new byte[buffer.remaining()]; buffer.get(bytes); String msg new String(bytes); System.out.println(receive: msg); channel.write(ByteBuffer.wrap((ack: msg).getBytes())); buffer.clear(); channel.read(buffer, null, this); // 繼續(xù)讀取下一條消息 } } Override public void failed(Throwable exc, Void attachment) { exc.printStackTrace(); } }); } Override public void failed(Throwable exc, Void attachment) { exc.printStackTrace(); } }); Thread.currentThread().join(); // 主線程等待避免進(jìn)程退出 } }AIO代碼的嵌套層級(jí)比NIO深accept成功回調(diào)里套read成功回調(diào)read回調(diào)里套下一次read回調(diào)。邏輯上不復(fù)雜但一旦業(yè)務(wù)步驟變多這個(gè)回調(diào)地獄會(huì)非常難看。這也是工程上更愿意用NIO而不用AIO的另一個(gè)現(xiàn)實(shí)原因代碼的可讀性和可維護(hù)性也是選型的重要考量。6. 常見問題與面試官話術(shù)應(yīng)對(duì)實(shí)錄6.1 “NIO既然是Non-blocking為什么selector.select()還會(huì)阻塞”這是我在面試中最喜歡追問的一個(gè)問題。很多背題型的候選人在這里會(huì)卡殼。答案是NIO的非阻塞指的是“單個(gè)Channel上的I/O操作不阻塞”但Selector的select()方法本身是阻塞的否則線程會(huì)進(jìn)入忙輪詢狀態(tài)CPU占用會(huì)飆升。線程阻塞在select()上等待的是事件通知這個(gè)等待是高效的線程讓出CPU由內(nèi)核在事件發(fā)生時(shí)喚醒它。從整體上看NIO的網(wǎng)絡(luò)I/O線程大部分時(shí)間都處于阻塞等待事件的狀態(tài)這和BIO的線程阻塞有本質(zhì)區(qū)別——BIO阻塞時(shí)只等一個(gè)連接NIO阻塞時(shí)等的是所有注冊(cè)連接的任意事件。6.2 “為什么說AIO是異步的但Java的AIO在Linux上又不算真正的異步”這個(gè)問題的核心在于區(qū)分“API層面的異步”和“操作系統(tǒng)層面的異步”。Java的AIO API提供的是CompletionHandler回調(diào)讓你發(fā)完請(qǐng)求就不用管了從程序員視角確實(shí)是異步編程。但Linux平臺(tái)上的底層實(shí)現(xiàn)并沒有走真正的異步I/O系統(tǒng)調(diào)用而是用epoll事件機(jī)制模擬出來的。真正的異步I/O應(yīng)該由內(nèi)核完成數(shù)據(jù)從內(nèi)核態(tài)到用戶態(tài)的拷貝然后通知應(yīng)用直接使用而Java的AIO在Linux上是內(nèi)核通知“數(shù)據(jù)可讀”應(yīng)用還得自己調(diào)用read()去把數(shù)據(jù)拷貝出來。所以API是異步的底層仍然是同步I/O的流程。6.3 “Tomcat的BIO和NIO模式差別在哪里”Tomcat從8.5/9.0版本開始已經(jīng)徹底移除了BIO模式默認(rèn)是NIO模式。老版本Tomcat的BIO模式里每個(gè)HttpServletRequest對(duì)應(yīng)一個(gè)線程處理線程從socket讀請(qǐng)求行、讀請(qǐng)求頭、讀請(qǐng)求體全程阻塞。連接數(shù)一多線程池打滿后面請(qǐng)求只能排隊(duì)。換到NIO模式后Tomcat的Acceptor線程只負(fù)責(zé)接收連接注冊(cè)到Poller線程監(jiān)控事件Poller發(fā)現(xiàn)可讀事件后把任務(wù)丟給工作線程池處理工作線程在處理業(yè)務(wù)時(shí)才占用等待網(wǎng)絡(luò)數(shù)據(jù)的工作不再占用線程。這解釋了為什么同樣一臺(tái)機(jī)器Tomcat從BIO切到NIO后能支撐的連接數(shù)能提升一個(gè)數(shù)量級(jí)。6.4 “RPC框架的I/O模型選擇有標(biāo)準(zhǔn)答案嗎”理論上RPC框架在網(wǎng)絡(luò)傳輸層都可以用BIO。但實(shí)際的高性能RPC框架比如Dubbo、gRPC這些幾乎都基于NIO實(shí)現(xiàn)原因在于RPC的調(diào)用方通常是海量并發(fā)請(qǐng)求TCP連接的復(fù)用率極高BIO的“一連接一線程”模式會(huì)讓線程數(shù)失控。Dubbo默認(rèn)使用的就是Netty底層是NIO事件循環(huán)。這里有一個(gè)反直覺的點(diǎn)NIO雖然適合高連接數(shù)但單個(gè)連接上的吞吐量并不一定比BIO高因?yàn)镹IO要對(duì)每個(gè)事件做額外調(diào)度和狀態(tài)管理。所以如果你的系統(tǒng)就是單連接、持續(xù)大數(shù)據(jù)傳輸比如文件傳輸服務(wù)BIO或者專門的傳輸協(xié)議反而可能更高效。6.5 會(huì)不會(huì)被問到“IO多路復(fù)用和NIO的關(guān)系”大概率會(huì)被追問。IO多路復(fù)用是操作系統(tǒng)提供的一種能力讓一個(gè)線程同時(shí)監(jiān)控多個(gè)文件描述符的可讀、可寫狀態(tài)select、poll、epoll都是具體的實(shí)現(xiàn)機(jī)制。NIO在Java層的Selector就是IO多路復(fù)用的封裝。更嚴(yán)格地說Java NIO的Selector在Linux上就是epoll的包裝在Mac上則是kqueue的包裝。所以NIO能夠做到“一個(gè)線程管成千上萬連接”本質(zhì)上是IO多路復(fù)用機(jī)制在Java層的體現(xiàn)。而BIO完全沒有使用多路復(fù)用因?yàn)樗恍枰瑫r(shí)監(jiān)控多個(gè)連接——一個(gè)線程只盯著一個(gè)連接的讀事件。AIO在Windows上走IOCP它的邏輯更加接近“異步通知”而不是“多路復(fù)用”但在Linux上的Java實(shí)現(xiàn)又繞回了epoll所以準(zhǔn)確地說AIO的Linux實(shí)現(xiàn)也是多路復(fù)用的變體。7. 給準(zhǔn)備面試的人的最終建議7.1 不要只背結(jié)論要把機(jī)制畫出來我見過很多候選人能把概念表背得滾瓜爛熟但一讓畫圖就露餡。面試前你可以試著在一張紙上畫出三種模型的線程與連接關(guān)系圖BIO是每個(gè)線程拉著一根線連接一個(gè)socketNIO是一個(gè)線程面前放著一個(gè)SelectorSelector連著很多socketAIO是socket直接連著回調(diào)函數(shù)的代碼塊。如果你能自己畫出來說明你是真懂了而不是背了一堆結(jié)論。另外要留意我在面試時(shí)經(jīng)常讓人現(xiàn)場(chǎng)模擬“假設(shè)有個(gè)客戶端連接上來之后每10秒才發(fā)一條消息服務(wù)端線程怎么看”的場(chǎng)景。BIO里那個(gè)線程這10秒就是在阻塞等數(shù)據(jù)白白占用資源NIO里線程在等其它事件這個(gè)連接只是注冊(cè)列表里的一項(xiàng)AIO里壓根沒有線程在等。能把這段場(chǎng)景敘述清楚面試官基本就認(rèn)可你對(duì)三者的理解了。7.2 結(jié)合JDK版本演進(jìn)講亮點(diǎn)更大有個(gè)很討巧的加分技巧把三種模型放進(jìn)JDK版本的時(shí)間線里講。JDK 1.0時(shí)代剛有網(wǎng)絡(luò)編程BIO是唯一選擇。JDK 1.4引入NIO這一版就是為高性能網(wǎng)絡(luò)框架準(zhǔn)備的但早期的NIO API用起來很繁瑣所以Netty這種封裝框架才有生存空間。JDK 7引入AIO本意是提供真正的異步I/O文件I/O場(chǎng)景也好、網(wǎng)絡(luò)I/O場(chǎng)景也好都有更高級(jí)的API可用。但后來Linux平臺(tái)上的網(wǎng)絡(luò)AIO沒有被大規(guī)模采用反而NIO經(jīng)過Netty等框架的深度封裝成了事實(shí)上的標(biāo)準(zhǔn)。JDK 9又開始推進(jìn)異步的、基于流的API設(shè)計(jì)這是更高層面的演進(jìn)方向。把時(shí)間線講出來說明你在系統(tǒng)性理解這個(gè)問題而不只是背了三個(gè)名詞。7.3 最后提醒寫代碼永遠(yuǎn)比背定義管用這篇文章信息量不小但我最想給你留的一句忠告是就算你把所有知識(shí)點(diǎn)都背下來了如果不親手寫一遍NIO服務(wù)端、不讓幾個(gè)客戶端同時(shí)連上來實(shí)測(cè)一把你對(duì)這三者的理解始終是空心的?；ò胄r(shí)把上面那個(gè)Demo跑起來把telnet打開親眼看一兩個(gè)線程扛住幾十個(gè)連接比你在網(wǎng)上看十篇對(duì)比文章都值。面試的時(shí)候如果還能把我上面寫的那些底層原理結(jié)合你跑過的現(xiàn)象來敘述你已經(jīng)超過絕大多數(shù)候選人了。