處理併發：異步非阻塞

 

這是借鑑博客內容：    

在研究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的效果。

    多線程缺點：

    其1、執行時（線程切換）上下文交換的開銷較大，一個線程大約須要2M的內存空間，佔用資源較大。

    其2、狀態同步（鎖）的問題，它也使得程序的編寫和調用複雜化。

    （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完成後經過信號或是回調將數據傳遞給應用程序便可。