Linux IO模型和網絡編程模型

術語概念描述：

IO有內存IO、網絡IO和磁盤IO三種，一般咱們說的IO指的是後二者。

阻塞和非阻塞，是函數/方法的實現方式，即在數據就緒以前是馬上返回仍是等待。

以文件IO爲例,一個IO讀過程是文件數據從磁盤→內核緩衝區→用戶內存的過程。同步與異步的區別主要在於數據從內核緩衝區→用戶內存這個過程需不須要用戶進程等待。有個數據拷貝的過程，是拷貝完再通知仍是在內核緩衝區就通知。(網絡IO把磁盤換作網卡便可)

Linux IO模型

1. 同步阻塞
2. 同步非阻塞
3. IO複用
4. 信號驅動
5. 異步非阻塞

同步阻塞

去餐館吃飯，點一個本身最愛吃的蓋澆飯，而後在原地等着一直到蓋澆飯作好，本身端到餐桌就餐。這就是典型的同步阻塞。當廚師給你作飯的時候，你須要一直在那裏等着。

網絡編程中，讀取客戶端的數據須要調用recvfrom。在默認狀況下，這個調用會一直阻塞直到數據接收完畢，就是一個同步阻塞的IO方式。這也是最簡單的IO模型，在一般fd(文件描述句柄)較少、就緒很快的狀況下使用是沒有問題的。

同步非阻塞

你每次點完飯就在那裏等着，忽然有一天你發現本身真傻。因而，你點完以後，就回桌子那裏坐着，而後估計差很少了，就問老闆飯好了沒，若是好了就去端，沒好的話就等一會再去問，依次循環直到飯作好。這就是同步非阻塞。

這種方式在編程中對socket設置O_NONBLOCK便可。但此方式僅僅針對網絡IO有效，對磁盤IO並無做用。由於本地文件IO就沒有被認爲是阻塞，咱們所說的網絡IO的阻塞是由於網路IO有無限阻塞的可能，而本地文件除非是被鎖住，不然是不可能無限阻塞的，所以只有鎖這種狀況下，O_NONBLOCK纔會有做用。並且，磁盤IO時要麼數據在內核緩衝區中直接能夠返回，要麼須要調用物理設備去讀取，這時候進程的其餘工做都須要等待。所以，後續的IO複用和信號驅動IO對文件IO也是沒有意義的。

IO複用

你點一份飯而後循環的去問好沒好顯然有點得不償失，還不如就等在那裏直到準備好，可是當你點了好幾樣飯菜的時候，你每次都去問一下全部飯菜的狀態(未作好/已作好)確定比你每次阻塞在那裏等着好多了。固然，你問的時候是須要阻塞的，一直到有準備好的飯菜或者你等的不耐煩(超時)。這就引出了IO複用，也叫多路IO就緒通知。這是一種進程預先告知內核的能力，讓內核發現進程指定的一個或多個IO條件就緒了，就通知進程。使得一個進程能在一連串的事件上等待。

IO複用的實現方式目前主要有select、poll和epoll。

select和poll的原理基本相同：

• 註冊待偵聽的fd(這裏的fd建立時最好使用非阻塞)

• 每次調用都去檢查這些fd的狀態，當有一個或者多個fd就緒的時候返回

• 返回結果中包括已就緒和未就緒的fd

相比select，poll解決了單個進程可以打開的文件描述符數量有限制這個問題：select受限於FD_SIZE的限制，若是修改則須要修改這個宏從新編譯內核；而poll經過一個pollfd數組向內核傳遞須要關注的事件，避開了文件描述符數量限制。此外，select和poll共同具備的一個很大的缺點就是包含大量fd的數組被總體複製於用戶態和內核態地址空間之間，開銷會隨着fd數量增多而線性增大。

select和poll就相似於上面說的就餐方式。但當你每次都去詢問時，老闆會把全部你點的飯菜都輪詢一遍再告訴你狀況，當大量飯菜很長時間都不能準備好的狀況下是很低效的。因而，老闆有些不耐煩了，就讓廚師每作好一個菜就記下來他。這樣每次你再去問的時候，他會直接把已經準備好的菜告訴你，你再去端。這就是事件驅動IO就緒通知的方式epoll。

