在高併發程式設計當中，我們經常會遇到一些非同步、非阻塞等一些概念，一些常用的技術比如非同步的httpclient、netty nio、nginx、node.js等，它們的原理大都跟非同步、非阻塞有關。特別是在伺服器開發中，併發的請求處理是個大問題，阻塞式的函式會導致資源浪費和時間延遲。通過事件註冊、非同步函式，開發人員可以提高資源的利用率，效能也會改善。其nginx和node.js處理併發都是採用的事件驅動非同步非阻塞模式。其中nginx中處理併發用的是epoll，poll,queue等方式，node.js使用的是libev，它們對大規模的HTTP請求處理的都很好。

那麼到底什麼是非同步、非阻塞，它們的原理是什麼，它們之間又有什麼區別呢？其實在很多情況下，非同步與非阻塞(同步與阻塞)表示的是同一個意思，但是在特定的上下文環境中，它們含義又十分不同。再具體講它們的區別之前，先介紹一下上下文背景。

一、上下文背景

我們所遇到的這些場景大部分都是當用戶程序（或執行緒）在進行網路IO時即進行Socket讀寫時遇到的，所以本文討論的上下文背景是基於Linux環境下的network IO。先介紹一下其中我們最常見的五種IO：

1.  blocking IO
2.  nonblocking IO
3.  IO multiplexing
4.  signal driven IO
5.  asynchronous IO

由於signal driven IO在實際中並不常用，所以我這隻提及剩下的四種IO Model。

再說一下IO發生時涉及的物件和步驟。對於一個network IO (這裡我們以read舉例)，它會涉及到兩個系統物件，一個是呼叫這個IO的程序(或執行緒)，另一個就是系統核心(kernel)。當一個read操作發生時，它會經歷兩個階段：

1. 等待資料準備(Waiting for the data to be ready)
2. 將資料從核心拷貝到程序中 (Copying the data from the kernel to the process)

記住這兩點很重要，因為這些IO Model的區別就是在兩個階段上各有不同的情況。

二、各種IO介紹

2.1 blocking IO

在linux中，預設情況下所有的socket都是blocking，也就是說我們的一個程序在進行IO操作時如果沒有資料達到，這個程序是被阻塞的。一個典型的讀操作流程大概是這樣：

當用戶程序呼叫了recvfrom這個系統呼叫，kernel就開始了IO的第一個階段：準備資料。對於network io來說，很多時候資料在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的資料到來。而在使用者程序這邊，整個程序會被阻塞。當kernel一直等到資料準備好了，它就會將資料從kernel中拷貝到使用者記憶體，然後kernel返回結果，使用者程序才解除block的狀態，重新執行起來。所以，blocking IO的特點就是在IO執行的wait和copy兩個階段都被block了

在這種block IO的情況下，如果請求的連線比較多，但其中大部分都是阻塞的。因為cpu的核數是有限的，所以一般的解決方案就是每個cpu啟用多個執行緒來處理多個連線。這種解決方案有很大的缺陷：

1. 執行緒是有記憶體開銷的，1個執行緒可能需要512K（或2M）存放棧，那麼1000個執行緒就要512M（或2G）記憶體
2. 執行緒的切換開銷和很大，因為執行緒切換時需要保持當前執行緒上下文資訊，當大量時間花在上下文切換的時候，分配給真正的操作的CPU就要少很多
3. 一個cpu所支援的執行緒數量時有限的（因為上面兩個原因），一般來說執行緒的數量級在幾百個左右就已經很大了

為了解決block IO存在的問題，就引入了no-blocking IO概念。

2.2 non-blocking IO

no-blocking IO很簡單，通過將socket設為非阻塞模式，這時，當你呼叫read時，如果有資料就緒，就返回資料，如果沒有資料就緒，就立刻返回一個錯誤，如EWOULDBLOCK。這樣是不會阻塞執行緒了，但是你還是要不斷的輪詢來讀取或寫入。當對一個non-blocking socket執行讀操作時，流程是這個樣子：

