轉自 http://blog.csdn.net/hguisu/article/details/7453390
在進行網絡編程時，我們常常見到同步(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的區別就在於：應用程序的調用是否立即返回！
同步和異步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同。
阻塞和非阻塞是指當server端的進程訪問的數據如果尚未就緒,進程是否需要等待,簡單說這相當於函數內部的實現區別,也就是未就緒時是直接返回還是等待就緒;
而同步和異步是指client端訪問數據的機制,同步一般指主動請求並等待I/O操作完畢的方式,當數據就緒後在讀寫的時候必須阻塞(區別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數據後便可以繼續處理其它任務,隨後等待I/O,操作完畢的通知,這可以使進程在數據讀寫時也不阻塞。(等待"通知")
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()等接口開始的。使用這些接口可以很方便的構建服務器 /客戶機的模型。
使用阻塞模式的套接字，開發網絡程序比較簡單，容易實現。當希望能夠立即發送和接收數據，且處理的套接字數量比較少的情況下，使用阻塞模式來開發網絡程序比較合適。
阻塞模式套接字的不足表現爲，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生產者-消費者”模型開發網絡程序時，爲每個套接字都分別分配一個讀線程、一個處理數據線程和一個用於同步的事件，那麼這樣無疑加大系統的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴展性很差.
阻塞模式給網絡編程帶來了一個很大的問題，如在調用 send()的同時，線程將被阻塞，在此期間，線程將無法執行任何運算或響應任何的網絡請求。這給多客戶機、多業務邏輯的網絡編程帶來了挑戰。這時，我們可能會選擇多線程的方式來解決這個問題。
應對多客戶機的網絡應用，最簡單的解決方式是在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。
具體使用多進程還是多線程，並沒有一個特定的模式。傳統意義上，進程的開銷要遠遠大於線程，所以，如果需要同時爲較多的客戶機提供服務，則不推薦使用多進程；如果單個服務執行體需要消耗較多的 CPU 資源，譬如需要進行大規模或長時間的數據運算或文件訪問，則進程較爲安全。通常，使用 pthread_create () 創建新線程，fork() 創建新進程。
上述多線程的服務器模型似乎完美的解決了爲多個客戶機提供問答服務的要求，但其實並不盡然。如果要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重佔據系統資源，降低系統對外界響應效率，而線程與進程本身也更容易進入假死狀態。
由此可能會考慮使用“線程池”或“連接池”。“線程池”旨在減少創建和銷燬線程的頻率，其維持一定合理數量的線程，並讓空閒的線程重新承擔新的執行任務。“連接池”維持連接的緩存池，儘量重用已有的連接、減少創建和關閉連接的頻率。這兩種技術都可以很好的降低系統開銷，都被廣泛應用很多大型系統，如apache，MySQL數據庫等。
但是，“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調用 IO 接口帶來的資源佔用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構成的系統對外界的響應並不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規模，並根據響應規模調整“池”的大小
非阻塞IO模型 ：
我們把一個SOCKET接口設置爲非阻塞就是告訴內核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數將不斷的測試數據是否已經準備好，如果沒有準備好，繼續測試，直到數據準備好爲止。在這個不斷測試的過程中，會大量的佔用CPU的時間。
把SOCKET設置爲非阻塞模式，即通知系統內核：在調用Windows Sockets API時，不要讓線程睡眠，而應該讓函數立即返回。在返回時，該函數返回一個錯誤代碼。
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模型
簡介：數據拷貝的時候進程無需阻塞。
當一個異步過程調用發出後，調用者不能立刻得到結果。實際處理這個調用的部件在完成後，通過狀態、通知和回調來通知調用者的輸入輸出操作