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