IO - 同步，異步，阻塞，非阻塞

當你發現本身最受歡迎的一篇blog其實大錯特錯時，這絕對不是一件讓人愉悅的事。
《 IO - 同步，異步，阻塞，非阻塞 》是我在開始學習epoll和libevent的時候寫的，主要的思路來自於文中的那篇link 。寫完以後發現不少人都很喜歡，我仍是很是開心的，也說明這個問題確實困擾了不少人。隨着學習的深刻，漸漸的感受原來的理解有些誤差，可是仍是沒引發本身的重視，覺着都是一些小錯誤，無傷大雅。直到有位博友問了一個問題，我從新查閱了一些更權威的資料，才發現原來的文章中有很大的理論錯誤。我不知道有多少人已經看過這篇blog並受到了個人誤導，鄙人在此表示抱歉。俺之後寫技術blog會更加嚴謹的。
一度想把原文刪了，最後仍是沒捨得。畢竟每篇blog都花費了很多心血，另外放在那裏也能夠引覺得戒。因此這裏新補一篇。算是亡羊補牢吧。

言歸正傳。
同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什麼，到底有什麼區別？這個問題其實不一樣的人給出的答案均可能不一樣，好比wiki，就認爲asynchronous IO和non-blocking IO是一個東西。這實際上是由於不一樣的人的知識背景不一樣，而且在討論這個問題的時候上下文(context)也不相同。因此，爲了更好的回答這個問題，我先限定一下本文的上下文。
本文討論的背景是Linux環境下的network IO。
本文最重要的參考文獻是Richard Stevens的「UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking 」，6.2節「I/O Models 」，Stevens在這節中詳細說明了各類IO的特色和區別，若是英文夠好的話，推薦直接閱讀。Stevens的文風是有名的深刻淺出，因此不用擔憂看不懂。本文中的流程圖也是截取自參考文獻。

 

Stevens在文章中一共比較了五種IO Model：
    blocking IO
    nonblocking IO
    IO multiplexing
    signal driven IO
    asynchronous IO
因爲signal driven IO在實際中並不經常使用，因此我這隻說起剩下的四種IO Model。

 

咱們首先要肯定一下咱們討論的上下文(context)，那就是Linux的network IO。對於一個網絡IO來講（以read做爲例子），其執行過程一般能夠分爲兩個階段。第一階段，等待數據從網絡中到達，並被拷貝到內核中某個緩衝區(Waiting for the data to be ready)。第二階段，把數據從內核態的緩衝區拷貝到用戶態的應用進程緩衝區來(Copying the data from the kernel to the process)。

再說一下IO發生時涉及的對象和步驟。
對於一個network IO (這裏咱們以read舉例)，它會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另外一個就是系統內核(kernel)。當一個read操做發生時，它會經歷兩個階段：
 1 等待數據準備 (Waiting for the data to be ready)
 2 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)
記住這兩點很重要，由於這些IO Model的區別就是在兩個階段上各有不一樣的狀況。

 

blocking IO
在linux中，默認狀況下全部的socket都是blocking，一個典型的讀操做流程大概是這樣：

 

 

當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來講，不少時候數據在一開始尚未到達（好比，尚未收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，而後kernel返回結果，用戶進程才解除block的狀態，從新運行起來。
因此，blocking IO的特色就是在IO執行的兩個階段都被block了。

 

non-blocking IO

linux下，能夠經過設置socket使其變爲non-blocking。當對一個non-blocking socket執行讀操做時，流程是這個樣子：

 

 

從圖中能夠看出，當用戶進程發出read操做時，若是kernel中的數據尚未準備好，那麼它並不會block用戶進程，而是馬上返回一個error。從用戶進程角度講 ，它發起一個read操做後，並不須要等待，而是立刻就獲得了一個結果。用戶進程判斷結果是一個error時，它就知道數據尚未準備好，因而它能夠再次發送read操做。一旦kernel中的數據準備好了，而且又再次收到了用戶進程的system call，那麼它立刻就將數據拷貝到了用戶內存，而後返回。
因此，用戶進程實際上是須要不斷的主動詢問kernel數據好了沒有。

       默認建立的socket都是阻塞的，非阻塞IO要求socket被設置爲NONBLOCK。注意這裏所說的NIO並不是Java的NIO（New IO）庫

      用戶須要不斷地調用read，嘗試讀取socket中的數據，直到讀取成功後，才繼續處理接收的數據。
