事件驅動模型之JAVA

第一部分：

https://www.ibm.com/developerworks/cn/linux/l-cn-edntwk/

有空根據此文章寫一篇java版本

http://blog.sina.com.cn/s/blog_4c8c58ce0102vkbo.html

這篇文章也很好，以上兩篇都講關於高性能網絡服務器

-------------------------------------------------------------------------------------------------------------

第二部分：

事件驅動模型通常是由事件收集器、事件發送器和事件處理器三部分組成基本單元組成。

1、select庫

　　select庫是各個版本的linux和windows平臺都支持的基本事件驅動模型庫，而且在接口的定義上也基本相同，只是部分參數的含義略有差別。

　　使用select庫的通常步驟：建立所關注事件的描述集合。對於一個描述符，能夠關注其上面的讀事件、寫事件以及異常發生事件，因此要建立三類事件描述符集合，分別用來收集讀事件的描述符、寫事件的描述符和異常事件的描述符。

　　其次，調用底層提供的select（）函數，等待事件的發生。select的阻塞與是否設置非阻塞的IO是沒有關係的。

　　而後，輪詢全部事件描述符集合中的每個事件描述符，檢查是否有響應的時間發生，若是有，則進行處理。

nginx服務器在編譯過程當中若是沒有爲其指定其餘高性能事件驅動模型庫，它將自動編譯該庫。

可使用--with-select_module和--without-select_module兩個參數，強制nginx是否編譯該庫。

2、poll庫

　　poll庫，做爲linux平臺上的基本事件驅動模型，Windows平臺不支持poll庫。

　　使用poll庫的通常過程是：與select的基本工做方式是相同的，都是先建立一個關注事件的描述符集合，再去等待這些事件的發生，而後在輪詢描述符集合，檢查有沒有事件發生，若是有，就進行處理。

　　與select的主要區別是select須要爲讀事件、寫事件、異常事件分別建立一個描述符的集合，所以在輪詢的時候，須要分別輪詢這三個集合。而poll庫只需建立一個集合，在每一個描述符對應的結構上分別設置讀事件，寫事件和異常事件，最後輪詢的時候能夠同時檢查這三種事件是否發生。是select庫優化的實現。

 

個人理解：

在java中的channel就是在socket基礎上抽象出來的統一的一層，裏面的內容是包括操做系統底層相關的文件描述符（我的猜想）。所以在jaba中至關於只須要輪詢者一個描述符集合就是咱們的全部客戶端發過來的channel集合，每一個Channel在java中有4個狀態。輪詢的時候輪詢全部的channel(文件描述符集合)。根據你每一個channel不一樣的狀態作出不一樣的操做。這時候就交給操做系統去實現了（poll/epoll）。是select庫的優化實現。

[轉]但select，poll，epoll本質上都是同步I/O，由於他們都須要在讀寫事件就緒後本身負責進行讀寫，也就是說這個讀寫過程是阻塞的

 

這篇文章有示例代碼：http://blog.csdn.net/tianmohust/article/details/6677985/

nginx服務器在編譯過程當中若是沒有爲其指定其餘高性能事件驅動模型庫，它將自動編譯該庫。

可使用--with-poll_module和--without-poll_module兩個參數，強制nginx是否編譯該庫。

3、epoll庫

　　epoll庫是Nginx服務器支持的高性能事件之一，它是公認的很是優秀的時間驅動模型，和poll和select有很大的不一樣，屬於poll庫的一個變種，他們的處理方式都是建立一個待處理事件列表，而後把這個事件列表發送給內核，返回的時候，再去輪詢檢查這個列表，以判斷事件是否發生。若是這樣的描述符在比較多的應用中，效率就顯得低下了，epoll是描述符列表的管理交給內核負責，一旦某種事件發生，內核會把發生事件的描述符列表通知給進程，這樣就避免了輪詢整個描述符列表，epoll庫獲得事件列表，就開始進行事件處理了。

4、其餘事件驅動模型

　　kqueue模型 用於FreeBSD 4.1及以上版本 OpenBSD2.九、NetBSD2.0及Mac os X平臺上。都是經過避免輪詢操做提供效率。該模型同時支持條件觸發（也叫水平觸發，只要知足條件就觸發一個事件）和邊緣觸發（每一個狀態變化時，就觸發一個事件）

　　/dev/poll 主要用在unix衍平生臺的高效事件驅動模型，主要在solaris7 11/99及以上版本 HP/UX11.22以上版本等

　　eventport 模型，用於支持solaris 10及以上版本平臺的高效事件驅動模型。

第二部分轉自：http://www.cnblogs.com/work115/archive/2016/06/16/5590796.html

 

 

---------------------------------------------------------------------------------------------------

第三部分：

關於NIO與TCP三次握手：http://blog.csdn.net/sunmenggmail/article/details/8638480

綜上，我認爲NIO（select poll epoll）將文件描述符（channel）的狀態與TCP三次握手的每一步進行綁定(IO事件)，進行處理，利用事件通知的機制對當前每一個Channel的不一樣狀態進行處理，這個處理過程是異步的。而後具體的channel與buffer的操做能夠提交給一個線程池併發處理去提高性能。這種異步不等於AIO.