在研究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調用，應用程序等待調用的完成的過程就是一種同步狀況。相反，I/O爲非阻塞模式時，應用程序則是異步的。
參照《node.js入門經典》中對同步的解釋，同步的代碼意味着每一次執行一個操作，在一個操作完成之前，代碼的執行會被阻塞，無法移到下一個操作上。也就是說代碼的執行會在函數返回前停止。直到函數返回後，代碼纔會繼續執行。
相反，異步就意味着函數的執行無需等待某個操作的結果就可以繼續執行，其操作的結果會在事件發生時由回調來處理。
異步I/O優缺點
使用同步IO，它的優點是可以使程序調試方便，但是它的缺點也是明顯的，程序的執行過程中如果入到一些耗時的IO操作，程序的執行都要等待該IO的完成，在這個等待的過程中，程序無法充分利用CPU，導致了CPU的閒置，爲了充分利用CPU，和IO並行操作，常用的方法有2中：
（1）多線程單進程
多線程的設計之處就是爲了在共享的程序空間中，實現並行處理任務，從而達到充分利用CPU的效果。
多線程缺點：
其一、執行時（線程切換）上下文交換的開銷較大，一個線程大約需要2M的內存空間，佔用資源較大。
其二、狀態同步（鎖）的問題，它也使得程序的編寫和調用複雜化。
（2）單線程多進程
爲了避免多線程造成的使用不便問題，有的語言選擇了單線程保持調用簡單化，採用啓動多進程的方式來達到充分利用CPU和提升總體的並行處理能力。它的缺點在於業務邏輯複雜時（涉及多個I/O調用），因爲業務邏輯不能分佈到多個進程之間，事務處理時長要遠遠大於多線程模式。
異步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應該是應用程序發起異步調用，而不需要進行輪詢，進而處理下一個任務，只需在I/O完成後通過信號或是回調將數據傳遞給應用程序即可。
暫時就整理這麼多吧，感覺好多看過的東西都忘記了，回頭會寫一篇關於epoll使用的詳細例子，該例子支持2W併發是通過的。哎，今天狀態不好，寫的不好，本打算自己多加點什麼的，結果都是參考別人的，如有錯誤請大家指正，謝謝。
參考資料：
《node.js入門經典》 George Ornbo 著 傅強 陳宗賦 譯 人民郵電出版社
《深入淺出node.js》
《node.js開發指南》 BYVoid 人民郵電出版社
