引言
同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什麼，到底有什麼區別？這個問題其實不同的人給出的答案都可能不同，比如wiki，就認爲asynchronous IO和non-blocking IO是一個東西。這其實是因爲不同的人的知識背景不同，並且在討論這個問題的時候上下文(context)也不相同。所以，爲了更好的回答這個問題，我先限定一下本文的上下文。本文討論的背景是Linux環境下的network IO。
本文最重要的參考文獻是RichardStevens的“UNIX® Network ProgrammingVolume 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操作兩個階段
再說一下IO發生時涉及的對象和步驟。以read函數舉例，對於一個networkIO會涉及到兩個系統對象，一個是調用這個IO的process (or thread)，另一個就是系統內核(kernel)。當一個read操作發生時，它會經歷兩個階段：
（1）等待數據準備(Waitingfor the data to be ready)
（2）將數據從內核拷貝到進程中(Copyingthe data from the kernel to the process)
記住這兩點很重要，因爲這些IO Model的區別就是在兩個階段上各有不同的情況。是否阻塞說的是第一個階段，即等待數據準備階段是否會阻塞，而是否同步說的是第二階段，即將數據從內核拷貝到進程這個真實的IO Operation操作階段是否阻塞。
阻塞式IO(blocking IO )
在linux中，默認情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：
當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
所以，blocking IO的特點就是在IO執行的兩個階段都被block了。
非阻塞式IO(non-blockingIO)
linux下，可以通過設置socket使其變爲non-blocking。當對一個non-blockingsocket執行讀操作時，流程是這個樣子：
從圖中可以看出，當用戶進程發出read操作時，如果kernel中的數據還沒有準備好，那麼它並不會block用戶進程，而是立刻返回一個error。從用戶進程角度講，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。用戶進程判斷結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦kernel中的數據準備好了，並且又再次收到了用戶進程的system call，那麼它馬上就將數據拷貝到了用戶內存，然後返回。所以，用戶進程其實是需要不斷的主動詢問kernel數據好了沒有。
所以，non-blocking IO的特點就是在IO執行的第一階段不阻塞，若沒準備好即可返回，但是在第二階段即將數據從內核拷貝到進程這個真實的IO Operation操作階段會阻塞。
IO多路複用(IO multiplexing)
IO multiplexing這個詞可能有點陌生，但是如果我說select/epoll，大概就都能明白了。有些地方也稱這種IO方式爲事件驅動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 multiplexingModel中，實際中，對於每一個socket，一般都設置成爲non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數block，而不是被socket IO給block。
所以多路複用IO的特點是引入了select這樣一個過程，阻塞監視多個socket，一旦有某個socket數據準備好了，則返回執行同步IO。
異步IO(AsynchronousI/O)
linux下的asynchronousIO其實用得很少。先看一下它的流程：
用戶進程發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對用戶進程產生任何block。然後，kernel會等待數據準備完成，然後將數據拷貝到用戶內存，當這一切都完成之後，kernel會給用戶進程發送一個signal，告訴它read操作完成了。
所以異步IO的特點是，在IO操作的兩個階段都不會阻塞，而是全權交給操作系統內核來完成，而內核完成後通過信號來通知用戶進程即可。
阻塞 vs 非阻塞
區別在於IO操作的第一階段，調用blockingIO會一直block住對應的進程直到操作完成，而non-blocking IO在kernel還準備數據的情況下會立刻返回。
同步 vs 異步
在說明synchronous IO和asynchronousIO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：
A synchronous I/Ooperation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operationdoes not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，之前所述的blockingIO，non-blocking IO，IO multiplexing都屬於synchronous IO。
有人可能會說，non-blockingIO並沒有被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-blockingIO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，並且當數據準備完成以後，也需要進程主動的再次調用recvfrom來將數據拷貝到用戶內存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然後他人做完後發信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態，也不需要主動的去拷貝數據。
