Reactor 是 NIO 的基礎。為什么 NIO 的性能就能夠比傳統的阻塞 I/O 性能高呢?我們首先來看一下傳統阻塞式 I/O 的一些特點。
非阻塞 I/O 模型
其實,在處理 I/O 動作時,有大部分時間是在等待。比如,socket 連接要花費很長時間進行連接操作,在完成連接的這段時間內,它并沒有占用額外的系統資源,但它只能阻塞等待在線程中。這種情況下,系統資源并不能被合理利用。
JAVA 的 NIO,在 linux 上底層是使用 epoll 實現的。epoll 是一個高性能的多路復用 I/O 工具,改進了 select 和 poll 等工具的一些功能。在網絡編程中,對 epoll 概念的一些理解,幾乎是面試中必問的問題。
epoll 的數據結構是直接在內核上進行支持的,通過 epoll_create 和 epoll_ctl 等函數的操作,可以構造描述符(fd)相關的事件組合(event)。
這里有兩個比較重要的概念:
fd 每條連接、每個文件,都對應著一個描述符,比如端口號。內核在定位到這些連接的時候,就是通過 fd 進行尋址的。
event 當 fd 對應的資源,有狀態或者數據變動,就會更新 epoll_item 結構。在沒有事件變更的時候,epoll 就阻塞等待,也不會占用系統資源;一旦有新的事件到來,epoll 就會被激活,將事件通知到應用方。
關于 epoll 還會有一個面試題,相對于 select,epoll 有哪些改進?
你可以這樣回答:
epoll 不再需要像 select 一樣對 fd 集合進行輪詢,也不需要在調用時將 fd 集合在用戶態和內核態進行交換;
應用程序獲得就緒 fd 的事件復雜度,epoll 是 O(1),select 是 O(n);
select 最大支持約 1024 個 fd,epoll 支持 65535個;
select 使用輪詢模式檢測就緒事件,epoll 采用通知方式,更加高效。
Reactor 模式
模型 里面有四個主要元素:
Acceptor處理 client 的連接,并綁定具體的事件處理器;
Event具體發生的事件,比如圖中sub的read、send等;
Handler執行具體事件的處理者,比如處理讀寫事件的具體邏輯;
Reactor將具體的事件分配(dispatch)給 Handler。
mAInReactor負責監聽處理新的連接,然后將后續的事件處理交給 subReactor;
subReactor對事件處理的方式,也由阻塞模式變成了多線程處理,引入了任務隊列的模式。
面試官可能會問你:為什么我在使用 NIO 時,使用 Channel 進行讀寫,socket 的操作依然是阻塞的?NIO 的作用主要體現在哪里?
這時你可以回答:NIO 只負責對發生在 fd 描述符上的事件進行通知。事件的獲取和通知部分是非阻塞的,但收到通知之后的操作,卻是阻塞的,即使使用多線程去處理這些事件,它依然是阻塞的。
AIO 更近一步,將這些對事件的操作也變成非阻塞的。下面是一段典型的 AIO 代碼,它通過注冊 CompletionHandler 回調函數進行事件處理。這里的事件是隱藏的,比如 read 函數,它不僅僅代表 Channel 可讀了,而且會把數據自動的讀取到 ByteBuffer 中。等完成了讀取,就會通過回調函數通知你,進行后續的操作。