轉自：http://blog.csdn.net/historyasamirror/article/details/5778378
同步（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。
再說一下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資料好了沒有。
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的優勢并不是對于單個連接配接能處理得更快，而是在于能處理更多的連接配接。）
在IO multiplexing
Model中，實際中，對于每一個socket，一般都設定成為non-blocking，但是，如上圖所示，整個使用者的process其實是一直被
block的。隻不過process是被select這個函數block，而不是被socket IO給block。
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的比較如圖所示：