Netty 的高性能架構(gòu)，是基于一個網(wǎng)絡(luò)編程設(shè)計模式 Reactor 進(jìn)行設(shè)計的?，F(xiàn)在，大多數(shù)與 I/O 相關(guān)的組件，都會使用 Reactor 模型，比如 Tomcat、Redis、Nginx 等，可見 Reactor 應(yīng)用的廣泛性。

Reactor 是 NIO 的基礎(chǔ)。為什么 NIO 的性能就能夠比傳統(tǒng)的阻塞 I/O 性能高呢？我們首先來看一下傳統(tǒng)阻塞式 I/O 的一些特點。

非阻塞 I/O 模型

其實，在處理 I/O 動作時，有大部分時間是在等待。比如，socket 連接要花費很長時間進(jìn)行連接操作，在完成連接的這段時間內(nèi)，它并沒有占用額外的系統(tǒng)資源，但它只能阻塞等待在線程中。這種情況下，系統(tǒng)資源并不能被合理利用。

Java 的 NIO，在 Linux 上底層是使用 epoll 實現(xiàn)的。epoll 是一個高性能的多路復(fù)用 I/O 工具，改進(jìn)了 select 和 poll 等工具的一些功能。在網(wǎng)絡(luò)編程中，對 epoll 概念的一些理解，幾乎是面試中必問的問題。

epoll 的數(shù)據(jù)結(jié)構(gòu)是直接在內(nèi)核上進(jìn)行支持的，通過 epoll_create 和 epoll_ctl 等函數(shù)的操作，可以構(gòu)造描述符（fd）相關(guān)的事件組合（event）。

這里有兩個比較重要的概念：

fd 每條連接、每個文件，都對應(yīng)著一個描述符，比如端口號。內(nèi)核在定位到這些連接的時候，就是通過 fd 進(jìn)行尋址的。

event 當(dāng) fd 對應(yīng)的資源，有狀態(tài)或者數(shù)據(jù)變動，就會更新 epoll_item 結(jié)構(gòu)。在沒有事件變更的時候，epoll 就阻塞等待，也不會占用系統(tǒng)資源；一旦有新的事件到來，epoll 就會被激活，將事件通知到應(yīng)用方。

關(guān)于 epoll 還會有一個面試題，相對于 select，epoll 有哪些改進(jìn)？

你可以這樣回答：

epoll 不再需要像 select 一樣對 fd 集合進(jìn)行輪詢，也不需要在調(diào)用時將 fd 集合在用戶態(tài)和內(nèi)核態(tài)進(jìn)行交換；

應(yīng)用程序獲得就緒 fd 的事件復(fù)雜度，epoll 是 O(1)，select 是 O(n)；

select 最大支持約 1024 個 fd，epoll 支持 65535個；

select 使用輪詢模式檢測就緒事件，epoll 采用通知方式，更加高效。

Reactor 模式

圖片

模型 里面有四個主要元素：

Acceptor處理 client 的連接，并綁定具體的事件處理器；

Event具體發(fā)生的事件，比如圖中sub的read、send等；

Handler執(zhí)行具體事件的處理者，比如處理讀寫事件的具體邏輯；

Reactor將具體的事件分配（dispatch）給 Handler。

mainReactor負(fù)責(zé)監(jiān)聽處理新的連接，然后將后續(xù)的事件處理交給 subReactor；

subReactor對事件處理的方式，也由阻塞模式變成了多線程處理，引入了任務(wù)隊列的模式。

面試官可能會問你：為什么我在使用 NIO 時，使用 Channel 進(jìn)行讀寫，socket 的操作依然是阻塞的？NIO 的作用主要體現(xiàn)在哪里？

這時你可以回答：NIO 只負(fù)責(zé)對發(fā)生在 fd 描述符上的事件進(jìn)行通知。事件的獲取和通知部分是非阻塞的，但收到通知之后的操作，卻是阻塞的，即使使用多線程去處理這些事件，它依然是阻塞的。

AIO 更近一步，將這些對事件的操作也變成非阻塞的。下面是一段典型的 AIO 代碼，它通過注冊 CompletionHandler 回調(diào)函數(shù)進(jìn)行事件處理。這里的事件是隱藏的，比如 read 函數(shù)，它不僅僅代表 Channel 可讀了，而且會把數(shù)據(jù)自動的讀取到 ByteBuffer 中。等完成了讀取，就會通過回調(diào)函數(shù)通知你，進(jìn)行后續(xù)的操作。