轉(zhuǎn)自：http://blog.csdn.net/historyasamirror/article/details/5778378

同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什么，到底有什么區(qū)別？這個問題其實不同的人給出的答案都可能不同，比如wiki，就認(rèn)為asynchronous IO和non-blocking IO是一個東西。這其實是因為不同的人的知識背景不同，并且在討論這個問題的時候上下文(context)也不相同。所以，為了更好的回答這個問題，我先限定一下本文的上下文。
本文討論的背景是Linux環(huán)境下的network IO。
本文最重要的參考文獻是Richard Stevens的“UNIX? Network Programming Volume 1, Third Edition: The Sockets Networking?”，6.2節(jié)“I/O Models?”，Stevens在這節(jié)中詳細(xì)說明了各種IO的特點和區(qū)別，如果英文夠好的話，推薦直接閱讀。Stevens的文風(fēng)是有名的深入淺出，所以不用擔(dān)心看不懂。本文中的流程圖也是截取自參考文獻。

?

Stevens在文章中一共比較了五種IO Model：
??? blocking IO
??? nonblocking IO
??? IO multiplexing
??? signal driven IO
??? asynchronous IO
由于signal driven IO在實際中并不常用，所以我這只提及剩下的四種IO Model。

再說一下IO發(fā)生時涉及的對象和步驟。
對于一個network IO (這里我們以read舉例)，它會涉及到兩個系統(tǒng)對象，一個是調(diào)用這個IO的process (or thread)，另一個就是系統(tǒng)內(nèi)核(kernel)。當(dāng)一個read操作發(fā)生時，它會經(jīng)歷兩個階段：
?1 等待數(shù)據(jù)準(zhǔn)備 (Waiting for the data to be ready)
?2 將數(shù)據(jù)從內(nèi)核拷貝到進程中 (Copying the data from the kernel to the process)
記住這兩點很重要，因為這些IO Model的區(qū)別就是在兩個階段上各有不同的情況。

?

blocking IO?
在linux中，默認(rèn)情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：

當(dāng)用戶進程調(diào)用了recvfrom這個系統(tǒng)調(diào)用，kernel就開始了IO的第一個階段：準(zhǔn)備數(shù)據(jù)。對于network io來說，很多時候數(shù)據(jù)在一開始還沒有到達(dá)（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數(shù)據(jù)到來。而在用戶進程這邊，整個進程會被阻塞。當(dāng)kernel一直等到數(shù)據(jù)準(zhǔn)備好了，它就會將數(shù)據(jù)從kernel中拷貝到用戶內(nèi)存，然后kernel返回結(jié)果，用戶進程才解除block的狀態(tài)，重新運行起來。
所以，blocking IO的特點就是在IO執(zhí)行的兩個階段都被block了。

?

non-blocking IO

linux下，可以通過設(shè)置socket使其變?yōu)閚on-blocking。當(dāng)對一個non-blocking socket執(zhí)行讀操作時，流程是這個樣子：

從圖中可以看出，當(dāng)用戶進程發(fā)出read操作時，如果kernel中的數(shù)據(jù)還沒有準(zhǔn)備好，那么它并不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發(fā)起一個read操作后，并不需要等待，而是馬上就得到了一個結(jié)果。用戶進程判斷結(jié)果是一個error時，它就知道數(shù)據(jù)還沒有準(zhǔn)備好，于是它可以再次發(fā)送read操作。一旦kernel中的數(shù)據(jù)準(zhǔn)備好了，并且又再次收到了用戶進程的system call，那么它馬上就將數(shù)據(jù)拷貝到了用戶內(nèi)存，然后返回。
所以，用戶進程其實是需要不斷的主動詢問kernel數(shù)據(jù)好了沒有。

?

IO multiplexing

IO multiplexing這個詞可能有點陌生，但是如果我說select，epoll，大概就都能明白了。有些地方也稱這種IO方式為event driven IO。我們都知道，select/epoll的好處就在于單個process就可以同時處理多個網(wǎng)絡(luò)連接的IO。它的基本原理就是select/epoll這個function會不斷的輪詢所負(fù)責(zé)的所有socket，當(dāng)某個socket有數(shù)據(jù)到達(dá)了，就通知用戶進程。它的流程如圖：

當(dāng)用戶進程調(diào)用了select，那么整個進程會被block，而同時，kernel會“監(jiān)視”所有select負(fù)責(zé)的socket，當(dāng)任何一個socket中的數(shù)據(jù)準(zhǔn)備好了，select就會返回。這個時候用戶進程再調(diào)用read操作，將數(shù)據(jù)從kernel拷貝到用戶進程。
這個圖和blocking IO的圖其實并沒有太大的不同，事實上，還更差一些。因為這里需要使用兩個system call (select 和 recvfrom)，而blocking IO只調(diào)用了一個system call (recvfrom)。但是，用select的優(yōu)勢在于它可以同時處理多個connection。（多說一句。所以，如果處理的連接數(shù)不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優(yōu)勢并不是對于單個連接能處理得更快，而是在于能處理更多的連接。）
在IO multiplexing Model中，實際中，對于每一個socket，一般都設(shè)置成為non-blocking，但是，如上圖所示，整個用戶的process其實是一直被block的。只不過process是被select這個函數(shù)block，而不是被socket IO給block。

?

Asynchronous I/O

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

