一、開篇從一個面試場景說起面試官經(jīng)常會拋出一個看似簡單、實則非?？疾斓讓庸Φ椎念}目「說說 BIO、NIO、AIO 的區(qū)別」。很多同學能背出「BIO 是阻塞、NIO 是非阻塞、AIO 是異步非阻塞」但如果繼續(xù)追問「為什么 NIO 是非阻塞的」「底層分別調(diào)用了 Linux 的哪些系統(tǒng)調(diào)用」「Select、Poll、Epoll 有什么區(qū)別」「Reactor 和 Proactor 模式怎么理解」「在 Java 里分別對應(yīng)哪些類」「實際項目中該怎么選型」很多人就開始支支吾吾了。這篇文章會從操作系統(tǒng) I/O 模型出發(fā)結(jié)合Linux 系統(tǒng)調(diào)用、Java 源碼與 API、網(wǎng)絡(luò)編程實戰(zhàn)以及面試高頻追問點把 BIO、NIO、AIO 三者的區(qū)別講透。文章較長建議先收藏再對照代碼逐個實驗。二、先建立認知什么是 I/O 模型在討論 BIO、NIO、AIO 之前必須先搞清楚一個更底層的概念一次網(wǎng)絡(luò) I/O 操作在操作系統(tǒng)層面到底發(fā)生了什么。2.1 一次網(wǎng)絡(luò)讀取的全過程當 Java 程序調(diào)用read()方法讀取網(wǎng)絡(luò)數(shù)據(jù)時整個過程通常分為兩個階段等待數(shù)據(jù)到達數(shù)據(jù)可能還沒有到達網(wǎng)卡或者還在內(nèi)核緩沖區(qū)中應(yīng)用程序需要等待。數(shù)據(jù)從內(nèi)核復制到用戶空間當內(nèi)核緩沖區(qū)準備好數(shù)據(jù)后需要把數(shù)據(jù)從內(nèi)核空間拷貝到用戶進程的緩沖區(qū)中。這兩個階段的處理方式直接決定了 I/O 是「阻塞」還是「非阻塞」、「同步」還是「異步」。這是理解 BIO、NIO、AIO 的核心鑰匙。2.2 兩個關(guān)鍵維度阻塞/非阻塞、同步/異步很多人搞混這兩個概念其實它們是兩個不同維度阻塞與非阻塞關(guān)注的是調(diào)用線程是否被掛起。如果調(diào)用read()后線程必須停下來等待結(jié)果就是阻塞如果read()立即返回一個「現(xiàn)在還沒有數(shù)據(jù)」的狀態(tài)線程可以繼續(xù)干別的事就是非阻塞。同步與異步關(guān)注的是數(shù)據(jù)復制階段由誰來完成、結(jié)果如何通知調(diào)用方。同步 I/O 中數(shù)據(jù)從內(nèi)核復制到用戶空間這個動作是由調(diào)用線程自己或在內(nèi)核替它完成后線程仍需等待結(jié)果完成的異步 I/O 中操作系統(tǒng)完成所有工作后通過回調(diào)或事件主動通知應(yīng)用程序。結(jié)合這兩個維度可以得出經(jīng)典的Unix 五種 I/O 模型阻塞 I/O、非阻塞 I/O、I/O 多路復用、信號驅(qū)動 I/O、異步 I/O。而 Java 中的 BIO、NIO、AIO正是對其中的若干模型的封裝。補充說明嚴格來說「非阻塞 I/O」和「I/O 多路復用」常被統(tǒng)稱為同步非阻塞而 AIO 屬于真正的異步 I/O。NIO 這個名詞在不同語境下含義略有差異稍后會詳細辨析。三、BIO同步阻塞 I/O3.1 BIO 的基本概念BIOBlocking I/O即同步阻塞 I/O是 Java 1.0 時代就有的傳統(tǒng) I/O 模型。在 JDK 1.4 之前Java 的網(wǎng)絡(luò)編程只能使用 BIO。它的典型實現(xiàn)包括java.io包下的流操作以及java.net包下的Socket、ServerSocket。所謂「阻塞」指的是服務(wù)端調(diào)用accept()時如果沒有客戶端連接進來線程會一直阻塞等待?？蛻舳苏{(diào)用read()時如果對端沒有發(fā)送數(shù)據(jù)線程會一直阻塞等待。調(diào)用write()時如果內(nèi)核發(fā)送緩沖區(qū)已滿線程也會阻塞等待。3.2 BIO 服務(wù)端代碼示例下面是一個典型的 BIO 服務(wù)端實現(xiàn)每個客戶端連接都用一個獨立線程處理import java.io.*; import java.net.ServerSocket; import java.net.Socket; public class BioServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(8080); System.out.println(BIO 服務(wù)端啟動監(jiān)聽端口 8080); while (true) { // 1. accept 阻塞直到有客戶端連接 Socket socket serverSocket.accept(); System.out.println(收到客戶端連接 socket.getRemoteSocketAddress()); // 2. 每個連接分配一個獨立線程 new Thread(new ClientHandler(socket)).start(); } } static class ClientHandler implements Runnable { private final Socket socket; ClientHandler(Socket socket) { this.socket socket; } Override public void run() { try (BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter writer new PrintWriter( socket.getOutputStream(), true)) { String line; // 3. readLine 阻塞直到客戶端發(fā)送一行數(shù)據(jù) while ((line reader.readLine()) ! null) { System.out.println(收到消息 line); writer.println(Echo: line); } } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } } }這段代碼的問題非常明顯每來一個連接就要new Thread而readLine()又是阻塞的。當連接數(shù)量增多時線程數(shù)也會線性增長。3.3 BIO 的致命缺陷一連接一線程BIO 最典型的缺陷就是「一個連接一個線程」的模型。具體表現(xiàn)為線程資源耗盡操作系統(tǒng)能創(chuàng)建的線程數(shù)量是有限的幾百上千個連接可能就會導致線程數(shù)爆表。大量線程空轉(zhuǎn)大多數(shù)連接可能長時間沒有數(shù)據(jù)交互但對應(yīng)的線程卻一直阻塞在read()上白白占用內(nèi)存和系統(tǒng)資源。上下文切換開銷大線程數(shù)越多CPU 在線程調(diào)度上的開銷越大真正用于處理業(yè)務(wù)的時間反而減少。為了解決這個問題前輩們又搞出了「線程池 短連接」「偽異步 I/O」等方案但本質(zhì)上仍然是「一個連接在某個時刻占用一個線程」治標不治本。3.4 BIO 的底層系統(tǒng)調(diào)用在 Linux 下BIO 的accept()和read()最終會分別對應(yīng)accept()和recvfrom()系統(tǒng)調(diào)用。當內(nèi)核緩沖區(qū)沒有數(shù)據(jù)時這些系統(tǒng)調(diào)用會阻塞觸發(fā)線程調(diào)度讓當前線程進入等待隊列。直到數(shù)據(jù)到達或者超時線程才會被重新喚醒。所以 BIO 的關(guān)鍵詞是同步、阻塞、實現(xiàn)簡單、可擴展性差。四、NIO同步非阻塞 I/O4.1 名詞辨析NIO 的多重含義提到 NIO需要先澄清一個概念上的容易混淆點。NIO 在不同語境下有兩種含義New I/O指 JDK 1.4 引入的java.nio包提供Channel、Buffer、Selector等全新 API。Non-blocking I/O指非阻塞 I/O 模型。大多數(shù)面試語境下的「NIO」指的是利用Selector實現(xiàn)的I/O 多路復用也叫同步非阻塞模型。下文如無特別說明NIO 均指這一模型。4.2 NIO 的三大核心組件NIO 與傳統(tǒng) BIO 最大的不同在于它引入了三個新組件Channel、Buffer和Selector。4.2.1 Channel通道Channel 可以理解為「雙向的數(shù)據(jù)傳輸通道」它同時支持讀取和寫入。傳統(tǒng)的InputStream和OutputStream是單向的而 Channel 是雙向的。常見的 Channel 有FileChannel文件通道。SocketChannelTCP 客戶端通道。ServerSocketChannelTCP 服務(wù)端通道。DatagramChannelUDP 通道。4.2.2 Buffer緩沖區(qū)BIO 是面向流的數(shù)據(jù)直接從流中讀取而 NIO 是面向緩沖區(qū)的所有數(shù)據(jù)讀寫都必須經(jīng)過 Buffer。Buffer 本質(zhì)上是一塊內(nèi)存包含capacity、position、limit等關(guān)鍵屬性capacity緩沖區(qū)容量創(chuàng)建后不可變。position當前讀寫位置。limit讀寫操作的邊界。常用的 Buffer 有ByteBuffer、CharBuffer等。讀寫數(shù)據(jù)時需要反復調(diào)用flip()、clear()、compact()來切換讀寫模式。4.2.3 Selector選擇器Selector 是 NIO 實現(xiàn)多路復用的核心。它允許一個線程同時監(jiān)控多個 Channel 的就緒狀態(tài)。當某個 Channel 上有可讀、可寫或者連接事件發(fā)生時Selector 會通知應(yīng)用程序應(yīng)用程序再對相應(yīng) Channel 進行處理。通過 Selector可以實現(xiàn)「一個線程處理大量連接」這就是常說的Reactor 模式。4.3 NIO 服務(wù)端代碼示例下面用 NIO 重寫上面的 Echo 服務(wù)端import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.*; import java.nio.charset.StandardCharsets; import java.util.Iterator; import java.util.Set; public class NioServer { public static void main(String[] args) throws IOException { Selector selector Selector.open(); // 1. 打開服務(wù)端通道并綁定端口 ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.bind(new InetSocketAddress(8080)); // 2. 設(shè)置非阻塞模式 serverChannel.configureBlocking(false); // 3. 注冊到 Selector監(jiān)聽連接事件 serverChannel.register(selector, SelectionKey.OP_ACCEPT); System.out.println(NIO 服務(wù)端啟動監(jiān)聽端口 8080); while (true) { // 4. select 阻塞直到至少有一個 Channel 就緒 selector.select(); SetSelectionKey keys selector.selectedKeys(); IteratorSelectionKey iterator keys.iterator(); while (iterator.hasNext()) { SelectionKey key iterator.next(); iterator.remove(); if (key.isAcceptable()) { // 處理新連接 ServerSocketChannel server (ServerSocketChannel) key.channel(); SocketChannel client server.accept(); client.configureBlocking(false); client.register(selector, SelectionKey.OP_READ); System.out.println(收到客戶端連接 client.getRemoteAddress()); } else if (key.isReadable()) { // 處理讀事件 SocketChannel client (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); int len client.read(buffer); if (len -1) { client.close(); continue; } buffer.flip(); String msg StandardCharsets.UTF_8.decode(buffer).toString(); System.out.println(收到消息 msg); // 回寫數(shù)據(jù) ByteBuffer outBuffer StandardCharsets.UTF_8.encode(Echo: msg); client.write(outBuffer); } } } } }這個實現(xiàn)中只有一個主線程通過 Selector 同時管理多個連接。當沒有任何事件就緒時線程阻塞在selector.select()一旦有事件發(fā)生就遍歷就緒的 SelectionKey 進行處理。4.4 NIO 的底層實現(xiàn)Select、Poll、EpollSelector 在 Linux 下的實現(xiàn)經(jīng)歷了從select到poll再到epoll的演進。這是面試中的高頻考點必須掌握4.4.1 select把要監(jiān)聽的 fd 集合從用戶態(tài)拷貝到內(nèi)核態(tài)。內(nèi)核輪詢檢查每個 fd 是否就緒。fd 數(shù)量受FD_SETSIZE限制默認 1024。每次調(diào)用都需要重新拷貝整個 fd 集合開銷大時間復雜度 O(n)。4.4.2 poll用鏈表代替 select 的數(shù)組沒有 1024 數(shù)量限制。但仍然需要遍歷所有 fd仍是 O(n)。4.4.3 epoll通過epoll_ctl注冊 fd內(nèi)核維護就緒事件隊列。通過epoll_wait獲取就緒事件不需要遍歷所有連接。支持ET邊緣觸發(fā)和LT水平觸發(fā)兩種模式。事件驅(qū)動性能不隨連接數(shù)線性下降適合高并發(fā)場景。可以用一句話概括select 和 poll 是「輪詢所有連接」的模型epoll 是「只處理就緒連接」的事件驅(qū)動模型。所以在大規(guī)模并發(fā)下epoll 性能遠優(yōu)于 select 和 poll。4.5 NIO 是否真的是「非阻塞」這是一個經(jīng)典的認知陷阱。NIO 中如果 Channel 配置為非阻塞模式直接調(diào)用read()沒有數(shù)據(jù)時會立即返回 0線程不會被掛起這是真正的非阻塞。但在實際運用多路復用時selector.select()方法本身在沒有事件時仍然會阻塞。不過它阻塞的是「等待事件」而不是「等待某一個連接的數(shù)據(jù)」。因此更準確的說法是NIO 處理單個 Channel 的操作是非阻塞的但 Selector 等待事件的過程是阻塞的。它屬于「同步非阻塞」模型——同步體現(xiàn)在數(shù)據(jù)從內(nèi)核復制到用戶空間時線程仍需要自己去執(zhí)行復制非阻塞體現(xiàn)在線程不用傻等某一個連接的數(shù)據(jù)。五、AIO異步非阻塞 I/O5.1 AIO 的基本概念AIOAsynchronous I/O即異步非阻塞 I/O在 JDK 1.7 中引入對應(yīng)java.nio.channels.AsynchronousSocketChannel、AsynchronousServerSocketChannel等類。AIO 與 NIO 的本質(zhì)區(qū)別在于AIO 中數(shù)據(jù)從內(nèi)核復制到用戶空間的整個 I/O 操作都由操作系統(tǒng)完成應(yīng)用程序發(fā)起請求后可以立即返回去做別的事情當 I/O 完成后操作系統(tǒng)通過回調(diào)函數(shù)或 Future 對象通知應(yīng)用程序。這就是Proactor 模式與 NIO 的Reactor 模式相對應(yīng)。5.2 AIO 服務(wù)端代碼示例下面分別使用Future和回調(diào)函數(shù)兩種方式實現(xiàn) AIO Echo 服務(wù)端幫助大家直觀感受 AIO 的異步處理流程。5.2.1 基于 Future 的 AIO 服務(wù)端首先創(chuàng)建AsynchronousServerSocketChannel循環(huán)調(diào)用accept()獲取Future再通過get()阻塞當前線程直到連接完成。為了保持示例簡單這里的讀取同樣以Future方式同步等待完成。import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.AsynchronousServerSocketChannel; import java.nio.channels.AsynchronousSocketChannel; import java.nio.charset.StandardCharsets; import java.util.concurrent.Future; public class AioFutureServer { public static void main(String[] args) throws Exception { AsynchronousServerSocketChannel server AsynchronousServerSocketChannel.open(); server.bind(new InetSocketAddress(8080)); System.out.println(AIO Future 服務(wù)端啟動監(jiān)聽端口 8080); while (true) { // accept 立即返回 Future FutureAsynchronousSocketChannel future server.accept(); // get 阻塞直到有客戶端連接 AsynchronousSocketChannel client future.get(); System.out.println(收到客戶端連接 client.getRemoteAddress()); // 每個連接交給一個異步讀取任務(wù) handle(client); } } static void handle(AsynchronousSocketChannel client) throws Exception { ByteBuffer buffer ByteBuffer.allocate(1024); while (client.isOpen()) { FutureInteger readFuture client.read(buffer); int len readFuture.get(); if (len -1) { client.close(); return; } buffer.flip(); String msg StandardCharsets.UTF_8.decode(buffer).toString(); buffer.clear(); System.out.println(收到消息 msg); ByteBuffer out StandardCharsets.UTF_8.encode(Echo: msg); client.write(out).get(); } } }Future 方式的優(yōu)點是代碼結(jié)構(gòu)直觀容易理解缺點是get()仍然會阻塞當前線程。如果希望用單線程處理多個連接還需要結(jié)合線程池或反復檢查isDone()。5.2.2 基于 CompletionHandler 回調(diào)的 AIO 服務(wù)端更符合異步思想的是回調(diào)方式給accept()、read()、write()傳入CompletionHandler操作系統(tǒng)完成 I/O 后主動回調(diào)對應(yīng)方法。import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.AsynchronousServerSocketChannel; import java.nio.channels.AsynchronousSocketChannel; import java.nio.channels.CompletionHandler; import java.nio.charset.StandardCharsets; public class AioCallbackServer { public static void main(String[] args) throws Exception { AsynchronousServerSocketChannel server AsynchronousServerSocketChannel.open(); server.bind(new InetSocketAddress(8080)); System.out.println(AIO 回調(diào)服務(wù)端啟動監(jiān)聽端口 8080); server.accept(null, new CompletionHandlerAsynchronousSocketChannel, Object() { Override public void completed(AsynchronousSocketChannel client, Object attachment) { // 繼續(xù)監(jiān)聽下一個連接 server.accept(null, this); System.out.println(收到客戶端連接 client); ByteBuffer buffer ByteBuffer.allocate(1024); client.read(buffer, buffer, new CompletionHandlerInteger, ByteBuffer() { Override public void completed(Integer len, ByteBuffer buffer) { if (len -1) { try { client.close(); } catch (Exception e) { e.printStackTrace(); } return; } buffer.flip(); String msg StandardCharsets.UTF_8.decode(buffer).toString(); System.out.println(收到消息 msg); ByteBuffer out StandardCharsets.UTF_8.encode(Echo: msg); client.write(out, out, new CompletionHandlerInteger, ByteBuffer() { Override public void completed(Integer result, ByteBuffer attachment) { ByteBuffer next ByteBuffer.allocate(1024); client.read(next, next, this); } Override public void failed(Throwable exc, ByteBuffer attachment) { exc.printStackTrace(); try { client.close(); } catch (Exception e) { e.printStackTrace(); } } }); } Override public void failed(Throwable exc, ByteBuffer buffer) { exc.printStackTrace(); try { client.close(); } catch (Exception e) { e.printStackTrace(); } } }); } Override public void failed(Throwable exc, Object attachment) { exc.printStackTrace(); } }); // 阻塞主線程避免程序退出 Thread.currentThread().join(); } }回調(diào)方式完全基于事件驅(qū)動業(yè)務(wù)代碼寫在completed()中。優(yōu)點是沒有線程阻塞缺點是層層嵌套容易形成「回調(diào)地獄」錯誤處理和代碼可讀性較差。5.3 AIO 的底層實現(xiàn)與平臺差異AIO 在不同操作系統(tǒng)上的實現(xiàn)差異很大這也是面試中非常容易追問的點。Windows底層使用IOCPI/O Completion PortI/O 完成端口。這是 Windows 原生的異步 I/O 機制實現(xiàn)非常完善AIO 在 Windows 上性能表現(xiàn)很好。LinuxJDK 的AsynchronousServerSocketChannel和AsynchronousSocketChannel在早期版本底層并不是真正由內(nèi)核異步完成而是通過epoll 線程池模擬異步。也就是說Java 應(yīng)用層看到的是異步 API但內(nèi)核仍在使用多路復用。macOS底層使用Kqueue同樣存在模擬實現(xiàn)的問題。正因為 Linux 下 JDK AIO 的底層實現(xiàn)并不「純粹」再加上易用性和生態(tài)問題實際生產(chǎn)中 Java 高并發(fā)網(wǎng)絡(luò)編程很少直接使用 AIO而是更傾向于 NIO 及其上層框架 Netty。5.4 AIO 的優(yōu)缺點總結(jié)AIO 的優(yōu)點真正的異步非阻塞 I/O讀寫操作由操作系統(tǒng)完成應(yīng)用線程不會阻塞。適合連接數(shù)量很大、單個連接數(shù)據(jù)處理耗時較長的場景。在 Windows 平臺上底層實現(xiàn)完善。AIO 的缺點Linux 上底層實現(xiàn)并非完全異步性能和 NIO epoll 相比沒有壓倒性優(yōu)勢。回調(diào)方式易出現(xiàn)「回調(diào)地獄」代碼結(jié)構(gòu)復雜。Netty、Tomcat 等主流框架長期選擇基于 NIO 構(gòu)建AIO 的生態(tài)相對薄弱。六、BIO、NIO、AIO 三者對比理解完三者的概念后我們用一張表把它們放在一起對比這是回答面試題最核心的表達框架。對比維度BIONIOAIO模型類型同步阻塞同步非阻塞異步非阻塞進程/線程模型一個連接一個線程一個線程處理多連接回調(diào)/事件驅(qū)動數(shù)據(jù)讀寫主體應(yīng)用線程應(yīng)用線程操作系統(tǒng)底層實現(xiàn)accept/recvfromselect/poll/epollIOCP/epoll 模擬編程復雜度簡單較復雜較復雜且易回調(diào)嵌套適用場景低并發(fā)、小規(guī)模連接高并發(fā)、大量連接大量連接且異步友好七、Reactor 與 Proactor 模式7.1 Reactor 模式Reactor反應(yīng)器模式是 NIO 的核心設(shè)計思想通常翻譯為「反應(yīng)堆」。應(yīng)用程序把關(guān)心的事件注冊到 Reactor。Reactor 負責監(jiān)聽事件例如連接建立、可讀、可寫等。事件發(fā)生后Reactor 把就緒的 Channel「分發(fā)」給對應(yīng)的 Handler。Handler 再調(diào)用read()或write()完成實際讀寫。也就是說Reactor 只負責事件分發(fā)實際數(shù)據(jù)讀取仍由應(yīng)用線程完成因此對應(yīng)的是「同步非阻塞」模型。7.2 主從 Reactor 模型在高性能網(wǎng)絡(luò)框架中Reactor 還可以拆分為主 Reactor和從 ReactorMainReactor單獨監(jiān)聽accept事件把新連接注冊到 SubReactor。SubReactor負責監(jiān)聽已建立連接上的讀寫事件并分發(fā)到業(yè)務(wù)線程池。Netty 的bossGroup和workerGroup就是典型的主從 Reactor 模型。7.3 Proactor 模式Proactor前攝器模式對應(yīng) AIO 的設(shè)計思想應(yīng)用程序發(fā)起異步操作把緩沖區(qū)、回調(diào)處理器交給操作系統(tǒng)。操作系統(tǒng)完成數(shù)據(jù)從內(nèi)核到用戶空間的復制后回調(diào)completed()。應(yīng)用線程只處理業(yè)務(wù)結(jié)果不再親自讀取數(shù)據(jù)。Reactor 是「事件就緒后由應(yīng)用線程主動讀」Proactor 是「I/O 完成后由操作系統(tǒng)回調(diào)」這是二者最本質(zhì)的區(qū)別。八、實際項目中如何選型回到最初的問題最實用的部分面試官問區(qū)別本質(zhì)是考察你能否根據(jù)場景做出合理選擇。連接數(shù)不多、業(yè)務(wù)簡單例如內(nèi)部小工具、一次性腳本可以使用 BIO代碼最簡單排查問題也直觀。高并發(fā)、大量長連接例如 IM 網(wǎng)關(guān)、推送服務(wù)、RPC 框架應(yīng)選擇 NIO。實際開發(fā)中通常直接使用基于 NIO 的Netty。少量超大文件的異步讀寫可以考慮AsynchronousFileChannel但網(wǎng)絡(luò)編程中長期使用 AIO 的案例較少。連接數(shù)極大且 Windows 平臺部署AIO 可能是相對合適的選擇但仍然要結(jié)合公司技術(shù)棧和團隊熟悉度。簡而言之默認選擇 NIO/Netty特殊小場景可以用 BIOAIO 了解其思想和 API 即可。九、面試高頻追問與回答思路9.1 為什么 Netty 不用 AIONetty 早期對 AIO 做過實驗最終沒有作為默認實現(xiàn)主要原因有Linux 下 JDK 的 AIO 底層是 epoll 線程池模擬性能提升不明顯。NIO epoll 已經(jīng)足夠快且 Netty 在此基礎(chǔ)上做了零拷貝、對象池、主從 Reactor 等大量優(yōu)化。AIO 回調(diào)模型在復雜協(xié)議處理中不如 Reactor 模型易于控制。9.2 select、poll、epoll 的核心區(qū)別回答要點select 有 1024 上限且每次都要復制 fd 集合poll 用鏈表去掉了數(shù)量限制但仍需輪詢epoll 通過就緒事件隊列實現(xiàn)事件驅(qū)動只返回就緒 fd并支持 ET/LT 模式適合高并發(fā)。9.3 阻塞、非阻塞、同步、異步究竟怎么區(qū)分回答要點阻塞/非阻塞看「線程是否被掛起」同步/異步看「數(shù)據(jù)復制由誰完成、結(jié)果如何通知」。BIO 同步阻塞NIO 同步非阻塞AIO 異步非阻塞。9.4 讀返回 0、-1 分別代表什么在 NIO 非阻塞模式下read()返回 0 表示當前沒有數(shù)據(jù)返回 -1 表示對端已經(jīng)關(guān)閉連接。這是網(wǎng)絡(luò)編程中非常容易忽略的細節(jié)。十、總結(jié)BIO、NIO、AIO 的區(qū)別表面上考察名詞解釋實際上覆蓋了操作系統(tǒng) I/O 模型、Linux 系統(tǒng)調(diào)用、Java API 設(shè)計和網(wǎng)絡(luò)編程實踐。可以從一條主線串聯(lián)起來BIO一個連接一個線程阻塞等待數(shù)據(jù)實現(xiàn)簡單但擴展性差。NIO通過 Channel、Buffer、Selector 實現(xiàn)多路復用一個線程管理大量連接底層是 select/poll/epoll。AIO真正把 I/O 交給操作系統(tǒng)完成通過回調(diào)或 Future 通知應(yīng)用底層在 Windows 上是 IOCP在 Linux 上早期為 epoll 模擬。理解這些還只是起點更值得繼續(xù)深入的是Netty 的主從 Reactor 實現(xiàn)、epoll 的 ET/LT 模式、零拷貝以及Java NIO 源碼。把這些串聯(lián)起來面試時才能從「背概念」升級到「講原理、講選型、講實戰(zhàn)」。