也談IO模型

前言

IO模型

網絡程式設計模型

參考資料

說到IO模型，都會牽扯到同步、異步、阻塞、非阻塞這幾個詞。從詞的表面上看，很多人都覺得很容易了解。但是細細一想，卻總會發現有點摸不着頭腦。自己也曾被這幾個詞弄的迷迷糊糊的，每次看相關資料弄明白了，然後很快又給搞混了。經曆過這麼幾次之後，發現這東西必須得有所總結提煉才不至于再次混為一談。尤其是最近看到好幾篇講這個的文章，很多都有謬誤，很容易把本來就搞不清楚的人弄的更加迷糊。

最适合IO模型的例子應該是咱們平常生活中的去餐館吃飯這個場景，下文就結合這個來講解一下經典的幾個IO模型。在此之前，先需要說明以下幾點：

IO有記憶體IO、網絡IO和磁盤IO三種，通常我們說的IO指的是後兩者。

阻塞和非阻塞，是函數/方法的實作方式，即在資料就緒之前是立刻傳回還是等待，即發起IO請求是否會被阻塞。

以檔案IO為例,一個IO讀過程是檔案資料從磁盤→核心緩沖區→使用者記憶體的過程。同步與異步的差別主要在于資料從核心緩沖區→使用者記憶體這個過程需不需要使用者程序等待，即實際的IO讀寫是否阻塞請求程序。(網絡IO把磁盤換做網卡即可)

更新了有關異步非阻塞IO;修正了java aio的說明

去餐館吃飯，點一個自己最愛吃的蓋澆飯，然後在原地等着一直到蓋澆飯做好，自己端到餐桌就餐。這就是典型的同步阻塞。當廚師給你做飯的時候，你需要一直在那裡等着。

網絡程式設計中，讀取用戶端的資料需要調用recvfrom。在預設情況下，這個調用會一直阻塞直到資料接收完畢，就是一個同步阻塞的IO方式。這也是最簡單的IO模型，在通常fd較少、就緒很快的情況下使用是沒有問題的。

接着上面的例子，你每次點完飯就在那裡等着，突然有一天你發現自己真傻。于是，你點完之後，就回桌子那裡坐着，然後估計差不多了，就問老闆飯好了沒，如果好了就去端，沒好的話就等一會再去問，依次循環直到飯做好。這就是同步非阻塞。

這種方式在程式設計中對socket設定O_NONBLOCK即可。但此方式僅僅針對網絡IO有效，對磁盤IO并沒有作用。因為本地檔案IO就沒有被認為是阻塞，我們所說的網絡IO的阻塞是因為網路IO有無限阻塞的可能，而本地檔案除非是被鎖住，否則是不可能無限阻塞的，是以隻有鎖這種情況下，O_NONBLOCK才會有作用。而且，磁盤IO時要麼資料在核心緩沖區中直接可以傳回，要麼需要調用實體裝置去讀取，這時候程序的其他工作都需要等待。是以，後續的IO複用和信号驅動IO對檔案IO也是沒有意義的。

此外，需要說明的一點是nginx和node中對于本地檔案的IO是用線程的方式模拟非阻塞的效果的，而對于靜态檔案的io，使用zero copy(例如sendfile)的效率是非常高的。

接着上面的列子，你點一份飯然後循環的去問好沒好顯然有點得不償失，還不如就等在那裡直到準備好，但是當你點了好幾樣飯菜的時候，你每次都去問一下所有飯菜的狀态(未做好/已做好)肯定比你每次阻塞在那裡等着好多了。當然，你問的時候是需要阻塞的，一直到有準備好的飯菜或者你等的不耐煩(逾時)。這就引出了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。

目前，epoll是Linux2.6下最高效的IO複用方式，也是Nginx、Node的IO實作方式。而在freeBSD下，kqueue是另一種類似于epoll的IO複用方式。

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

水準觸發：當就緒的fd未被使用者程序處理後，下一次查詢依舊會傳回，這是select和poll的觸發方式。

