同步（synchronous） IO和異步（asynchronous） IO，阻塞（blocking） IO和非阻塞（non-blocking）IO分別是什么，到底有什么區別？這個(gè)問(wèn)題其實(shí)不同的人給出的答案都可能不同，比如wiki，就認為asynchronous IO和non-blocking IO是一個(gè)東西。這其實(shí)是因為不同的人的知識背景不同，并且在討論這個(gè)問(wèn)題的時(shí)候上下文(context)也不相同。所以，為了更好的回答這個(gè)問(wèn)題，我先限定一下本文的上下文。
本文討論的背景是Linux環(huán)境下的network IO。
本文最重要的參考文獻是Richard Stevens的“UNIX? Network Programming Volume 1, Third Edition: The Sockets Networking ”，6.2節“I/O Models ”，Stevens在這節中詳細說(shuō)明了各種IO的特點(diǎn)和區別，如果英文夠好的話(huà)，推薦直接閱讀。Stevens的文風(fēng)是有名的深入淺出，所以不用擔心看不懂。本文中的流程圖也是截取自參考文獻。
Stevens在文章中一共比較了五種IO Model：
blocking IO
nonblocking IO
IO multiplexing
signal driven IO
asynchronous IO
由于signal driven IO在實(shí)際中并不常用，所以我這只提及剩下的四種IO Model。
再說(shuō)一下IO發(fā)生時(shí)涉及的對象和步驟。
對于一個(gè)network IO (這里我們以read舉例)，它會(huì )涉及到兩個(gè)系統對象，一個(gè)是調用這個(gè)IO的process (or thread)，另一個(gè)就是系統內核(kernel)。當一個(gè)read操作發(fā)生時(shí)，它會(huì )經(jīng)歷兩個(gè)階段：
1 等待數據準備 (Waiting for the data to be ready)
2 將數據從內核拷貝到進(jìn)程中 (Copying the data from the kernel to the process)
記住這兩點(diǎn)很重要，因為這些IO Model的區別就是在兩個(gè)階段上各有不同的情況。
blocking IO
在linux中，默認情況下所有的socket都是blocking，一個(gè)典型的讀操作流程大概是這樣：
當用戶(hù)進(jìn)程調用了recvfrom這個(gè)系統調用，kernel就開(kāi)始了IO的第一個(gè)階段：準備數據。對于network io來(lái)說(shuō)，很多時(shí)候數據在一開(kāi)始還沒(méi)有到達（比如，還沒(méi)有收到一個(gè)完整的UDP包），這個(gè)時(shí)候kernel就要等待足夠的數據到來(lái)。而在用戶(hù)進(jìn)程這邊，整個(gè)進(jìn)程會(huì )被阻塞。當kernel一直等到數據準備好了，它就會(huì )將數據從kernel中拷貝到用戶(hù)內存，然后kernel返回結果，用戶(hù)進(jìn)程才解除block的狀態(tài)，重新運行起來(lái)。
所以，blocking IO的特點(diǎn)就是在IO執行的兩個(gè)階段都被block了。
non-blocking IO
linux下，可以通過(guò)設置socket使其變?yōu)閚on-blocking。當對一個(gè)non-blocking socket執行讀操作時(shí)，流程是這個(gè)樣子：
從圖中可以看出，當用戶(hù)進(jìn)程發(fā)出read操作時(shí)，如果kernel中的數據還沒(méi)有準備好，那么它并不會(huì )block用戶(hù)進(jìn)程，而是立刻返回一個(gè)error。從用戶(hù)進(jìn)程角度講 ，它發(fā)起一個(gè)read操作后，并不需要等待，而是馬上就得到了一個(gè)結果。用戶(hù)進(jìn)程判斷結果是一個(gè)error時(shí)，它就知道數據還沒(méi)有準備好，于是它可以再次發(fā)送read操作。一旦kernel中的數據準備好了，并且又再次收到了用戶(hù)進(jìn)程的system call，那么它馬上就將數據拷貝到了用戶(hù)內存，然后返回。
所以，用戶(hù)進(jìn)程其實(shí)是需要不斷的主動(dòng)詢(xún)問(wèn)kernel數據好了沒(méi)有。
IO multiplexing
IO multiplexing這個(gè)詞可能有點(diǎn)陌生，但是如果我說(shuō)select，epoll，大概就都能明白了。有些地方也稱(chēng)這種IO方式為event driven IO。我們都知道，select/epoll的好處就在于單個(gè)process就可以同時(shí)處理多個(gè)網(wǎng)絡(luò )連接的IO。它的基本原理就是select/epoll這個(gè)function會(huì )不斷的輪詢(xún)所負責的所有socket，當某個(gè)socket有數據到達了，就通知用戶(hù)進(jìn)程。它的流程如圖：
當用戶(hù)進(jìn)程調用了select，那么整個(gè)進(jìn)程會(huì )被block，而同時(shí)，kernel會(huì )“監視”所有select負責的socket，當任何一個(gè)socket中的數據準備好了，select就會(huì )返回。這個(gè)時(shí)候用戶(hù)進(jìn)程再調用read操作，將數據從kernel拷貝到用戶(hù)進(jìn)程。
這個(gè)圖和blocking IO的圖其實(shí)并沒(méi)有太大的不同，事實(shí)上，還更差一些。因為這里需要使用兩個(gè)system call (select 和 recvfrom)，而blocking IO只調用了一個(gè)system call (recvfrom)。但是，用select的優(yōu)勢在于它可以同時(shí)處理多個(gè)connection。（多說(shuō)一句。所以，如果處理的連接數不是很高的話(huà)，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好，可能延遲還更大。select/epoll的優(yōu)勢并不是對于單個(gè)連接能處理得更快，而是在于能處理更多的連接。）
在IO multiplexing Model中，實(shí)際中，對于每一個(gè)socket，一般都設置成為non-blocking，但是，如上圖所示，整個(gè)用戶(hù)的process其實(shí)是一直被block的。只不過(guò)process是被select這個(gè)函數block，而不是被socket IO給block。
Asynchronous I/O
linux下的asynchronous IO其實(shí)用得很少。先看一下它的流程：
用戶(hù)進(jìn)程發(fā)起read操作之后，立刻就可以開(kāi)始去做其它的事。而另一方面，從kernel的角度，當它受到一個(gè)asynchronous read之后，首先它會(huì )立刻返回，所以不會(huì )對用戶(hù)進(jìn)程產(chǎn)生任何block。然后，kernel會(huì )等待數據準備完成，然后將數據拷貝到用戶(hù)內存，當這一切都完成之后，kernel會(huì )給用戶(hù)進(jìn)程發(fā)送一個(gè)signal，告訴它read操作完成了。
到目前為止，已經(jīng)將四個(gè)IO Model都介紹完了?，F在回過(guò)頭來(lái)回答最初的那幾個(gè)問(wèn)題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。
先回答最簡(jiǎn)單的這個(gè)：blocking vs non-blocking。前面的介紹中其實(shí)已經(jīng)很明確的說(shuō)明了這兩者的區別。調用blocking IO會(huì )一直block住對應的進(jìn)程直到操作完成，而non-blocking IO在kernel還準備數據的情況下會(huì )立刻返回。
在說(shuō)明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實(shí)是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”的時(shí)候會(huì )將process阻塞。按照這個(gè)定義，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬于synchronous IO。有人可能會(huì )說(shuō)，non-blocking IO并沒(méi)有被block啊。這里有個(gè)非?！敖苹钡牡胤?，定義中所指的”IO operation”是指真實(shí)的IO操作，就是例子中的recvfrom這個(gè)system call。non-blocking IO在執行recvfrom這個(gè)system call的時(shí)候，如果kernel的數據沒(méi)有準備好，這時(shí)候不會(huì )block進(jìn)程。但是，當kernel中數據準備好的時(shí)候，recvfrom會(huì )將數據從kernel拷貝到用戶(hù)內存中，這個(gè)時(shí)候進(jìn)程是被block了，在這段時(shí)間內，進(jìn)程是被block的。而asynchronous IO則不一樣，當進(jìn)程發(fā)起IO 操作之后，就直接返回再也不理睬了，直到kernel發(fā)送一個(gè)信號，告訴進(jìn)程說(shuō)IO完成。在這整個(gè)過(guò)程中，進(jìn)程完全沒(méi)有被block。
各個(gè)IO Model的比較如圖所示：
經(jīng)過(guò)上面的介紹，會(huì )發(fā)現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然進(jìn)程大部分時(shí)間都不會(huì )被block，但是它仍然要求進(jìn)程去主動(dòng)的check，并且當數據準備完成以后，也需要進(jìn)程主動(dòng)的再次調用recvfrom來(lái)將數據拷貝到用戶(hù)內存。而asynchronous IO則完全不同。它就像是用戶(hù)進(jìn)程將整個(gè)IO操作交給了他人（kernel）完成，然后他人做完后發(fā)信號通知。在此期間，用戶(hù)進(jìn)程不需要去檢查IO操作的狀態(tài)，也不需要主動(dòng)的去拷貝數據。
最后，再舉幾個(gè)不是很恰當的例子來(lái)說(shuō)明這四個(gè)IO Model:
有A，B，C，D四個(gè)人在釣魚(yú)：
A用的是最老式的魚(yú)竿，所以呢，得一直守著(zhù)，等到魚(yú)上鉤了再拉桿；
B的魚(yú)竿有個(gè)功能，能夠顯示是否有魚(yú)上鉤，所以呢，B就和旁邊的MM聊天，隔會(huì )再看看有沒(méi)有魚(yú)上鉤，有的話(huà)就迅速拉桿；
C用的魚(yú)竿和B差不多，但他想了一個(gè)好辦法，就是同時(shí)放好幾根魚(yú)竿，然后守在旁邊，一旦有顯示說(shuō)魚(yú)上鉤了，它就將對應的魚(yú)竿拉起來(lái)；
D是個(gè)有錢(qián)人，干脆雇了一個(gè)人幫他釣魚(yú)，一旦那個(gè)人把魚(yú)釣上來(lái)了，就給D發(fā)個(gè)短信。
聯(lián)系客服
