【深入探究Node】（3）“異步IO” 有九問

作者：事業有成的張啦啦 2021-06-18 09:17:10

在node中，假設此時不使用異步io，那么當一個io在執行的時候，另一個io的執行必須等待前一個io執行完畢才可以。那么速度就會慢很多，需要認識到只有后端能夠快速響應資源，才能讓前端的體驗變好。

我嘗試用一種自問自答的方式記下筆記，就像面試一樣，我自個兒覺得有意思極了，希望你也喜歡

1.為什么要異步I/O?

具體到實處，則可以從用戶體驗和資源分配這兩個方面說起。

用戶體驗

與前端JavaScript在單線程上執行，而且它還與UI渲染共用一個線程一樣。JavaScript在執行的時候UI渲染和響應是處于停滯狀態的。那么，在node中，假設此時不使用異步io，那么當一個io在執行的時候，另一個io的執行必須等待前一個io執行完畢才可以。那么速度就會慢很多，需要認識到只有后端能夠快速響應資源，才能讓前端的體驗變好。

資源分配

我們首先需要知道計算機在發展過程中將組件進行了抽象，分為I/O設備和計算設備。

如果創建多線程的開銷小于并行執行，那么多線程的方式是首選的。多線程的代價在于創建線程和執行期線程上下文切換的開銷較大。另外，在復雜的業務中，多線程編程經常面臨鎖、狀態同步等問題，這是多線程被詬病的主要原因。但是多線程在多核CPU上能夠有效提升CPU的利用率，這個優勢是毋庸置疑的。

單線程順序執行任務的方式比較符合編程人員按順序思考的思維方式。它依然是最主流的編程方式，因為它易于表達。但是串行執行的缺點在于性能，任意一個略慢的任務都會導致后續執行代碼被阻塞。在計算機資源中，通常I/O與CPU計算之間是可以并行進行的。但是同步的編程模型導致的問題是，I/O的進行會讓后續任務等待，這造成資源不能被更好地利用。

單線程同步編程模型會因阻塞I/O導致硬件資源得不到更優的使用。多線程編程模型也因為編程中的死鎖、狀態同步等問題讓開發人員頭疼。

Node在兩者之間給出了它的方案：利用單線程，遠離多線程死鎖、狀態同步等問題;利用異步I/O，讓單線程遠離阻塞，以更好地使用CPU。

異步I/O可以算作Node的特色，因為它是首個大規模將異步I/O應用在應用層上的平臺，它力求在單線程上將資源分配得更高效。為了彌補單線程無法利用多核CPU的缺點，Node提供了類似前端瀏覽器中WebWorkers的子進程，該子進程可以通過工作進程高效地利用CPU和I/O。

異步I/O的提出是期望I/O的調用不再阻塞后續運算，將原有等待I/O完成的這段時間分配給其余需要的業務去執行。

下圖為異步I/O的調用示意圖。

2.說到異步IO，我也經常聽到非阻塞IO，這兩者是一個東西嗎?

異步與非阻塞聽起來似乎是同一回事。從實際效果而言，異步和非阻塞都達到了我們并行I/O的目的。但是從計算機內核I/O而言，異步/同步和阻塞/非阻塞實際上是兩回事。

操作系統內核對于I/O只有兩種方式：阻塞與非阻塞。在調用阻塞I/O時，應用程序需要等待I/O完成才返回結果，如圖所示。

阻塞I/O的一個特點是調用之后一定要等到系統內核層面完成所有操作后，調用才結束。以讀取磁盤上的一段文件為例，系統內核在完成磁盤尋道、讀取數據、復制數據到內存中之后，這個調用才結束。

阻塞I/O造成CPU等待I/O，浪費等待時間，CPU的處理能力不能得到充分利用。為了提高性能，內核提供了非阻塞I/O。非阻塞I/O跟阻塞I/O的差別為調用之后會立即返回，如圖所示。

