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