Java NIO的多路復用及reactor


(from:http://developer.51cto.com/art/201112/306489.htm)

以下描述,為了說明問題,就提提歷史(類似的東西,網上一搜一大把,但是希望你能在這里止步,知道到底是怎么回事。如果還是不清楚,咱就站內溝通!)。

在我(剛)看nio的這段時間里,主要接觸了幾個東西,就是關於server和client。java之前的io完全可以勝任,但是效率不高,為何效率不高呢?

===============history==start===============
//TODO:finish the old style of server and socket data transion.
ServerSocket socket = new ServerSocket(80); 
while (true) { 
final Socket connection = socket.accept(); 
handleRequest(connection); 
}
===============history==end in the future================

在上面的代碼片段中,我們只能是一個request一個的進行處理。這使得所有的請求都阻塞了。如果我們再改變一下,將handleRequest方法封裝到線程中處理:

  1. if(connection = null){ 
  2. new Thread(new Runnable(){ 
  3. public void run(){ 
  4. handleRequest(connection); 
  5. public void handleRequest(Socket conn){ 
  6. //do actions 
  7. }).start(); 

服務器端的資源是有限的,我們這里僅僅是從線程角度來擴展,但是這種處理依然是阻塞的處理方式。首先,僅僅是建立連接(socket),就占用了服務器的線程資源。如果客戶端還沒有發出相應的數據請求,那么服務器就要一直等待他們的數據流過來,然后再進行讀取,如此往復。。。一直都blocking。服務器處在一個高負荷狀態中。

NIO出來之后,進入改革開放時期,有了這么幾個角色,ServerSocketChannel,SelectionKey,Selector。

這幾個角色都是做什么用的呢?需要了解一下reactor模式(反應堆模式)。

作為服務端,如果什么操作都要依賴於客戶端,很多操作都阻塞,如上面的代碼片段所示。reactor模式提供了一種很好的事件處理機制,以分離事件處理對象與事件之間的耦合。如下圖示(詳細請看參考資料(1)):

說明:

Acceptor就是我們Server端的主要任務消化者;

Initiation Dispatcher是事件(Event)的分發者;

HTTP Handler是具體操作人。

首先,在Initiation Dispatcher中注冊一個acceptor(1:register Acceptor),這個Acceptor是跟事件綁定的,它僅僅關心某種事件(event)。

Initiation Dispatcher不斷地循環獲取請求過來的事件(2:handle events),如果發現有對應Acceptor關心的事件(3:connect),通知Acceptor有事件發生(4:new connection)。

Acceptor針對此事件進行處理,創建了新的HTTP Handler((5:create handler))

一輪事件獲取和分發完成。

那么handler是不是就抓住這個connection不放,然后一直苦苦等待數據流的到來呢?

不是的,它也是將自己和自己關心的事件注冊到Initiation Dispatcher。如果Initiation Dispatcher在handle Events時發現了它關心的事件,那么就會交由它去進行相應處理。如下圖示,在連接完成后,browser提交的get請求,handler的處理過程:

這里面尤其要注意到,2:read ready,之后才read request,也就是說,handler在dispatcher中注冊了自己關心的事件(READ),然后在寫的時候,也是類似情況。

以上的過程就實現了非阻塞的處理方式,客戶端的連接可以非阻塞(這是意思是,acceptor不必一直苦苦等候),然后對客戶端過來的request內容,也是非阻塞(這里是不必苦苦等待其數據的到來),都是不必一直眼巴巴的看着那個連接,那些數據,而是如果有我關心的事件了,我再進行處理,期間完全相信Initiation Dispatcher就行了。

這里有一點要注意,就是現在的reactor模式都是建立在操作系統的基礎上實現的,不同的操作系統有不同的實現方式。而且都不支持多線程(針對Initiation Dispatcher而言)。

有了上面的理解之后,來給NIO中的對象跟reactor的對象對個象。

Acceptor:ServerSocketChannel;

Initiation Dispatcher:Selector;

HTTP Handler:針對SocketChannel進行實際處理的個性化對象;

Events:在SelectionKey中:

 

static int OP_ACCEPT 
          Operation-set bit for socket-accept operations.
static int OP_CONNECT 
          Operation-set bit for socket-connect operations.
static int OP_READ 
          Operation-set bit for read operations.
static int OP_WRITE 
          Operation-set bit for write operations.

 

Operation-set bit for write operations. 經過上面的描述,我們就可以寫出基於NIO的非阻塞Server啦。具體的代碼示例大家可以看參考資料

參考資料:

(1)華盛頓大學計算機科學的一篇關於proactor的論文,非常詳細。同時這篇文章中還有 reactor的改進版proactor,各位可以一飽眼福。

(2)簡單的NIO server實現代碼,但是這個代碼中在寫的部分有些瑕疵,各位根據上面的描述,可以考慮一下有何問題。

在這個代碼中,還有一個要注意的地方,就it.remove(),因為某個key在處理過后要刪除,否則,這個key將一直處於active狀態。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM