阻塞與非阻塞、同步與異步、I/O模型

1. 概念理解

在進行網絡編程時，咱們經常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調用方式：

同步/異步主要針對C端: 

同步：

所謂同步，就是在c端發出一個功能調用時，在沒有獲得結果以前，該調用就不返回。也就是必須一件一件事作，等前一件作完了才能作下一件事。

例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能幹任何事

異步：

異步的概念和同步相對。當c端一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者。

例如 ajax請求（異步）: 請求經過事件觸發->服務器處理（這是瀏覽器仍然能夠做其餘事情）->處理完畢

阻塞/非阻塞主要針對S端:

阻塞

阻塞調用是指調用結果返回以前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態下，cpu不會給線程分配時間片，即線程暫停運行）。函數只有在獲得結果以後纔會返回。

有人也許會把阻塞調用和同步調用等同起來，實際上他是不一樣的。對於同步調用來講，不少時候當前線程仍是激活的，只是從邏輯上當前函數沒有返回而已。 例如，咱們在socket中調用recv函數，若是緩衝區中沒有數據，這個函數就會一直等待，直到有數據才返回。而此時，當前線程還會繼續處理各類各樣的消息。

快遞的例子：好比到你某個時候到A樓一層（假如是內核緩衝區）取快遞，可是你不知道快遞何時過來，你又不能幹別的事，只能死等着。但你能夠睡覺（進程處於休眠狀態），由於你知道快遞把貨送來時必定會給你打個電話（假定必定能叫醒你）。

非阻塞

非阻塞和阻塞的概念相對應，指在不能馬上獲得結果以前，該函數不會阻塞當前線程，而會馬上返回。

仍是等快遞的例子：若是用忙輪詢的方法，每隔5分鐘到A樓一層(內核緩衝區）去看快遞來了沒有。若是沒來，當即返回。而快遞來了，就放在A樓一層，等你去取。

對象的阻塞模式和阻塞函數調用

對象是否處於阻塞模式和函數是否是阻塞調用有很強的相關性，可是並非一一對應的。阻塞對象上能夠有非阻塞的調用方式，咱們能夠經過必定的API去輪詢狀 態，在適當的時候調用阻塞函數，就能夠避免阻塞。而對於非阻塞對象，調用特殊的函數也能夠進入阻塞調用。函數select就是這樣的一個例子。

1. 同步，就是我客戶端（c端調用者）調用一個功能，該功能沒有結束前，我（c端調用者）死等結果。
2. 異步，就是我（c端調用者）調用一個功能，不須要知道該功能結果，該功能有結果後通知我（c端調用者）即回調通知。

同步/異步主要針對C端， 可是跟S端不是徹底沒有關係，同步/異步機制必須S端配合才能實現.同步/異步是由c端本身控制，可是S端是否阻塞/非阻塞， C端徹底不須要關心.
3. 阻塞，      就是調用我（s端被調用者，函數），我（s端被調用者，函數）沒有接收完數據或者沒有獲得結果以前，我不會返回。
4. 非阻塞，  就是調用我（s端被調用者，函數），我（s端被調用者，函數）當即返回，經過select通知調用者

同步IO和異步IO的區別就在於：數據訪問的時候進程是否阻塞！

阻塞IO和非阻塞IO的區別就在於：應用程序的調用是否當即返回！

同步和異步都只針對於本機SOCKET而言的。

同步和異步，阻塞和非阻塞，有些混用，其實它們徹底不是一回事，並且它們修飾的對象也不相同。

阻塞和非阻塞是指當server端的進程訪問的數據若是還沒有就緒，進程是否須要等待，簡單說這至關於函數內部的實現區別，也就是未就緒時是直接返回仍是等待就緒;

而同步和異步是指client端訪問數據的機制，同步通常指主動請求並等待I/O操做完畢的方式，當數據就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段，同步的讀寫必須阻塞)，異步則指主動請求數據後即可以繼續處理其它任務，隨後等待I/O，操做完畢的通知，這可使進程在數據讀寫時也不阻塞。(等待」通知」)

node.js裏面的描述：

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