從圖中可以看出，當用戶程序發出read操作時，如果kernel中的資料還沒有準備好，那麼它並不會block使用者程序，而是立刻返回一個error。從使用者程序角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。使用者程序判斷結果是一個error時，它就知道資料還沒有準備好，於是它可以再次傳送read操作。一旦kernel中的資料準備好了，並且又再次收到了使用者程序的system call，那麼它馬上就將資料拷貝到了使用者記憶體，然後返回。

從上面介紹可以看到，blocking IO的特點就是在IO執行的wait階段是非阻塞的，但是copy階段還是阻塞的。

但是no-blocking IO也存在很大的缺陷，就是IO執行緒還是要不斷的輪詢socket來讀取或寫入， 於是，我們又引入了IO多路複用。

2.3 IO multiplexing（IO多路複用）

IO multiplexing即IO多路複用，有些地方也稱這種IO方式為event driven IO（事件驅動IO）。它的基本原理就是用通過作業系統提供的select/epoll等這些函式不斷的輪詢所負責的所有socket，而不是讓使用者程序自己去輪詢，注意這個socket必須先設成非同步的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，如果處理的連線數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server效能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連線能處理得更快，而是在於能處理更多的連線。

那麼IO多路複用的優勢在哪裡呢，其實就是在”多路複用”這個詞上。上面也講到了多路複用是指使用一個執行緒來檢查多個Socket(也成檔案描述符 )的就緒狀態，比如呼叫select和epoll函式，傳入多個檔案描述符，如果有一個檔案描述符就緒，則返回，否則阻塞直到超時。所以，在高併發的場景中，比如要處理10000個連線，只需要1個執行緒監控就緒狀態，對就緒的每個連線開一個執行緒處理或者直接丟到執行緒池處理，當然也可以用當前執行緒處理，那麼這個IO執行緒可以同時管理多個連線，也就是多路複用了。

2.4 Asynchronous I/O

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

使用者程序發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對使用者程序產生任何block。然後，kernel會等待資料準備完成，然後將資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者程序傳送一個signal，告訴它read操作完成了。

三、各種IO之間的區別

到目前為止，已經將四個IO Model都介紹完了。現在回過頭來回答最初的那幾個問題：blocking和non-blocking的區別在哪，synchronous IO和asynchronous IO的區別在哪。

blocking vs non-blocking，這個問題很簡單，前面的介紹中其實已經很明確的說明了這兩者的區別：

1. blocking IO 會在wait和copy階段都會阻塞程序
2. non-blocking IO 在wait階段會立即返回不會阻塞程序，而在copy階段仍會阻塞程序copy資料

在說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。Stevens給出的定義（其實是POSIX的定義）是這樣子的：

1. synchronous I/O：IO操作過程中程序會被阻塞，直到IO操作完成
2. asynchronous I/O：IO操作過程中程序不會被阻塞，作業系統幫你完成IO操作之後直接返回給你

按照這個定義，在網路IO層面，同步非同步相對於阻塞非阻塞是一個更加巨集觀的概念，之前所述的阻塞IO，非阻塞IO，IO多路複用都屬於同步IO，因為它們在核心copy資料階段都會阻塞程序。而非同步IO則不一樣，當程序發起IO 操作之後，就直接返回再也不理睬了，直到作業系統核心傳送一個訊號，告訴程序說作業系統IO已經完成，在這整個過程中，程序完全沒有被阻塞。

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

經過上面的介紹，會發現非阻塞IO和非同步IO的區別還是很明顯的。在非阻塞 IO中，雖然程序大部分時間都不會被block，但是它仍然要求程序去主動的check，並且當資料準備完成以後，也需要程序主動的再次呼叫recvfrom來將資料拷貝到使用者記憶體。而非同步 IO則完全不同，它就像是使用者程序將整個IO操作交給了作業系統（核心）完成，然後作業系統做完後發訊號通知。在此期間，使用者程序不需要去檢查IO操作的狀態，也不需要主動的去拷貝資料。