聊聊Node中的各種I/O模型

本篇文章帶大家聊聊中的各種I/O模型，介紹一下阻塞式I/O模型、非阻塞式I/O模型和非阻塞非同步I/O，希望對大家有所幫助！

我們以網路請求IO為例，首先介紹伺服器端處理一次完整的網路IO請求的典型流程：

應用程式獲得一個操作結果，通常包括兩個不同的階段：

以下，我們以 recvfrom 函數為例，解釋說明各種IO模型

阻塞式 I/O 模型(blocking I/O）

阻塞呼叫是指呼叫結果返回之前，當前執行緒會被掛起，呼叫執行緒只有在等待系統核心層面所有操作完成之後，呼叫才會結束。

阻塞I/O造成了cpu的等待I/O，浪費了CPU的時間片。

相比於前者，非阻塞I/O不帶資料直接返回，要獲取資料，還需要通過檔案描述符再次嘗試讀取資料

非阻塞呼叫得到返回（並不是真實的期待資料）之後，CPU時間片可以用於處理其他的事情，可以明顯提升效能。

但是隨之而來的問題是，之前的操作並不是一次完整的I/O，返回得到的結果不是期望得到的業務資料，而僅僅是非同步呼叫狀態。

為了獲取完整的資料，應用程式需要重複呼叫IO操作來確認操作是否已經完成，這種操作我們稱之為輪詢，常見的幾種輪詢策略如下

這是最原始，也是效能最低的一種方式，通過重複呼叫來檢查I/O狀態達到獲取完整資料的目的

優點：程式設計簡單

缺點：CPU一直耗費在輪詢上，同時影響伺服器效能，因為你輪詢之後伺服器還要進行作答

在 I/O 複用模型中，會用到 Select 或 Poll 函數或 Epoll 函數(Linux 2.6 以後的核心開始支援)，這兩個函數也會使程序阻塞，但是和阻塞 I/O 有所不同。

這三個函數可以同時阻塞多個 I/O 操作，而且可以同時對多個讀操作，多個寫操作的 I/O 函數進行檢測，直到有資料可讀或可寫時，才真正呼叫 I/O 操作函數。

三種I/O複用機制的區別如下

由於select採用1024長度的陣列來儲存檔案狀態，因此最多可以同時檢測1024個檔案描述符

相比select略有改進，採用連結串列避免了1024的長度限制，並且能避免不需要的遍歷檢查，相比select效能稍有改善

是linux下效率最高的I/O事件通知機制，輪詢時如果沒有檢測到I/O事件，將會進行休眠，直到事件發生將執行緒喚醒。它是真正利用了事件通知，執行回撥，而不是遍歷（檔案描述符）查詢，因此不會浪費CPU

小結：本質上說，輪詢仍然是一種同步操作，因為應用程式仍然在等待I/O完全返回，等待期間要麼遍歷檔案描述狀態，要麼休眠等待事件的發生。

在訊號驅動式 I/O 模型中，應用程式使用訊號驅動 I/O，並安裝一個訊號處理常式，程序繼續執行並不阻塞。

當資料準備好時，程式會收到一個 SIGIO 訊號，可以在訊號處理常式中呼叫 I/O 操作函數處理資料。

小結：到此為止，訊號驅動式I/O模型是更加符合我們的非同步需求的，程式會在等待資料的過程中非同步執行其他的業務邏輯。

但是！！！ 在資料從核心複製到使用者空間過程中依然是阻塞的，並不能算是一場徹底的革命（非同步）。

我們理想中的非同步I/O應該是應用程式發起非阻塞呼叫，無需通過輪詢的方式進行資料獲取，更沒有必要在資料拷貝階段進行無謂的等待，而是能夠在I/O完成之後，通過訊號或者回撥函數的方式傳遞給應用程式，在此期間應用程式可以執行其他業務邏輯。

實際上，linux平臺下原生支援了非同步I/O（AIO），但是目前 AIO 並不完善，因此在 Linux 下實現高並行網路程式設計時都是以 I/O 複用模型為主。

而Windows 下通過 IOCP 實現了真正的非同步 I/O。

linux平臺下，Node利用執行緒池，通過讓部分執行緒進行阻塞I/O或者非阻塞I/O+輪詢的方式完成資料獲取，讓某一個單獨的執行緒進行計算，通過執行緒之間的通訊，將I/O結果進行傳遞，這樣便實現了非同步I/O的模擬。

其實Windows平臺下的IOCP非同步非同步方案底層也是採用執行緒池的方式實現的，所不同的是，後者的執行緒池是由系統核心進行託管的。

我們常說Node是單執行緒的，但其實只能說是JS執行在單執行緒中，無論是*nix還是windows平臺，底層都是利用執行緒池來完成I/O操作。

更多node相關知識，請存取：！

以上就是聊聊Node中的各種I/O模型的詳細內容，更多請關注TW511.COM其它相關文章！