這個讓我想起直接打印狀態為pending的promise對象，也是可以打印出來的，這個就是異步吧，雖然狀態還沒變為resolved或者rejected，也一樣返回了。

非阻塞I/O返回之后，CPU的時間片可以用來處理其他事務，此時的性能提升是明顯的。

3.這樣的話根本無法返回完整的數據，怎么辦?

層期望的數據，而僅僅是當前調用的狀態。為了獲取完整的數據，應用程序需要重復調用I/O操作來確認是否完成。這種重復調用判斷操作是否完成的技術叫做輪詢。

4.可以說下什么是輪詢技術嗎?

任意技術都并非完美的。阻塞I/O造成CPU等待浪費，非阻塞帶來的麻煩卻是需要輪詢去確認是否完全完成數據獲取，它會讓CPU處理狀態判斷，是對CPU資源的浪費。

輪詢技術主要包括這幾種：read、select、poll、epoll。

read

它是最原始、性能最低的一種，通過重復調用來檢查I/O的狀態來完成完整數據的讀取。在得到最終數據前，CPU一直耗用在等待上。下圖為通過read進行輪詢的示意圖。

select

它是在read的基礎上改進的一種方案，通過對文件描述符上的事件狀態來進行判斷。下圖為通過select進行輪詢的示意圖。

select輪詢具有一個較弱的限制，那就是由于它采用一個1024長度的數組來存儲狀態，所以它最多可以同時檢查1024個文件描述符。

poll

該方案較select有所改進，采用鏈表的方式避免數組長度的限制，其次它能避免不需要的檢查。但是當文件描述符較多的時候，它的性能還是十分低下的。下圖為通過poll實現輪詢的示意圖，它與select相似，但性能限制有所改善。

epoll

該方案是Linux下效率最高的I/O事件通知機制，在進入輪詢的時候如果沒有檢查到I/O事件，將會進行休眠，直到事件發生將它喚醒。它是真實利用了事件通知、執行回調的方式，而不是遍歷查詢，所以不會浪費CPU，執行效率較高。下圖為通過epoll方式實現輪詢的示意圖。

輪詢技術滿足了非阻塞I/O確保獲取完整數據的需求，但是對于應用程序而言，它仍然只能算是一種同步，因為應用程序仍然需要等待I/O完全返回，依舊花費了很多時間來等待。等待期間，CPU要么用于遍歷文件描述符的狀態，要么用于休眠等待事件發生。結論是它不夠好。

5.盡管epoll已經利用了事件來降低CPU的耗用，但是休眠期間CPU幾乎是閑置的，對于當前線程而言利用率不夠。那么，是否有一種理想的異步I/O呢?

有啊。

我們期望的完美的異步I/O應該是應用程序發起非阻塞調用，無須通過遍歷或者事件喚醒等方式輪詢，可以直接處理下一個任務，只需在I/O完成后通過信號或回調將數據傳遞給應用程序即可

幸運的是，在Linux下存在這樣一種方式，它原生提供的一種異步I/O方式(AIO)就是通過信號或回調來傳遞數據的。

但不幸的是，只有Linux下有，而且它還有缺陷——AIO僅支持內核I/O中的O_DIRECT方式讀取，導致無法利用系統緩存。

6.現實的異步I/O是怎么實現的?

現實比理想要骨感一些，但是要達成異步I/O的目標，并非難事。前面我們將場景限定在了單線程的狀況下，多線程的方式會是另一番風景。通過讓部分線程進行阻塞I/O或者非阻塞I/O加輪詢技術來完成數據獲取，讓一個線程進行計算處理，通過線程之間的通信將I/O得到的數據進行傳遞，這就輕松實現了異步I/O(盡管它是模擬的)，示意圖如圖。

另一個需要強調的地方在于我們時常提到Node是單線程的，這里的單線程僅僅只是JavaScript執行在單線程中罷了。在Node中，無論是*nix還是Windows平臺，內部完成I/O任務的另有線程池。

