同步與阻塞，非同步與非阻塞的區別轉載
同步與阻塞，非同步與非阻塞的區別
同步與非同步是對應的，它們是執行緒之間的關係，兩個執行緒之間要麼是同步的，要麼是非同步的。
阻塞與非阻塞是對同一個執行緒來說的，在某個時刻，執行緒要麼處於阻塞，要麼處於非阻塞。
阻塞是使用同步機制的結果，非阻塞則是使用非同步機制的結果。
處理大併發之一 對非同步非阻塞的理解
在研究nginx和node.js的時候常會遇到非同步、非阻塞等，之前自己也經常使用epoll，對其同步與阻塞，非同步與非阻塞有了一定的認識，現對參考資料總結下。
首先討論下使用事件驅動，非同步程式設計的優點：
充分利用了系統資源，執行程式碼無須阻塞等待某種操作完成，有限的資源可以用於其他的任務。其非常適合於後端的網路服務程式設計。
在伺服器開發中，併發的請求處理是個大問題，阻塞式的函式會導致資源浪費和時間延遲。通過事件註冊、非同步函式，開發人員可以提高資源的利用率，效能也會改善。其nginx和node.js處理併發都是採用的事件驅動非同步非阻塞模式。其中nginx中處理併發用的是epoll，poll,queue等方式，node.js使用的是libev，它們對大規模的HTTP請求處理的都很好。
《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為非阻塞模式時，應用程式則是非同步的。
參照《node.js入門經典》中對同步的解釋，同步的程式碼意味著每一次執行一個操作，在一個操作完成之前，程式碼的執行會被阻塞，無法移到下一個操作上。也就是說程式碼的執行會在函式返回前停止。直到函式返回後，程式碼才會繼續執行。
相反，非同步就意味著函式的執行無需等待某個操作的結果就可以繼續執行，其操作的結果會在事件發生時由回撥來處理。
使用同步IO，它的優點是可以使程式除錯方便，但是它的缺點也是明顯的，程式的執行過程中如果入到一些耗時的IO操作，程式的執行都要等待該IO的完成，在這個等待的過程中，程式無法充分利用CPU，導致了CPU的閒置，為了充分利用CPU，和IO並行操作，常用的方法有2中：
（1）多執行緒單程序
多執行緒的設計之處就是為了在共享的程式空間中，實現並行處理任務，從而達到充分利用CPU的效果。
多執行緒缺點：
其一、執行時（執行緒切換）上下文交換的開銷較大，一個執行緒大約需要2M的記憶體空間，佔用資源較大。
其二、狀態同步（鎖）的問題，它也使得程式的編寫和呼叫複雜化。
（2）單執行緒多程序
為了避免多執行緒造成的使用不便問題，有的語言選擇了單執行緒保持呼叫簡單化，採用啟動多程序的方式來達到充分利用CPU和提升總體的並行處理能力。它的缺點在於業務邏輯複雜時（涉及多個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完成後通過訊號或是回撥將資料傳遞給應用程式即可。
暫時就整理這麼多吧，感覺好多看過的東西都忘記了，回頭會寫一篇關於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發個簡訊。