epoll的出現，解決了select、poll的缺點：

• 基於事件驅動的方式，避免了每次都要把全部fd都掃描一遍。

• epoll_wait只返回就緒的fd。

• epoll使用nmap內存映射技術避免了內存複製的開銷。

• epoll的fd數量上限是操做系統的最大文件句柄數目,這個數目通常和內存有關，一般遠大於1024。

總結：

1. select：支持註冊 FD_SETSIZE(1024) 個 socket。
2. poll： poll 做爲 select 的替代者，最大的區別就是，poll 再也不限制 socket 數量。
3. epoll：epoll 能直接返回具體的準備好的通道，時間複雜度 O(1)。

ps：select 和 poll 都有一個共同的問題，那就是它們都只會返回全部通道(channel)，可是不會告訴你具體是哪幾個通道已經就緒。一旦知道有通道準備好之後，須要進行一次掃描，通道少的時候還行，一旦通道的數量是幾十萬個以上的時候，掃描一次的時間複雜度 O(n)。後來才催生了epoll實現。

 

此外，對於IO複用還有一個水平觸發和邊緣觸發的概念：

• 水平觸發：當就緒的fd未被用戶進程處理後，下一次查詢依舊會返回，這是select和poll的觸發方式。

• 邊緣觸發：不管就緒的fd是否被處理，下一次再也不返回。理論上性能更高，可是實現至關複雜，而且任何意外的丟失事件都會形成請求處理錯誤。epoll默認使用水平觸發，經過相應選項可使用邊緣觸發。

信號驅動

上文的就餐方式仍是須要你每次都去問一下飯菜情況。因而，你再次不耐煩了，就跟老闆說，哪一個飯菜好了就通知我一聲吧。而後就本身坐在桌子那裏幹本身的事情。更甚者，你能夠把手機號留給老闆，本身出門，等飯菜好了直接發條短信給你。這就相似信號驅動的IO模型。

流程以下：

• 開啓套接字信號驅動IO功能

• 系統調用sigaction執行信號處理函數（非阻塞，馬上返回）

• 數據就緒（在內核緩衝區），生成sigio信號，經過信號回調通知應用來讀取數據。

異步非阻塞

以前的就餐方式，到最後老是須要你本身去把飯菜端到餐桌。這下你也不耐煩了，因而就告訴老闆，能不能飯好了直接端到你的面前或者送到你的家裏(數據在用戶內存就緒)。這就是異步非阻塞IO了。

對比信號驅動IO，異步IO的主要區別在於：信號驅動由內核告訴咱們什麼時候能夠開始一個IO操做(數據在內核緩衝區中)，而異步IO則由內核通知IO操做什麼時候已經完成(數據已經在用戶空間中)。異步IO又叫作事件驅動IO，在Unix中，POSIX1003.1標準爲異步方式訪問文件定義了一套庫函數，定義了AIO的一系列接口。使用aio_read或者aio_write發起異步IO操做。使用aio_error檢查正在運行的IO操做的狀態。

網絡編程模型

Java的I/O發展簡史：

從JDK1.0到JDK1.3，Java的I/O類庫都很是原始，不少UNIX網絡編程中的概念或者接口在I/O類庫中都沒有體現，例如Pipe、Channel、Buffer和Selector等。2002年發佈JDK1.4時，NIO以JSR-51的身份正式隨JDK發佈。它新增了個java.nio包，提供了不少進行異步I/O開發的API和類庫，主要的類和接口以下。

1. 進行異步I/O操做的緩衝區ByteBuffer等；
2. 進行異步I/O操做的管道Pipe；
3. 進行各類I/O操做（異步或者同步）的Channel，包括ServerSocketChannel和SocketChannel；
4. 多種字符集的編碼能力和解碼能力；
5. 實現非阻塞I/O操做的多路複用器selector；
6. 基於流行的Perl實現的正則表達式類庫；
7. 文件通道FileChannel。

新的NIO類庫的提供，極大地促進了基於Java的異步非阻塞編程的發展和應用，可是，它依然有不完善的地方，特別是對文件系統的處理能力仍顯不足，主要問題以下。