7.以上是系統對異步IO的實現，那node中是怎么實現異步IO的

完成整個異步I/O環節的有事件循環、觀察者、線程池和請求對象等。

事件循環

首先，我們著重強調一下Node自身的執行模型——事件循環，正是它使得回調函數十分普遍。

在進程啟動時，Node便會創建一個類似于while(true)的循環，每執行一次循環體的過程我們稱為Tick。每個Tick的過程就是查看是否有事件待處理，如果有，就取出事件及其相關的回調函數。如果存在關聯的回調函數，就執行它們。然后進入下個循環，如果不再有事件處理，就退出進程。流程圖如圖

觀察者

在每個Tick的過程中，如何判斷是否有事件需要處理呢?這里必須要引入的概念是觀察者。每個事件循環中有一個或者多個觀察者，而判斷是否有事件要處理的過程就是向這些觀察者詢問是否有要處理的事件。

這個過程就如同飯館的廚房，廚房一輪一輪地制作菜肴，但是要具體制作哪些菜肴取決于收銀臺收到的客人的下單。廚房每做完一輪菜肴，就去問收銀臺的小妹，接下來有沒有要做的菜，如果沒有的話，就下班打烊了。

在這個過程中，收銀臺的小妹就是觀察者，她收到的客人點單就是關聯的回調函數。當然，如果飯館經營有方，它可能有多個收銀員，就如同事件循環中有多個觀察者一樣。收到下單就是一個事件，一個觀察者里可能有多個事件。

瀏覽器采用了類似的機制。事件可能來自用戶的點擊或者加載某些文件時產生，而這些產生的事件都有對應的觀察者。在Node中，事件主要來源于網絡請求、文件I/O等，這些事件對應的觀察者有文件I/O觀察者、網絡I/O觀察者等。觀察者將事件進行了分類。

事件循環是一個典型的生產者/消費者模型。異步I/O、網絡請求等則是事件的生產者，源源不斷為Node提供不同類型的事件，這些事件被傳遞到對應的觀察者那里，事件循環則從觀察者那里取出事件并處理。

請求對象

我們可以先看這張圖，大致了解一下node中異步io的實現，然后在看下面的分析。

由于下面的講解中會引用到內部的一些方法，要記住這些方法是很困難的，所以我建議不必深究這些方法是怎么寫的，只要能夠弄清楚這張圖的流程就好

我們將通過解釋Windows下異步I/O(利用IOCP實現)的簡單例子來探尋從JavaScript代碼到系統內核之間都發生了什么。對于一般的(非異步)回調函數，函數由我們自行調用，如下所示：

var forEach = function (list, callback) { 
    for (var i = 0; i < list.length; i++) { 
        callback(list[i], i, list); 
    } 
};

對于Node中的異步I/O調用而言，回調函數卻不由開發者來調用。那么從我們發出調用后，到回調函數被執行，中間發生了什么呢?事實上，從JavaScript發起調用到內核執行完I/O操作的過渡過程中，存在一種中間產物，它叫做請求對象。

下面我們以最簡單的fs.open()方法來作為例子，探索Node與底層之間是如何執行異步I/O調用以及回調函數究竟是如何被調用執行的：

fs.open = function (path, flags, mode, callback) { 
    // ... 
    binding.open(pathModule._makeLong(path), 
        stringToFlags(flags), 
        mode, 
        callback); 
};

fs.open()的作用是根據指定路徑和參數去打開一個文件，從而得到一個文件描述符，這是后續所有I/O操作的初始操作。從前面的代碼中可以看到，JavaScript層面的代碼通過調用C++核心模塊進行下層的操作。