相應地，異步式I/O （Asynchronous I/O）或非阻塞式I/O （Non-blocking I/O）則針對全部I/O 操做不採用阻塞的策略。當線程遇到I/O 操做時，不會以阻塞的方式等待I/O 操做的完成或數據的返回，而只是將I/O 請求發送給操做系統，繼續執行下一條語句。當操做系統完成I/O 操做時，以事件的形式通知執行I/O 操做的線程，線程會在特定時候處理這個事件。爲了處理異步I/O，線程必須有事件循環，不斷地檢查有沒有未處理的事件，依次予以處理。阻塞模式下，一個線程只能處理一項任務，要想提升吞吐量必須經過多線程。而非阻塞模式下，一個線程永遠在執行計算操做，這個線程所使用的CPU 核心利用率永遠是100%>，I/O 以事件的方式通知。在阻塞模式下，多線程每每能提升系統吞吐量，由於一個線程阻塞時還有其餘線程在工做，多線程可讓CPU 資源不被阻塞中的線程浪費。而在非阻塞模式下，線程不會被I/O 阻塞，永遠在利用CPU。多線程帶來的好處僅僅是在多核CPU 的狀況下利用更多的核，而Node.js的單線程也能帶來一樣的好處。這就是爲何Node.js 使用了單線程、非阻塞的事件編程模式。

2. Linux下的五種I/O模型

1)阻塞I/O（blocking I/O）
2)非阻塞I/O （nonblocking I/O）
3) I/O複用(select 和poll) （I/O multiplexing）
4)信號驅動I/O （signal driven I/O (SIGIO)）
5)異步I/O （asynchronous I/O (the POSIX aio_functions)）

前四種都是同步，只有最後一種纔是異步IO。

阻塞I/O模型：

簡介：進程會一直阻塞，直到數據拷貝完成

應用程序調用一個IO函數，致使應用程序阻塞，等待數據準備好。 若是數據沒有準備好，一直等待….數據準備好了，從內核拷貝到用戶空間，IO函數返回成功指示。

咱們 第一次接觸到的網絡編程都是從 listen()、send()、recv()等接口開始的。使用這些接口能夠很方便的構建服務器 /客戶機的模型。

阻塞I/O模型圖：在調用recv()/recvfrom（）函數時，發生在內核中等待數據和複製數據的過程。

當調用recv()函數時，系統首先查是否有準備好的數據。若是數據沒有準備好，那麼系統就處於等待狀態。當數據準備好後，將數據從系統緩衝區複製到用戶空間，而後該函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那麼此時recv()函數就會處於等待狀態。

當使用socket()函數和WSASocket()函數建立套接字時，默認的套接字都是阻塞的。這意味着當調用Windows Sockets API不能當即完成時，線程處於等待狀態，直到操做完成。

並非全部Windows Sockets API以阻塞套接字爲參數調用都會發生阻塞。例如，以阻塞模式的套接字爲參數調用bind()、listen()函數時，函數會當即返回。將可能阻塞套接字的Windows Sockets API調用分爲如下四種:

1．輸入操做： recv()、recvfrom()、WSARecv()和WSARecvfrom()函數。以阻塞套接字爲參數調用該函數接收數據。若是此時套接字緩衝區內沒有數據可讀，則調用線程在數據到來前一直睡眠。

2．輸出操做： send()、sendto()、WSASend()和WSASendto()函數。以阻塞套接字爲參數調用該函數發送數據。若是套接字緩衝區沒有可用空間，線程會一直睡眠，直到有空間。

3．接受鏈接：accept()和WSAAcept()函數。以阻塞套接字爲參數調用該函數，等待接受對方的鏈接請求。若是此時沒有鏈接請求，線程就會進入睡眠狀態。

4．外出鏈接：connect()和WSAConnect()函數。對於TCP鏈接，客戶端以阻塞套接字爲參數，調用該函數向服務器發起鏈接。該函數在收到服務器的應答前，不會返回。這意味着TCP鏈接總會等待至少到服務器的一次往返時間。

使用阻塞模式的套接字，開發網絡程序比較簡單，容易實現。當但願可以當即發送和接收數據，且處理的套接字數量比較少的狀況下，使用阻塞模式來開發網絡程序比較合適。

