一、IO模型介紹

　　為了更好地了解IO模型，我們需要事先回顧下：

　　　　同步：一件事情做完再做另一件事情

　　　　異步：同時做多件事情

　　　　阻塞：sleep、input、join、shutdown、get、acquire、wait　　accept、recv、recvfrom

　　　　非阻塞：strblocking(False)

　　用socket 一定會用到accept、recv、recvfrom這些方法

　　　　正常情況下accept、recv、recvfrom都是阻塞的

　　　　如果setblocking(False) 整個程序就變成一個非阻塞的程序了

同步（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 阻塞IO
* nonblocking IO 非阻塞IO
* IO multiplexing IO多路復用
* signal driven IO 信號驅動IO
* asynchronous IO 異步IO
由signal driven IO（信號驅動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模型的區別就是在兩個階段上各有不同的情況。

二、阻塞IO(blocking IO)

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

　　當用戶進程調用了recvfrom這個系統調用，kernel就開始了IO的第一個階段：準備數據。對於network io來說，很多時候數據在一開始還沒有到達（比如，還沒有收到一個完整的UDP包），這個時候kernel就要等待足夠的數據到來。

而在用戶進程這邊，整個進程會被阻塞。當kernel一直等到數據準備好了，它就會將數據從kernel中拷貝到用戶內存，然後kernel返回結果，用戶進程才解除block的狀態，重新運行起來。
所以，blocking IO的特點就是在IO執行的兩個階段（等待數據和拷貝數據兩個階段）都被block了。

幾乎所有的程序員第一次接觸到的網絡編程都是從listen()、send()、recv() 等接口開始的，使用這些接口可以很方便的構建服務器/客戶機的模型。然而大部分的socket接口都是阻塞型的。如下圖

ps：所謂阻塞型接口是指系統調用（一般是IO接口）不返回調用結果並讓當前線程一直阻塞，只有當該系統調用獲得結果或者超時出錯時才返回。

　　實際上，除非特別指定，幾乎所有的IO接口 ( 包括socket接口 ) 都是阻塞型的。這給網絡編程帶來了一個很大的問題，如在調用recv(1024)的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網絡請求。

一個簡單的解決方案：

#在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。

該方案的問題是：

#開啟多進程或都線程的方式，在遇到要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重占據系統資源，降低系統對外界響應效率，而且線程與進程本身也更容易進入假死狀態。

改進方案：

#很多程序員可能會考慮使用“線程池”或“連接池”。“線程池”旨在減少創建和銷毀線程的頻率，其維持一定合理數量的線程，並讓空閑的線程重新承擔新的執行任務。“連接池”維持連接的緩存池，盡量重用已有的連接、減少創建和關閉連接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如websphere、tomcat和各種數據庫等。

改進後方案其實也存在著問題：

#“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調用IO接口帶來的資源占用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小。

對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。總之，多線程模型可以方便高效的解決小規模的服務請求，但面對大規模的服務請求，多線程模型也會遇到瓶頸，可以用非阻塞接口來嘗試解決這個問題。

《Python》IO模型