整個IO請求的過程當中，雖然用戶線程每次發起IO請求後能夠當即返回，可是爲了等到數據，
仍須要不斷地輪詢、重複請求，消耗了大量的CPU的資源。
通常不多直接使用這種模型，而是在其餘IO模型中使用非阻塞IO這一特性。

 

IO multiplexing

IO multiplexing這個詞可能有點陌生，可是若是我說select，epoll，大概就都能明白了。有些地方也稱這種IO方式爲event driven IO。咱們都知道，select/epoll的好處就在於單個process就能夠同時處理多個網絡鏈接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負責的全部socket，當某個socket有數據到達了，就通知用戶進程。它的流程如圖：

 

 

當用戶進程調用了select，那麼整個進程會被block，而同時，kernel會「監視」全部select負責的socket，當任何一個socket中的數據準備好了，select就會返回。這個時候用戶進程再調用read操做，將數據從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實並無太大的不一樣，事實上，還更差一些。由於這裏須要使用兩個system call (select 和 recvfrom)，而blocking IO只調用了一個system call (recvfrom)。可是，用select的優點在於它能夠同時處理多個connection。（多說一句。因此，若是處理的鏈接數不是很高的話，使用select/epoll的web server不必定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優點並非對於單個鏈接能處理得更快，而是在於能處理更多的鏈接。）使用select之後最大的優點是用戶能夠

在一個線程內同時處理多個socket的IO請求。便可達到在同一個線程內同時處理多個IO請求的目的

在IO multiplexing Model中，實際中，對於每個socket，通常都設置成爲non-blocking，可是，如上圖所示，整個用戶的process實際上是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。

 

此模型用到select和poll函數，這兩個函數也會使進程阻塞，
用戶首先將須要進行IO操做的socket添加到select中，
而後阻塞等待select系統調用返回，select先阻塞，有活動套接字才返回，
可是和阻塞I/O不一樣的是，這兩個函數能夠同時阻塞多個I/O操做，並且能夠同時對多個讀操做，
多個寫操做的I/O函數進行檢測，直到有數據可讀或可寫（就是監聽多個socket）。select被調用後，
進程會被阻塞，內核監視全部select負責的socket，
當有任何一個socket的數據準備好了，select就會返回套接字可讀，咱們就能夠調用recvfrom處理數據。
正由於阻塞I/O只能阻塞一個I/O操做，而I/O複用模型可以阻塞多個I/O操做，因此才叫作多路複用。

 

IO多路複用模型是創建在內核提供的多路分離函數select基礎之上的，使用select函數能夠
避免同步非阻塞IO模型中輪詢等待的問題。
爲了不這裏cpu的空轉，咱們不讓這個線程親自去檢查流中是否有事件，
而是引進了一個代理(一開始是select,後來是poll)，這個代理很牛，
它能夠同時觀察許多流的I/O事件，若是沒有事件，代理就阻塞，線程就不會挨個挨個去輪詢了，
  可是依然有個問題，咱們從select那裏僅僅知道了，有I/O事件發生了，
卻並不知道是哪那幾個流（可能有一個，多個，甚至所有），
咱們只能無差異輪詢全部流，找出能讀出數據，或者寫入數據的流，
對他們進行操做。因此select具備O(n)的無差異輪詢複雜度，
同時處理的流越多，無差異輪詢時間就越長。

epoll能夠理解爲event poll，不一樣於忙輪詢和無差異輪詢，
epoll會把哪一個流發生了怎樣的I/O事件通知咱們。
因此咱們說epoll其實是事件驅動（每一個事件關聯上fd）的，此時咱們對這些流的操做都是有意義的。
（複雜度下降到了O(1)）
能夠看到，select和epoll最大的區別就是：select只是告訴你必定數目的流有事件了，
至於哪一個流有事件，還得你一個一個地去輪詢，而epoll會把發生的事件告訴你，
經過發生的事件，就天然而然定位到哪一個流了。不能不說epoll跟select相比，是質的飛躍，我以爲這也是一種犧牲空間，
換取時間的思想，

 