阻塞模式套接字的不足表現爲，在大量創建好的套接字線程之間進行通訊時比較困難。當使用「生產者-消費者」模型開發網絡程序時，爲每一個套接字都分別分配一個讀線程、一個處理數據線程和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當但願同時處理大量套接字時，將無從下手，其擴展性不好.

阻塞模式給網絡編程帶來了一個很大的問題，如在調用 send()的同時，線程將被阻塞，在此期間，線程將沒法執行任何運算或響應任何的網絡請求。這給多客戶機、多業務邏輯的網絡編程帶來了挑戰。這時，咱們可能會選擇多線程的方式來解決這個問題。

應對多客戶機的網絡應用，最簡單的解決方式是在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每一個鏈接都擁有獨立的線程（或進程），這樣任何一個鏈接的阻塞都不會影響其餘的鏈接。

具體使用多進程仍是多線程，並無一個特定的模式。傳統意義上，進程的開銷要遠遠大於線程，因此，若是須要同時爲較多的客戶機提供服務，則不推薦使用多進程；若是單個服務執行體須要消耗較多的 CPU 資源，譬如須要進行大規模或長時間的數據運算或文件訪問，則進程較爲安全。一般，使用 pthread_create () 建立新線程， fork() 建立新進程。

多線程/進程服務器同時爲多個客戶機提供應答服務。模型以下：

主線程持續等待客戶端的鏈接請求，若是有鏈接，則建立新線程，並在新線程中提供爲前例一樣的問答服務。

上述多線程的服務器模型彷佛完美的解決了爲多個客戶機提供問答服務的要求，但其實並不盡然。若是要同時響應成百上千路的鏈接請求，則不管多線程仍是多進程都會嚴重佔據系統資源，下降系統對外界響應效率，而線程與進程自己也更容易進入假死狀態。

由此可能會考慮使用「線程池」或「鏈接池」。「線程池」旨在減小建立和銷燬線程的頻率，其維持必定合理數量的線程，並讓空閒的線程從新承擔新的執行任務。「鏈接池」維持鏈接的緩存池，儘可能重用已有的鏈接、減小建立和關閉鏈接的頻率。這兩種技術均可以很好的下降系統開銷，都被普遍應用不少大型系統，如apache，MySQL數據庫等。

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

對應上例中的所面臨的可能同時出現的上千甚至上萬次的客戶端請求，「線程池」或「鏈接池」或許能夠緩解部分壓力，可是不能解決全部問題。

非阻塞IO模型 ：

簡介：非阻塞IO經過進程反覆調用IO函數（屢次系統調用，並立刻返回）；在數據拷貝的過程當中，進程是阻塞的；
咱們把一個SOCKET接口設置爲非阻塞就是告訴內核，當所請求的I/O操做沒法完成時，不要將進程睡眠，而是返回一個錯誤。這樣咱們的I/O操做函數將不斷的測試數據是否已經準備好，若是沒有準備好，繼續測試，直到數據準備好爲止。在這個不斷測試的過程當中，會大量的佔用CPU的時間。

把SOCKET設置爲非阻塞模式，即通知系統內核：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數當即返回。在返回時，該函數返回一個錯誤代碼。圖所示，一個非阻塞模式套接字屢次調用recv()函數的過程。前三次調用recv()函數時，內核數據尚未準備好。所以，該函數當即返回WSAEWOULDBLOCK錯誤代碼。第四次調用recv()函數時，數據已經準備好，被複制到應用程序的緩衝區中，recv()函數返回成功指示，應用程序開始處理數據。

當使用socket()函數和WSASocket()函數建立套接字時，默認都是阻塞的。在建立套接字以後，經過調用ioctlsocket()函數，將該套接字設置爲非阻塞模式。Linux下的函數是:fcntl().
套接字設置爲非阻塞模式後，在調用Windows Sockets API函數時，調用函數會當即返回。大多數狀況下，這些函數調用都會調用「失敗」，並返回WSAEWOULDBLOCK錯誤代碼。說明請求的操做在調用期間內沒有時間完成。一般，應用程序須要重複調用該函數，直到得到成功返回代碼。

