同步與阻塞，異步與非阻塞的區別

時間 2019-11-12

標籤同步阻塞異步區別简体版

原文原文鏈接

同步與異步是對應的，它們是線程之間的關係，兩個線程之間要麼是同步的，要麼是異步的。

阻塞與非阻塞是對同一個線程來講的，在某個時刻，線程要麼處於阻塞，要麼處於非阻塞。

阻塞是使用同步機制的結果，非阻塞則是使用異步機制的結果。

處理大併發之一對異步非阻塞的理解

在研究nginx和node.js的時候常會遇到異步、非阻塞等，以前本身也常用epoll，對其同步與阻塞，異步與非阻塞有了必定的認識，現對參考資料總結下。node

首先討論下使用事件驅動，異步編程的優勢：linux

充分利用了系統資源，執行代碼無須阻塞等待某種操做完成，有限的資源能夠用於其餘的任務。其很是適合於後端的網絡服務編程。nginx

在服務器開發中，併發的請求處理是個大問題，阻塞式的函數會致使資源浪費和時間延遲。經過事件註冊、異步函數，開發人員能夠提升資源的利用率，性能也會改善。其nginx和node.js處理併發都是採用的事件驅動異步非阻塞模式。其中nginx中處理併發用的是epoll，poll,queue等方式，node.js使用的是libev，它們對大規模的HTTP請求處理的都很好。web

阻塞

《node.js開發指南》是這樣定義的：線程在執行中若是遇到（I/O 操做）如磁盤讀寫或網絡通訊，一般要耗費較長的時間，這時操做系統會剝奪這個線程的 CPU 控制權，使其暫停執行，同時將資源讓給其餘的工做線程，這種線程調度方式稱爲阻塞。當 I/O 操做完畢時，操做系統將這個線程的阻塞狀態解除，恢復其對CPU的控制權，令其繼續執行。這種 I/O 模式就是一般的同步式 I/O（Synchronous I/O）或阻塞式 I/O（Blocking I/O）。編程

非阻塞

非阻塞是這樣定義的，當線程遇到 I/O 操做時，不會以阻塞的方式等待 I/O 操做的完成或數據的返回，而只是將 I/O 請求發送給操做系統，繼續執行下一條語句。當操做系統完成 I/O 操做時，以事件的形式通知執行 I/O 操做的線程，線程會在特定時候處理這個事件。後端

對比阻塞與非阻塞

阻塞模式下，一個線程只能處理一項任務，要想提升吞吐量必須經過多線程。服務器

非阻塞模式下，一個線程永遠在執行計算操做，這個線程所使用的 CPU 核心利用率永遠是 100%，I/O 以事件的方式通知。網絡

在阻塞模式下，多線程每每能提升系統吞吐量，由於一個線程阻塞時還有其餘線程在工做，多線程可讓 CPU 資源不被阻塞中的線程浪費。多線程

而在非阻塞模式下，線程不會被 I/O 阻塞，永遠在利用 CPU。多線程帶來的好處僅僅是在多核 CPU 的狀況下利用更多的核。併發

來看看《深刻淺出Node.js》對異步I/O的解釋，在操做系統中，程序運行的空間分爲內核空間和用戶空間。咱們經常提起的異步I/O，其實質是用戶空間中的程序不用依賴內核空間中的I/O操做實際完成，便可進行後續任務。

I/O的阻塞與非阻塞的解釋

阻塞模式的I/O會形成應用程序等待，直到I/O完成。同時操做系統也支持將I/O操做設置爲非阻塞模式，這時應用程序的調用將可能在沒有拿到真正數據時就當即返回了，爲此應用程序須要屢次調用才能確認I/O操做徹底完成。

I/O的同步與異步I/O的同步與異步出如今應用程序中。若是作阻塞I/O調用，應用程序等待調用的完成的過程就是一種同步情況。相反，I/O爲非阻塞模式時，應用程序則是異步的。

