聊聊阻塞IO 非阻塞IO 異步IO，你學(xué)會了嗎？
Netty 的高性能架構(gòu)，是基于一個網(wǎng)絡(luò)編程設(shè)計模式 Reactor 進行設(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 連接要花費很長時間進行連接操作，在完成連接的這段時間內(nèi)，它并沒有占用額外的系統(tǒng)資源，但它只能阻塞等待在線程中。這種情況下，系統(tǒng)資源并不能被合理利用。
Java 的 NIO，在 Linux 上底層是使用 epoll 實現(xiàn)的。epoll 是一個高性能的多路復(fù)用 I/O 工具，改進了 select 和 poll 等工具的一些功能。在網(wǎng)絡(luò)編程中，對 epoll 概念的一些理解，幾乎是面試中必問的問題。
epoll 的數(shù)據(jù)結(jié)構(gòu)是直接在內(nèi)核上進行支持的，通過 epoll_create 和 epoll_ctl 等函數(shù)的操作，可以構(gòu)造描述符（fd）相關(guān)的事件組合（event）。
這里有兩個比較重要的概念：
fd 每條連接、每個文件，都對應(yīng)著一個描述符，比如端口號。內(nèi)核在定位到這些連接的時候，就是通過 fd 進行尋址的。
event 當 fd 對應(yīng)的資源，有狀態(tài)或者數(shù)據(jù)變動，就會更新 epoll_item 結(jié)構(gòu)。在沒有事件變更的時候，epoll 就阻塞等待，也不會占用系統(tǒng)資源；一旦有新的事件到來，epoll 就會被激活，將事件通知到應(yīng)用方。
關(guān)于 epoll 還會有一個面試題，相對于 select，epoll 有哪些改進？
你可以這樣回答：
epoll 不再需要像 select 一樣對 fd 集合進行輪詢，也不需要在調(diào)用時將 fd 集合在用戶態(tài)和內(nèi)核態(tài)進行交換；
應(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負責(zé)監(jiān)聽處理新的連接，然后將后續(xù)的事件處理交給 subReactor；
subReactor對事件處理的方式，也由阻塞模式變成了多線程處理，引入了任務(wù)隊列的模式。
面試官可能會問你：為什么我在使用 NIO 時，使用 Channel 進行讀寫，socket 的操作依然是阻塞的？NIO 的作用主要體現(xiàn)在哪里？
這時你可以回答：NIO 只負責(zé)對發(fā)生在 fd 描述符上的事件進行通知。事件的獲取和通知部分是非阻塞的，但收到通知之后的操作，卻是阻塞的，即使使用多線程去處理這些事件，它依然是阻塞的。
AIO 更近一步，將這些對事件的操作也變成非阻塞的。下面是一段典型的 AIO 代碼，它通過注冊 CompletionHandler 回調(diào)函數(shù)進行事件處理。這里的事件是隱藏的，比如 read 函數(shù)，它不僅僅代表 Channel 可讀了，而且會把數(shù)據(jù)自動的讀取到 ByteBuffer 中。等完成了讀取，就會通過回調(diào)函數(shù)通知你，進行后續(xù)的操作。