須要說明的是並不是全部的Windows Sockets API在非阻塞模式下調用，都會返回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字爲參數調用bind()函數時，就不會返回該錯誤代碼。固然，在調用WSAStartup()函數時更不會返回該錯誤代碼，由於該函數是應用程序第一調用的函數，固然不會返回這樣的錯誤代碼。

要將套接字設置爲非阻塞模式，除了使用ioctlsocket()函數以外，還可使用WSAAsyncselect()和WSAEventselect()函數。當調用該函數時，套接字會自動地設置爲非阻塞方式。

因爲使用非阻塞套接字在調用函數時，會常常返回WSAEWOULDBLOCK錯誤。因此在任什麼時候候，都應仔細檢查返回代碼並做好對「失敗」的準備。應用程序接二連三地調用這個函數，直到它返回成功指示爲止。上面的程序清單中，在While循環體內不斷地調用recv()函數，以讀入1024個字節的數據。這種作法很浪費系統資源。

要完成這樣的操做，有人使用MSG_PEEK標誌調用recv()函數查看緩衝區中是否有數據可讀。一樣，這種方法也很差。由於該作法對系統形成的開銷是很大的，而且應用程序至少要調用recv()函數兩次，才能實際地讀入數據。較好的作法是，使用套接字的「I/O模型」來判斷非阻塞套接字是否可讀可寫。

非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，須要編寫更多的代碼，以便在每一個Windows Sockets API函數調用中，對收到的WSAEWOULDBLOCK錯誤進行處理。所以，非阻塞套接字便顯得有些難於使用。

可是，非阻塞套接字在控制創建的多個鏈接，在數據的收發量不均，時間不定時，明顯具備優點。這種套接字在使用上存在必定難度，但只要排除了這些困難，它在功能上仍是很是強大的。一般狀況下，可考慮使用套接字的「I/O模型」，它有助於應用程序經過異步方式，同時對一個或多個套接字的通訊加以管理。

 

IO複用模型：

簡介：主要是select和epoll；對一個IO端口，兩次調用，兩次返回，比阻塞IO並無什麼優越性；關鍵是能實現同時對多個IO端口進行監聽；

I/O複用模型會用到select、poll、epoll函數，這幾個函數也會使進程阻塞，可是和阻塞I/O所不一樣的的，這兩個函數能夠同時阻塞多個I/O操做。並且能夠同時對多個讀操做，多個寫操做的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操做函數。

信號驅動IO

簡介：兩次調用，兩次返回；

首先咱們容許套接口進行信號驅動I/O，並安裝一個信號處理函數，進程繼續運行並不阻塞。當數據準備好時，進程會收到一個SIGIO信號，能夠在信號處理函數中調用I/O操做函數處理數據。

異步IO模型

簡介：數據拷貝的時候進程無需阻塞。

     當一個異步過程調用發出後，調用者不能馬上獲得結果。實際處理這個調用的部件在完成後，經過狀態、通知和回調來通知調用者的輸入輸出操做

同步IO引發進程阻塞，直至IO操做完成。
異步IO不會引發進程阻塞。
IO複用是先經過select調用阻塞。

5個I/O模型的比較：

3. select、poll、epoll簡介

select原型說明:http://blog.csdn.net/hguisu/article/details/38638183#t5

epoll模型：http://blog.csdn.net/hguisu/article/details/38638183#t12

epoll跟select都能提供多路I/O複用的解決方案。在如今的Linux內核裏有都可以支持，其中epoll是Linux所特有，而select則應該是POSIX所規定，通常操做系統均有實現

select：

select本質上是經過設置或者檢查存放fd標誌位的數據結構來進行下一步處理。這樣所帶來的缺點是：

一、 單個進程可監視的fd數量被限制，即能監聽端口的大小有限。

通常來講這個數目和系統內存關係很大，具體數目能夠cat /proc/sys/fs/file-max察看。32位機默認是1024個。64位機默認是2048.

二、 對socket進行掃描時是線性掃描，即採用輪詢的方法，效率較低：