參照《node.js入門經典》中對同步的解釋，同步的代碼意味着每一次執行一個操做，在一個操做完成以前，代碼的執行會被阻塞，沒法移到下一個操做上。也就是說代碼的執行會在函數返回前中止。直到函數返回後，代碼纔會繼續執行。

相反，異步就意味着函數的執行無需等待某個操做的結果就能夠繼續執行，其操做的結果會在事件發生時由回調來處理。

異步I/O優缺點

使用同步IO，它的優勢是可使程序調試方便，可是它的缺點也是明顯的，程序的執行過程當中若是入到一些耗時的IO操做，程序的執行都要等待該IO的完成，在這個等待的過程當中，程序沒法充分利用CPU，致使了CPU的閒置，爲了充分利用CPU，和IO並行操做，經常使用的方法有2中：

（1）多線程單進程

多線程的設計之處就是爲了在共享的程序空間中，實現並行處理任務，從而達到充分利用CPU的效果。

多線程缺點：

其1、執行時（線程切換）上下文交換的開銷較大，一個線程大約須要2M的內存空間，佔用資源較大。

其2、狀態同步（鎖）的問題，它也使得程序的編寫和調用複雜化。

（2）單線程多進程

爲了不多線程形成的使用不便問題，有的語言選擇了單線程保持調用簡單化，採用啓動多進程的方式來達到充分利用CPU和提高整體的並行處理能力。它的缺點在於業務邏輯複雜時（涉及多個I/O調用），由於業務邏輯不能分佈到多個進程之間，事務處理時長要遠遠大於多線程模式。

異步I/O與輪詢技術

當進行非阻塞I/O調用時，要讀到完整的數據，應用程序須要進行屢次輪詢，才能確保讀取數據完成，以進行下一步的操做。輪詢技術的缺點在於應用程序要主動調用，會形成佔用較多CPU時間片，性能較爲低下。現存的輪詢技術有如下這些： read、select、poll、epoll、pselect、kqueue

read是性能最低的一種，它經過重複調用來檢查I/O的狀態來完成完整數據讀取。

select是一種改進方案，經過對文件描述符上的事件狀態來進行判斷。

操做系統還提供了poll、epoll等多路複用技術來提升性能。

輪詢技術知足了異步I/O確保獲取完整數據的保證。可是對於應用程序而言，它仍然只能算時一種同步，由於應用程序仍然須要主動去判斷I/O的狀態，依舊花費了不少CPU時間來等待。上一種方法重複調用read進行輪詢直到最終成功，用戶程序會佔用較多CPU，性能較爲低下。而實際上操做系統提供了select方法來代替這種重複read輪詢進行狀態判斷。select內部經過檢查文件描述符上的事件狀態來進行判斷數據是否徹底讀取。可是對於應用程序而言它仍然只能算是一種同步，由於應用程序仍然須要主動去判斷I/O的狀態，依舊花費了不少CPU時間等待，select也是一種輪詢。

理想的異步I/O模型

理想的異步I/O應該是應用程序發起異步調用，而不須要進行輪詢，進而處理下一個任務，只需在I/O完成後經過信號或是回調將數據傳遞給應用程序便可。

暫時就整理這麼多吧，感受好多看過的東西都忘記了，回頭會寫一篇關於epoll使用的詳細例子，該例子支持2W併發是經過的。哎，今天狀態很差，寫的很差，本打算本身多加點什麼的，結果都是參考別人的，若有錯誤請你們指正，謝謝。

參考資料：

《node.js入門經典》 George Ornbo 著傅強陳宗賦譯人民郵電出版社

《深刻淺出node.js》

《node.js開發指南》 BYVoid 人民郵電出版社

如是轉載，請指明原出處：http://blog.csdn.net/feitianxuxue，謝謝合做！

同步（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的比較如圖所示：

通過上面的介紹，會發現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發個短信。