從JavaScript調用Node的核心模塊，核心模塊調用C++內建模塊，內建模塊通過libuv進行系統調用，這是Node里經典的調用方式。這里libuv作為封裝層，有兩個平臺的實現，實質上是調用了uv_fs_open()方法。在uv_fs_open()的調用過程中，我們創建了一個FSReqWrap請求對象。從JavaScript層傳入的參數和當前方法都被封裝在這個請求對象中，其中我們最為關注的回調函數則被設置在這個對象的oncomplete_sym屬性上：

req_wrap->object_->Set(oncomplete_sym, callback);

對象包裝完畢后，在Windows下，則調用QueueUserWorkItem()方法將這個FSReqWrap對象推入線程池中等待執行，該方法的代碼如下所示：

QueueUserWorkItem(& uv_fs_thread_proc, req, WT_EXECUTEDEFAULT)

QueueUserWorkItem()方法接受3個參數：第一個參數是將要執行的方法的引用，這里引用的是uv_fs_thread_proc，第二個參數是uv_fs_thread_proc方法運行時所需要的參數;第三個參數是執行的標志。當線程池中有可用線程時，我們會調用uv_fs_thread_proc()方法。

uv_fs_thread_proc()方法會根據傳入參數的類型調用相應的底層函數。以uv_fs_open()為例，實際上調用fs__open()方法。

至此，JavaScript調用立即返回，由JavaScript層面發起的異步調用的第一階段就此結束。JavaScript線程可以繼續執行當前任務的后續操作。當前的I/O操作在線程池中等待執行，不管它是否阻塞I/O，都不會影響到JavaScript線程的后續執行，如此就達到了異步的目的。

請求對象是異步I/O過程中的重要中間產物，所有的狀態都保存在這個對象中，包括送入線程池等待執行以及I/O操作完畢后的回調處理。

8.So嘎，上面講得是異步方法的調用，也就是fs.open這個方法的調用，那后面的io操作以及回調函數的執行呢?

簡單的回答就是：調用fs.open這個方法之后就會獲得一個io讀取操作，然后把這個操作放入到線程池，等待有空的線程來執行io的讀取操作，然后得到結果，將數據傳遞給回調函數，再執行，再執行回調。

如下圖所示。

下面是詳細講解：

組裝好請求對象、送入I/O線程池等待執行，實際上完成了異步I/O的第一部分，回調通知是第二部分。

線程池中的I/O操作調用完畢之后，會將獲取的結果儲存在req->result屬性上，然后調用PostQueuedCompletionStatus()通知IOCP，告知當前對象操作已經完成：

PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped))

PostQueuedCompletionStatus()方法的作用是向IOCP提交執行狀態，并將線程歸還線程池。通過PostQueuedCompletionStatus()方法提交的狀態，可以通過GetQueuedCompletionStatus()提取。

在這個過程中，我們其實還動用了事件循環的I/O觀察者。在每次Tick的執行中，它會調用IOCP相關的GetQueuedCompletionStatus()方法檢查線程池中是否有執行完的請求，如果存在，會將請求對象加入到I/O觀察者的隊列中，然后將其當做事件處理。

I/O觀察者回調函數的行為就是取出請求對象的result屬性作為參數，取出oncomplete_sym屬性作為方法，然后調用執行，以此達到調用JavaScript中傳入的回調函數的目的。至此，整個異步I/O的流程完全結束。

事件循環、觀察者、請求對象、I/O線程池這四者共同構成了Node異步I/O模型的基本要素。

9.setTimeout()、setInterval()、setImmediate()和process.nextTick()也是異步IO嗎?

并不是，這些是異步API。

這一部分也值得略微關注一下。

定時器

setTimeout()和setInterval()與瀏覽器中的API是一致的，分別用于單次和多次定時執行任務。它們的實現原理與異步I/O比較類似，只是不需要I/O線程池的參與。調用setTimeout()或者setInterval()創建的定時器會被插入到定時器觀察者內部的一個紅黑樹中。每次Tick執行時，會從該紅黑樹中迭代取出定時器對象，檢查是否超過定時時間，如果超過，就形成一個事件，它的回調函數將立即執行。