當套接字比較多的時候，每次select()都要經過遍歷FD_SETSIZE個Socket來完成調度，無論哪一個Socket是活躍的，都遍歷一遍。這會浪費不少CPU時間。若是能給套接字註冊某個回調函數，當他們活躍時，自動完成相關操做，那就避免了輪詢，這正是epoll與kqueue作的。

三、須要維護一個用來存放大量fd的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時複製開銷大

poll：

poll本質上和select沒有區別，它將用戶傳入的數組拷貝到內核空間，而後查詢每一個fd對應的設備狀態，若是設備就緒則在設備等待隊列中加入一項並繼續遍歷，若是遍歷完全部fd後沒有發現就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒後它又要再次遍歷fd。這個過程經歷了屢次無謂的遍歷。

它沒有最大鏈接數的限制，緣由是它是基於鏈表來存儲的，可是一樣有一個缺點：

一、大量的fd的數組被總體複製於用戶態和內核地址空間之間，而無論這樣的複製是否是有意義。

二、poll還有一個特色是「水平觸發」，若是報告了fd後，沒有被處理，那麼下次poll時會再次報告該fd。

epoll:

epoll支持水平觸發和邊緣觸發，最大的特色在於邊緣觸發，它只告訴進程哪些fd剛剛變爲就需態，而且只會通知一次。還有一個特色是，epoll使用「事件」的就緒通知方式，經過epoll_ctl註冊fd，一旦該fd就緒，內核就會採用相似callback的回調機制來激活該fd，epoll_wait即可以收到通知

epoll的優勢：
一、沒有最大併發鏈接的限制，能打開的FD的上限遠大於1024（1G的內存上能監聽約10萬個端口）；
二、效率提高，不是輪詢的方式，不會隨着FD數目的增長效率降低。只有活躍可用的FD纔會調用callback函數；
即Epoll最大的優勢就在於它只管你「活躍」的鏈接，而跟鏈接總數無關，所以在實際的網絡環境中，Epoll的效率就會遠遠高於select和poll。

三、 內存拷貝，利用mmap()文件映射內存加速與內核空間的消息傳遞；即epoll使用mmap減小複製開銷。

select、poll、epoll 區別總結：

一、支持一個進程所能打開的最大鏈接數

select	單個進程所能打開的最大鏈接數有FD_SETSIZE宏定義，其大小是32個整數的大小（在32位的機器上，大小就是32*32，同理64位機器上FD_SETSIZE爲32*64），固然咱們能夠對進行修改，而後從新編譯內核，可是性能可能會受到影響，這須要進一步的測試。
poll	poll本質上和select沒有區別，可是它沒有最大鏈接數的限制，緣由是它是基於鏈表來存儲的
epoll	雖然鏈接數有上限，可是很大，1G內存的機器上能夠打開10萬左右的鏈接，2G內存的機器能夠打開20萬左右的鏈接

二、FD劇增後帶來的IO效率問題

select	由於每次調用時都會對鏈接進行線性遍歷，因此隨着FD的增長會形成遍歷速度慢的「線性降低性能問題」。
poll	同上
epoll	由於epoll內核中實現是根據每一個fd上的callback函數來實現的，只有活躍的socket纔會主動調用callback，因此在活躍socket較少的狀況下，使用epoll沒有前面二者的線性降低的性能問題，可是全部socket都很活躍的狀況下，可能會有性能問題。

三、 消息傳遞方式

select	內核須要將消息傳遞到用戶空間，都須要內核拷貝動做
poll	同上
epoll	epoll經過內核和用戶空間共享一塊內存來實現的。

總結：

綜上，在選擇select，poll，epoll時要根據具體的使用場合以及這三種方式的自身特色。

一、表面上看epoll的性能最好，可是在鏈接數少而且鏈接都十分活躍的狀況下，select和poll的性能可能比epoll好，畢竟epoll的通知機制須要不少函數回調。

二、select低效是由於每次它都須要輪詢。但低效也是相對的，視狀況而定，也可經過良好的設計改善

同步/異步與阻塞/非阻塞常常看到是成對出現：

同步阻塞，異步非阻塞，同步非阻塞