用戶進程發(fā)起read操作之后，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當(dāng)它受到一個asynchronous read之后，首先它會立刻返回，所以不會對用戶進程產(chǎn)生任何block。然后，kernel會等待數(shù)據(jù)準(zhǔn)備完成，然后將數(shù)據(jù)拷貝到用戶內(nèi)存，當(dāng)這一切都完成之后，kernel會給用戶進程發(fā)送一個signal，告訴它read操作完成了。

?

?

到目前為止，已經(jīng)將四個IO Model都介紹完了。現(xiàn)在回過頭來回答最初的那幾個問題：blocking和non-blocking的區(qū)別在哪，synchronous IO和asynchronous IO的區(qū)別在哪。
先回答最簡單的這個：blocking vs non-blocking。前面的介紹中其實已經(jīng)很明確的說明了這兩者的區(qū)別。調(diào)用blocking IO會一直block住對應(yīng)的進程直到操作完成，而non-blocking IO在kernel還準(zhǔn)備數(shù)據(jù)的情況下會立刻返回。

在說明synchronous IO和asynchronous IO的區(qū)別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：
????A synchronous I/O operation causes the requesting process to be blocked until that?I/O operationcompletes;
??? An asynchronous I/O operation does not cause the requesting process to be blocked;?
兩者的區(qū)別就在于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在執(zhí)行recvfrom這個system call的時候，如果kernel的數(shù)據(jù)沒有準(zhǔn)備好，這時候不會block進程。但是，當(dāng)kernel中數(shù)據(jù)準(zhǔn)備好的時候，recvfrom會將數(shù)據(jù)從kernel拷貝到用戶內(nèi)存中，這個時候進程是被block了，在這段時間內(nèi)，進程是被block的。而asynchronous IO則不一樣，當(dāng)進程發(fā)起IO 操作之后，就直接返回再也不理睬了，直到kernel發(fā)送一個信號，告訴進程說IO完成。在這整個過程中，進程完全沒有被block。

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

經(jīng)過上面的介紹，會發(fā)現(xiàn)non-blocking IO和asynchronous IO的區(qū)別還是很明顯的。在non-blocking IO中，雖然進程大部分時間都不會被block，但是它仍然要求進程去主動的check，并且當(dāng)數(shù)據(jù)準(zhǔn)備完成以后，也需要進程主動的再次調(diào)用recvfrom來將數(shù)據(jù)拷貝到用戶內(nèi)存。而asynchronous IO則完全不同。它就像是用戶進程將整個IO操作交給了他人（kernel）完成，然后他人做完后發(fā)信號通知。在此期間，用戶進程不需要去檢查IO操作的狀態(tài)，也不需要主動的去拷貝數(shù)據(jù)。

最后，再舉幾個不是很恰當(dāng)?shù)睦觼碚f明這四個IO Model:
有A，B，C，D四個人在釣魚：
A用的是最老式的魚竿，所以呢，得一直守著，等到魚上鉤了再拉桿；
B的魚竿有個功能，能夠顯示是否有魚上鉤，所以呢，B就和旁邊的MM聊天，隔會再看看有沒有魚上鉤，有的話就迅速拉桿；
C用的魚竿和B差不多，但他想了一個好辦法，就是同時放好幾根魚竿，然后守在旁邊，一旦有顯示說魚上鉤了，它就將對應(yīng)的魚竿拉起來；
D是個有錢人，干脆雇了一個人幫他釣魚，一旦那個人把魚釣上來了，就給D發(fā)個短信。

阻塞： 如果條件未就緒，'你'必須死等它就緒;進程睡眠
非阻塞：如果條件未就緒，'你'可以轉(zhuǎn)身作別的事情;進程可以作任何想做的事情，不過通常是低效的輪詢。當(dāng)用戶進程發(fā)出read操作時，如果kernel中的數(shù)據(jù)還沒有準(zhǔn)備好，那么它并不會block用戶進程，而是立刻返回一個error。從用戶進程角度講 ，它發(fā)起一個read操作后，并不需要等待，而是馬上就得到了一個結(jié)果。用戶進程判斷結(jié)果是一個error時，它就知道數(shù)據(jù)還沒有準(zhǔn)備好，于是它可以再次發(fā)送read操作，也就是這樣不斷的輪詢

所謂同步，就是在發(fā)出一個功能調(diào)用時，在沒有得到結(jié)果之前，該調(diào)用就不返回。按照這個定義，其實絕大多數(shù)函數(shù)都是同步調(diào)用（例如sin, isdigit等）。但是一般而言，我們在說同步、異步的時候，特指那些需要其他部件協(xié)作或者需要一定時間完成的任務(wù)。最常見的例子就是 SendMessage。該函數(shù)發(fā)送一個消息給某個窗口，在對方處理完消息之前，這個函數(shù)不返回。當(dāng)對方處理完畢以后，該函數(shù)才把消息處理函數(shù)所返回的 LRESULT值返回給調(diào)用者。
異步，就是一個功能調(diào)用，但是數(shù)據(jù)還沒有準(zhǔn)備好，這個進程就去干其他事，直到內(nèi)核給這個進程發(fā)一個信號，線程在去繼續(xù)這個功能調(diào)用

總結(jié)

以上是生活随笔為你收集整理的IO - 同步，异步，阻塞，非阻塞的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。