定時器的問題在于，它并非精確的(在容忍范圍內)。盡管事件循環十分快，但是如果某一次循環占用的時間較多，那么下次循環時，它也許已經超時很久了。譬如通過setTimeout()設定一個任務在10毫秒后執行，但是在9毫秒后，有一個任務占用了5毫秒的CPU時間片，再次輪到定時器執行時，時間就已經過期4毫秒。

process.nextTick()

在未了解process.nextTick()之前，很多人也許為了立即異步執行一個任務，會這樣調用setTimeout()來達到所需的效果：

setTimeout(function () { 
    // TODO 
}, 0);

由于事件循環自身的特點，定時器的精確度不夠。而事實上，采用定時器需要動用紅黑樹，創建定時器對象和迭代等操作，而setTimeout(fn, 0)的方式較為浪費性能。實際上，process.nextTick()方法的操作相對較為輕量，具體代碼如下：

process.nextTick = function (callback) { 
    // on the way out, don't bother. 
    // it won't get fired anyway 
    if (process._exiting) return; 
 
    if (tickDepth >= process.maxTickDepth) 
        maxTickWarn(); 
 
    var tock = { callback: callback }; 
    if (process.domain) tock.domain = process.domain; 
    nextTickQueue.push(tock); 
    if (nextTickQueue.length) { 
        process._needTickCallback(); 
    } 
};

每次調用process.nextTick()方法，只會將回調函數放入隊列中，在下一輪Tick時取出執行。定時器中采用紅黑樹的操作時間復雜度為O(lg(n)), nextTick()的時間復雜度為O(1)。相較之下，process.nextTick()更高效。

setImmediate()

setImmediate()方法與process.nextTick()方法十分類似，都是將回調函數延遲執行。在Node v0.9.1之前，setImmediate()還沒有實現，那時候實現類似的功能主要是通過process.nextTick()來完成，該方法的代碼如下所示：

process.nextTick(function () { 
    console.log(’延遲執行’); 
}); 
console.log(’正常執行’);

上述代碼的輸出結果如下：

而用setImmediate()實現時，相關代碼如下：

setImmediate(function () { 
    console.log(’延遲執行’); 
}); 
console.log(’正常執行’);

其結果完全一樣：

但是兩者之間其實是有細微差別的。將它們放在一起時，又會是怎樣的優先級呢。示例代碼如下：

process.nextTick(function () { 
    console.log('nextTick延遲執行’); 
  }); 
setImmediate(function () { 
    console.log('setImmediate延遲執行’); 
  }); 
console.log(’正常執行’);

其執行結果如下：

從結果里可以看到，process.nextTick()中的回調函數執行的優先級要高于setImmediate()。這里的原因在于事件循環對觀察者的檢查是有先后順序的，process.nextTick()屬于idle觀察者，setImmediate()屬于check觀察者。在每一個輪循環檢查中，idle觀察者先于I/O觀察者，I/O觀察者先于check觀察者。

在具體實現上，process.nextTick()的回調函數保存在一個數組中，setImmediate()的結果則是保存在鏈表中。在行為上，process.nextTick()在每輪循環中會將數組中的回調函數全部執行完，而setImmediate()在每輪循環中執行鏈表中的一個回調函數。如下的示例代碼可以佐證：

// 加入兩個nextTick()的回調函數 
process.nextTick(function () { 
    console.log('nextTick延遲執行1'); 
}); 
process.nextTick(function () { 
    console.log('nextTick延遲執行2'); 
}); 
// 加入兩個setImmediate()的回調函數 
setImmediate(function () { 
    console.log('setImmediate延遲執行1'); 
    // 進入下次循環 
    process.nextTick(function () { 
        console.log(’強勢插入’); 
    }); 
}); 
setImmediate(function () { 
    console.log('setImmediate延遲執行2'); 
}); 
console.log(’正常執行’);