Node.js 事件循環,定時器和 process.nextTick()
什麼是事件輪詢
事件循環是 Node.js 處理非阻塞 I/O 操作的機制——儘管 JavaScript 是單線程處理的——當有可能的時候,它們會把操作轉移到系統內核中去。
既然目前大多數內核都是多線程的,它們可在後臺處理多種操作。當其中的一個操作完成的時候,內核通知 Node.js 將適合的回調函數添加到 輪詢 隊列中等待時機執行。我們在本文後面會進行詳細介紹。
事件輪詢機制解析
當 Node.js 啓動後,它會初始化事件輪詢;處理已提供的輸入腳本(或丟入 REPL,本文不涉及到),它可能會調用一些異步的 API、調度定時器,或者調用 process.nextTick()
,然後開始處理事件循環。
下面的圖表展示了事件循環操作順序的簡化概覽。
┌───────────────────────────┐
┌─>│ timers │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │
│ └─────────────┬─────────────┘ ┌───────────────┐
│ ┌─────────────┴─────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └─────────────┬─────────────┘ │ data, etc. │
│ ┌─────────────┴─────────────┐ └───────────────┘
│ │ check │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │
└───────────────────────────┘
注意:每個框被稱爲事件循環機制的一個階段。
每個階段都有一個 FIFO 隊列來執行回調。雖然每個階段都是特殊的,但通常情況下,當事件循環進入給定的階段時,它將執行特定於該階段的任何操作,然後執行該階段隊列中的回調,直到隊列用盡或最大回調數已執行。當該隊列已用盡或達到回調限制,事件循環將移動到下一階段,等等。
由於這些操作中的任何一個都可能調度 更多的 操作和由內核排列在輪詢階段被處理的新事件, 且在處理輪詢中的事件時,輪詢事件可以排隊。因此,長時間運行的回調可以允許輪詢階段運行長於計時器的閾值時間。有關詳細信息,請參閱 計時器 和 輪詢 部分。
注意: 在 Windows 和 Unix/Linux 實現之間存在細微的差異,但這對演示來說並不重要。最重要的部分在這裏。實際上有七或八個步驟,但我們關心的是 Node.js 實際上使用以上的某些步驟。
階段概述
- 定時器:本階段執行已經被
setTimeout()
和setInterval()
的調度回調函數。 - 待定回調:執行延遲到下一個循環迭代的 I/O 回調。
- idle, prepare:僅系統內部使用。
- 輪詢:檢索新的 I/O 事件;執行與 I/O 相關的回調(幾乎所有情況下,除了關閉的回調函數,那些由計時器和
setImmediate()
調度的之外),其餘情況 node 將在適當的時候在此阻塞。 - 檢測:
setImmediate()
回調函數在這裏執行。 - 關閉的回調函數:一些關閉的回調函數,如:
socket.on('close', ...)
。
在每次運行的事件循環之間,Node.js 檢查它是否在等待任何異步 I/O 或計時器,如果沒有的話,則完全關閉。
階段的詳細概述
定時器
計時器指定 可以執行所提供回調 的 閾值,而不是用戶希望其執行的確切時間。在指定的一段時間間隔後, 計時器回調將被儘可能早地運行。但是,操作系統調度或其它正在運行的回調可能會延遲它們。
注意:輪詢 階段 控制何時定時器執行。
例如,假設您調度了一個在 100 毫秒後超時的定時器,然後您的腳本開始異步讀取會耗費 95 毫秒的文件:
const fs = require('fs');
function someAsyncOperation(callback) {
// Assume this takes 95ms to complete
fs.readFile('/path/to/file', callback);
}
const timeoutScheduled = Date.now();
setTimeout(() => {
const delay = Date.now() - timeoutScheduled;
console.log(`${delay}ms have passed since I was scheduled`);
}, 100);
// do someAsyncOperation which takes 95 ms to complete
someAsyncOperation(() => {
const startCallback = Date.now();
// do something that will take 10ms...
while (Date.now() - startCallback < 10) {
// do nothing
}
});
當事件循環進入 輪詢 階段時,它有一個空隊列(此時 fs.readFile()
尚未完成),因此它將等待剩下的毫秒數,直到達到最快的一個計時器閾值爲止。當它等待 95 毫秒過後時,fs.readFile()
完成讀取文件,它的那個需要 10 毫秒才能完成的回調,將被添加到 輪詢 隊列中並執行。當回調完成時,隊列中不再有回調,因此事件循環機制將查看最快到達閾值的計時器,然後將回到 計時器 階段,以執行定時器的回調。在本示例中,您將看到調度計時器到它的回調被執行之間的總延遲將爲 105 毫秒。
注意:爲了防止 輪詢 階段餓死事件循環,libuv(實現 Node.js 事件循環和平臺的所有異步行爲的 C 函數庫),在停止輪詢以獲得更多事件之前,還有一個硬性最大值(依賴於系統)。
掛起的回調函數
此階段對某些系統操作(如 TCP 錯誤類型)執行回調。例如,如果 TCP 套接字在嘗試連接時接收到 ECONNREFUSED
,則某些 *nix 的系統希望等待報告錯誤。這將被排隊以在 掛起的回調 階段執行。
輪詢
輪詢 階段有兩個重要的功能:
- 計算應該阻塞和輪詢 I/O 的時間。
- 然後,處理 輪詢 隊列裏的事件。
當事件循環進入 輪詢 階段且 沒有被調度的計時器時 ,將發生以下兩種情況之一:
-
如果 輪詢 隊列 不是空的 ,事件循環將循環訪問回調隊列並同步執行它們,直到隊列已用盡,或者達到了與系統相關的硬性限制。
-
如果 輪詢 隊列 是空的 ,還有兩件事發生:
-
如果腳本被
setImmediate()
調度,則事件循環將結束 輪詢 階段,並繼續 檢查 階段以執行那些被調度的腳本。 -
如果腳本 未被
setImmediate()
調度,則事件循環將等待回調被添加到隊列中,然後立即執行。
-
一旦 輪詢 隊列爲空,事件循環將檢查 _已達到時間閾值的計時器_。如果一個或多個計時器已準備就緒,則事件循環將繞回計時器階段以執行這些計時器的回調。
檢查階段
此階段允許人員在輪詢階段完成後立即執行回調。如果輪詢階段變爲空閒狀態,並且腳本使用 setImmediate()
後被排列在隊列中,則事件循環可能繼續到 檢查 階段而不是等待。
setImmediate()
實際上是一個在事件循環的單獨階段運行的特殊計時器。它使用一個 libuv API 來安排回調在 輪詢 階段完成後執行。
通常,在執行代碼時,事件循環最終會命中輪詢階段,在那等待傳入連接、請求等。但是,如果回調已使用 setImmediate()
調度過,並且輪詢階段變爲空閒狀態,則它將結束此階段,並繼續到檢查階段而不是繼續等待輪詢事件。
關閉的回調函數
如果套接字或處理函數突然關閉(例如 socket.destroy()
),則'close'
事件將在這個階段發出。否則它將通過 process.nextTick()
發出。
setImmediate()
對比 setTimeout()
setImmediate()
和 setTimeout()
很類似,但是基於被調用的時機,他們也有不同表現。
setImmediate()
設計爲一旦在當前 輪詢 階段完成, 就執行腳本。setTimeout()
在最小閾值(ms 單位)過後運行腳本。
執行計時器的順序將根據調用它們的上下文而異。如果二者都從主模塊內調用,則計時器將受進程性能的約束(這可能會受到計算機上其他正在運行應用程序的影響)。
例如,如果運行以下不在 I/O 週期(即主模塊)內的腳本,則執行兩個計時器的順序是非確定性的,因爲它受進程性能的約束:
// timeout_vs_immediate.js
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
$ node timeout_vs_immediate.js
timeout
immediate
$ node timeout_vs_immediate.js
immediate
timeout
但是,如果你把這兩個函數放入一個 I/O 循環內調用,setImmediate 總是被優先調用:
// timeout_vs_immediate.js
const fs = require('fs');
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
});
$ node timeout_vs_immediate.js
immediate
timeout
$ node timeout_vs_immediate.js
immediate
timeout
使用 setImmediate()
相對於setTimeout()
的主要優勢是,如果setImmediate()
是在 I/O 週期內被調度的,那它將會在其中任何的定時器之前執行,跟這裏存在多少個定時器無關
process.nextTick()
理解 process.nextTick()
您可能已經注意到 process.nextTick()
在圖示中沒有顯示,即使它是異步 API 的一部分。這是因爲 process.nextTick()
從技術上講不是事件循環的一部分。相反,它都將在當前操作完成後處理 nextTickQueue
, 而不管事件循環的當前階段如何。這裏的一個操作被視作爲一個從底層 C/C++ 處理器開始過渡,並且處理需要執行的 JavaScript 代碼。
回顧我們的圖示,任何時候在給定的階段中調用 process.nextTick()
,所有傳遞到 process.nextTick()
的回調將在事件循環繼續之前解析。這可能會造成一些糟糕的情況,因爲它允許您通過遞歸 process.nextTick()
調用來“餓死”您的 I/O,阻止事件循環到達 輪詢 階段。
爲什麼會允許這樣?
爲什麼這樣的事情會包含在 Node.js 中?它的一部分是一個設計理念,其中 API 應該始終是異步的,即使它不必是。以此代碼段爲例:
function apiCall(arg, callback) {
if (typeof arg !== 'string')
return process.nextTick(callback,
new TypeError('argument should be string'));
}
代碼段進行參數檢查。如果不正確,則會將錯誤傳遞給回調函數。最近對 API 進行了更新,允許傳遞參數給 process.nextTick()
,這將允許它接受任何在回調函數位置之後的參數,並將參數傳遞給回調函數作爲回調函數的參數,這樣您就不必嵌套函數了。
我們正在做的是將錯誤傳回給用戶,但僅在執行用戶的其餘代碼之後。通過使用process.nextTick()
,我們保證 apiCall()
始終在用戶代碼的其餘部分之後和在讓事件循環繼續進行之前,執行其回調函數。爲了實現這一點,JS 調用棧被允許展開,然後立即執行提供的回調,允許進行遞歸調用 process.nextTick()
,而不觸碰 RangeError: 超過 V8 的最大調用堆棧大小
限制。
這種設計原理可能會導致一些潛在的問題。 以此代碼段爲例:
let bar;
// this has an asynchronous signature, but calls callback synchronously
function someAsyncApiCall(callback) { callback(); }
// the callback is called before `someAsyncApiCall` completes.
someAsyncApiCall(() => {
// since someAsyncApiCall has completed, bar hasn't been assigned any value
console.log('bar', bar); // undefined
});
bar = 1;
用戶將 someAsyncApiCall()
定義爲具有異步簽名,但實際上它是同步運行的。當調用它時,提供給 someAsyncApiCall()
的回調是在事件循環的同一階段內被調用,因爲 someAsyncApiCall()
實際上並沒有異步執行任何事情。結果,回調函數在嘗試引用 bar
,但作用域中可能還沒有該變量,因爲腳本尚未運行完成。
通過將回調置於 process.nextTick()
中,腳本仍具有運行完成的能力,允許在調用回調之前初始化所有的變量、函數等。它還具有不讓事件循環繼續的優點,適用於讓事件循環繼續之前,警告用戶發生錯誤的情況。下面是上一個使用 process.nextTick()
的示例:
let bar;
function someAsyncApiCall(callback) {
process.nextTick(callback);
}
someAsyncApiCall(() => {
console.log('bar', bar); // 1
});
bar = 1;
這又是另外一個真實的例子:
const server = net.createServer(() => {}).listen(8080);
server.on('listening', () => {});
只有傳遞端口時,端口才會立即被綁定。因此,可以立即調用 'listening'
回調。問題是 .on('listening')
的回調在那個時間點尚未被設置。
爲了繞過這個問題,'listening'
事件被排在 nextTick()
中,以允許腳本運行完成。這讓用戶設置所想設置的任何事件處理器。
process.nextTick()
對比 setImmediate()
就用戶而言,我們有兩個類似的調用,但它們的名稱令人費解。
process.nextTick()
在同一個階段立即執行。setImmediate()
在事件循環的接下來的迭代或 'tick' 上觸發。
實質上,這兩個名稱應該交換,因爲 process.nextTick()
比 setImmediate()
觸發得更快,但這是過去遺留問題,因此不太可能改變。如果貿然進行名稱交換,將破壞 npm 上的大部分軟件包。每天都有更多新的模塊在增加,這意味着我們要多等待每一天,則更多潛在破壞會發生。儘管這些名稱使人感到困惑,但它們本身名字不會改變。
我們建議開發人員在所有情況下都使用 setImmediate()
,因爲它更容易理解。
爲什麼要使用 process.nextTick()
?
有兩個主要原因:
-
允許用戶處理錯誤,清理任何不需要的資源,或者在事件循環繼續之前重試請求。
-
有時有讓回調在棧展開後,但在事件循環繼續之前運行的必要。
以下是一個符合用戶預期的簡單示例:
const server = net.createServer();
server.on('connection', (conn) => { });
server.listen(8080);
server.on('listening', () => { });
假設 listen()
在事件循環開始時運行,但 listening 的回調被放置在 setImmediate()
中。除非傳遞過主機名,纔會立即綁定到端口。爲使事件循環繼續進行,它必須命中 輪詢 階段,這意味着有可能已經接收了一個連接,並在偵聽事件之前觸發了連接事件。
另一個示例運行的函數構造函數是從 EventEmitter
繼承的,它想調用構造函數:
const EventEmitter = require('events');
const util = require('util');
function MyEmitter() {
EventEmitter.call(this);
this.emit('event');
}
util.inherits(MyEmitter, EventEmitter);
const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
console.log('an event occurred!');
});
你不能立即從構造函數中觸發事件,因爲腳本尚未處理到用戶爲該事件分配回調函數的地方。因此,在構造函數本身中可以使用 process.nextTick()
來設置回調,以便在構造函數完成後發出該事件,這是預期的結果:
const EventEmitter = require('events');
const util = require('util');
function MyEmitter() {
EventEmitter.call(this);
// use nextTick to emit the event once a handler is assigned
process.nextTick(() => {
this.emit('event');
});
}
util.inherits(MyEmitter, EventEmitter);
const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
console.log('an event occurred!');
});