Asynchronous I/O

linux下的asynchronous IO其實用得不多。先看一下它的流程：

 

 

用戶進程發起read操做以後，馬上就能夠開始去作其它的事。而另外一方面，從kernel的角度，當它受到一個asynchronous read以後，首先它會馬上返回，因此不會對用戶進程產生任何block。而後，kernel會等待數據準備完成，而後將數據拷貝到用戶內存，當這一切都完成以後，kernel會給用戶進程發送一個signal，告訴它read操做完成了。

 

 

到目前爲止，已經將四個IO Model都介紹完了。如今回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。
先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經很明確的說明了這二者的區別。調用blocking IO會一直block住對應的進程直到操做完成，而non-blocking IO在kernel還準備數據的狀況下會馬上返回。

在說明synchronous IO和asynchronous IO的區別以前，須要先給出二者的定義。Stevens給出的定義（實際上是POSIX的定義）是這樣子的：
    A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
    An asynchronous I/O operation does not cause the requesting process to be blocked;
二者的區別就在於synchronous IO作」IO operation」的時候會將process阻塞。按照這個定義，以前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。有人可能會說，non-blocking IO並無被block啊。這裏有個很是「狡猾」的地方，定義中所指的」IO operation」是指真實的IO操做，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，若是kernel的數據沒有準備好，這時候不會block進程。可是，當kernel中數據準備好的時候，recvfrom會將數據從kernel拷貝到用戶內存中，這個時候進程是被block了，在這段時間內，進程是被block的。而asynchronous IO則不同，當進程發起IO 操做以後，就直接返回不再理睬了，直到kernel發送一個信號，告訴進程說IO完成。在這整個過程當中，進程徹底沒有被block。

各個IO Model的比較如圖所示：

 

通過上面的介紹，會發現non-blocking IO和asynchronous IO的區別仍是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，可是它仍然要求進程去主動的check，而且當數據準備完成之後，也須要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則徹底不一樣。它就像是用戶進程將整個IO操做交給了他人（kernel）完成，而後他人作完後發信號通知。在此期間，用戶進程不須要去檢查IO操做的狀態，也不須要主動的去拷貝數據。

最後，再舉幾個不是很恰當的例子來講明這四個IO Model:
有A，B，C，D四我的在釣魚：
A用的是最老式的魚竿，因此呢，得一直守着，等到魚上鉤了再拉桿；
B的魚竿有個功能，可以顯示是否有魚上鉤，因此呢，B就和旁邊的MM聊天，隔會再看看有沒有魚上鉤，有的話就迅速拉桿；
C用的魚竿和B差很少，但他想了一個好辦法，就是同時放好幾根魚竿，而後守在旁邊，一旦有顯示說魚上鉤了，它就將對應的魚竿拉起來；
D是個有錢人，乾脆僱了一我的幫他釣魚，一旦那我的把魚釣上來了，就給D發個短信。

 

I/O多路複用中的select、poll、epoll的區別

epoll跟select都能提供多路I/O複用的解決方案。在如今的Linux內核裏都可以支持，其中epoll是Linux所特有，而select則是POSIX所規定，通常操做系統（包括Windows–Windows也兼容POSIX的較老標準）均有實現。

select：select本質上是經過設置或者檢查存放fd標誌位的數據結構來進行下一步處理。單個進程可監視的fd數量被限制、對socket進行掃描時是採用輪詢的方法致使效率較低。

poll：poll本質上和select沒有區別，但沒有最大鏈接數的限制由於它是基於鏈表來存儲的。

epoll： epoll使用「事件」的就緒通知方式，經過epoll_ctl註冊fd，一旦該fd就緒，內核就會採用相似callback的回調機制來激活該fd，epoll_wait即可以收到通知。由於epoll沒有最大併發鏈接的限制、只有活躍可用的FD纔會調用callback函數使得效率提高、使用mmap內存映射減小複製開銷。