邊緣觸發：無論就緒的fd是否被處理，下一次不再傳回。理論上性能更高，但是實作相當複雜，并且任何意外的丢失事件都會造成請求處理錯誤。epoll預設使用水準觸發，通過相應選項可以使用邊緣觸發。

上文的就餐方式還是需要你每次都去問一下飯菜狀況。于是，你再次不耐煩了，就跟老闆說，哪個飯菜好了就通知我一聲吧。然後就自己坐在桌子那裡幹自己的事情。更甚者，你可以把手機号留給老闆，自己出門，等飯菜好了直接發條短信給你。這就類似信号驅動的IO模型。

流程如下：

開啟套接字信号驅動IO功能

系統調用sigaction執行信号處理函數（非阻塞，立刻傳回）

資料就緒，生成sigio信号，通過信号回調通知應用來讀取資料。

此種io方式存在的一個很大的問題：Linux中信号隊列是有限制的，如果超過這個數字問題就無法讀取資料。

之前的就餐方式，到最後總是需要你自己去把飯菜端到餐桌。這下你也不耐煩了，于是就告訴老闆，能不能飯好了直接端到你的面前或者送到你的家裡(外賣)。這就是異步非阻塞IO了。

對比信号驅動IO，異步IO的主要差別在于：信号驅動由核心告訴我們何時可以開始一個IO操作(資料在核心緩沖區中)，而異步IO則由核心通知IO操作何時已經完成(資料已經在使用者空間中)。

異步IO又叫做事件驅動IO，在Unix中，POSIX1003.1标準為異步方式通路檔案定義了一套庫函數，定義了AIO的一系列接口。使用aio_read或者aio_write發起異步IO操作，使用aio_error檢查正在運作的IO操作的狀态。但是其實作沒有通過核心而是使用了多線程阻塞。此外，還有Linux自己實作的Native AIO，依賴兩個函數：io_submit和io_getevents，雖然io是非阻塞的，但仍需要主動去擷取讀寫的狀态。

需要特别注意的是：AIO是I/O處理模式，是一種接口标準，各家作業系統可以實作也可以不實作。目前Linux中AIO的核心實作隻對檔案IO有效，如果要實作真正的AIO，需要使用者自己來實作。

上文講述了UNIX環境的五種IO模型。基于這五種模型，在Java中，随着NIO和NIO2.0(AIO)的引入，一般具有以下幾種網絡程式設計模型：

BIO

NIO

AIO

BIO是一個典型的網絡程式設計模型，是通常我們實作一個服務端程式的過程，步驟如下：

主線程accept請求阻塞

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

主線程繼續accept下一個請求

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

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的程式設計非常複雜。

JDK1.7引入NIO2.0，提供了異步檔案通道和異步套接字通道的實作。其底層在windows上是通過IOCP，在Linux上是通過epoll來實作的(LinuxAsynchronousChannelProvider.java,UnixAsynchronousServerSocketChannelImpl.java)。

建立AsynchronousServerSocketChannel，綁定監聽端口

調用AsynchronousServerSocketChannel的accpet方法，傳入自己實作的CompletionHandler。包括上一步，都是非阻塞的

連接配接傳入，回調CompletionHandler的completed方法，在裡面，調用AsynchronousSocketChannel的read方法，傳入負責處理資料的CompletionHandler。

資料就緒，觸發負責處理資料的CompletionHandler的completed方法。繼續做下一步處理即可。

寫入操作類似，也需要傳入CompletionHandler。

其程式設計模型相比NIO有了不少的簡化。

.

同步阻塞IO

僞異步IO

用戶端數目 ：IO線程

1 : 1

m : n

m : 1

m : 0

同步非阻塞IO

異步非阻塞IO

吞吐量

低

中

高

程式設計複雜度

簡單

非常複雜

複雜

原文出處：後端技術雜談

<a href="http://www.rowkey.me/blog/2016/01/18/io-model/" target="_blank">原文連結</a>

轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。