1. 沒有統一的文件屬性（例如讀寫權限）；
2. API能力比較弱，例如目錄的級聯建立和遞歸遍歷，每每須要本身實現；
3. 底層存儲系統的一些高級API沒法使用；
4. 全部的文件操做都是同步阻塞調用，不支持異步文件讀寫操做。

2011年7月28日，JDK1.7正式發佈。它的一個比較大的亮點就是將原來的NIO類庫進行了升級，被稱爲NIO2.0。

NIO2.0由JSR-203演進而來，它主要提供了以下三個方面的改進。

1. 提供可以批量獲取文件屬性的API，這些API具備平臺無關性，不與特性的文件系統相耦合，另外它還提供了標準文件系統的SPI，供各個服務提供商擴展實現；
2. 提供AIO功能，支持基於文件的異步I/O操做和針對網絡套接字的異步操做；
3. 完成JSR-51定義的通道功能，包括對配置和多播數據報的支持等。

上文講述了UNIX環境的五種IO模型。基於這五種模型，在Java中，隨着NIO和NIO2.0(AIO)的引入，通常具備如下幾種網絡編程模型：

1. BIO
2. NIO
3. AIO 

BIO

BIO是一個典型的網絡編程模型，是一般咱們實現一個服務端程序的過程，步驟以下：

• 主線程accept請求阻塞

• 請求到達，建立新的線程來處理這個套接字，完成對客戶端的響應。

• 主線程繼續accept下一個請求

這種模型有一個很大的問題是：當客戶端鏈接增多時，服務端建立的線程也會暴漲，系統性能會急劇降低。所以，在此模型的基礎上，相似於 tomcat的bio connector，採用的是線程池來避免對於每個客戶端都建立一個線程。有些地方把這種方式叫作僞異步IO(把請求拋到線程池中異步等待處理)。

NIO

JDK1.4開始引入了NIO類庫，這裏的NIO指的是Non-blcok IO，主要是使用Selector多路複用器來實現。Selector在Linux等主流操做系統上是經過epoll實現的。

NIO的實現流程，相似於select：

• 建立ServerSocketChannel監聽客戶端鏈接並綁定監聽端口，設置爲非阻塞模式。

• 建立Reactor線程，建立多路複用器(Selector)並啓動線程。

• 將ServerSocketChannel註冊到Reactor線程的Selector上。監聽accept事件。

• Selector在線程run方法中無線循環輪詢準備就緒的Key。

• Selector監聽到新的客戶端接入，處理新的請求，完成tcp三次握手，創建物理鏈接。

• 將新的客戶端鏈接註冊到Selector上，監聽讀操做。讀取客戶端發送的網絡消息。

• 客戶端發送的數據就緒則讀取客戶端請求，進行處理。

相比BIO，NIO的編程很是複雜。

AIO

JDK1.7引入NIO2.0，提供了異步文件通道和異步套接字通道的實現，是真正的異步非阻塞IO, 對應於Unix中的異步IO。

一般會有一個線程池用於執行異步任務，提交任務的線程將任務提交到線程池就能夠立馬返回，沒必要等到任務真正完成。若是想要知道任務的執行結果，一般是經過傳遞一個回調函數任務結束後去調用這個函數(任務結束後去系統調用這個函數)或者Future get(須要用時編碼阻塞獲取)的方式，任務結束後去調用這個函數。一樣的原理，Java 中的異步 IO 也是同樣的，都是由一個線程池來負責執行任務，而後使用回調或本身去查詢結果。異步 IO 主要是爲了控制線程數量，減小過多的線程帶來的內存消耗和 CPU 在線程調度上的開銷。

• 建立AsynchronousServerSocketChannel，綁定監聽端口

• 調用AsynchronousServerSocketChannel的accpet方法，傳入本身實現的CompletionHandler(回調函數)。包括上一步，都是非阻塞的

• 鏈接傳入，回調CompletionHandler的completed方法，在裏面，調用AsynchronousSocketChannel的read方法，傳入負責處理數據的CompletionHandler。

• 數據就緒，觸發負責處理數據的CompletionHandler的completed方法。繼續作下一步處理便可。

• 寫入操做相似，也須要傳入CompletionHandler。

總結