剖析Node定時器

JavaScript 是單線程運行，異步操作特別重要。

只要用到引擎之外的功能，就需要跟外部交互，從而形成異步操作。由于異步操作實在太多，JavaScript 不得不提供很多異步語法。這就好比，有些人老是受打擊， 他的抗打擊能力必須變得很強，否則他就完蛋了。

Node 的異步語法比瀏覽器更復(fù)雜，因為它可以跟內(nèi)核對話，不得不搞了一個專門的庫 libuv 做這件事。這個庫負(fù)責(zé)各種回調(diào)函數(shù)的執(zhí)行時間，畢竟異步任務(wù)最后還是要回到主線程，一個個排隊執(zhí)行。

為了協(xié)調(diào)異步任務(wù)，Node 居然提供了四個定時器，讓任務(wù)可以在指定的時間運行。

• setTimeout()
• setInterval()
• setImmediate()
• process.nextTick()

前兩個是語言的標(biāo)準(zhǔn)，后兩個是 Node 獨有的。它們的寫法差不多，作用也差不多，不太容易區(qū)別。

你能說出下面代碼的運行結(jié)果嗎？

// test.js

setTimeout(() => console.log(1));

setImmediate(() => console.log(2));

process.nextTick(() => console.log(3));

Promise.resolve().then(() => console.log(4));

(() => console.log(5))();

運行結(jié)果如下。

$ node test.js

5

3

4

1

2

如果你能一口說對，可能就不需要再看下去了。本文詳細(xì)解釋，Node 怎么處理各種定時器，或者更廣義地說，libuv 庫怎么安排異步任務(wù)在主線程上執(zhí)行。

一、同步任務(wù)和異步任務(wù)

首先，同步任務(wù)總是比異步任務(wù)更早執(zhí)行。

前面的那段代碼，只有最后一行是同步任務(wù)，因此最早執(zhí)行。

(() => console.log(5))();

二、本輪循環(huán)和次輪循環(huán)

異步任務(wù)可以分成兩種。

• 追加在本輪循環(huán)的異步任務(wù)
• 追加在次輪循環(huán)的異步任務(wù)

所謂”循環(huán)”，指的是事件循環(huán)（event loop）。這是 JavaScript 引擎處理異步任務(wù)的方式，后文會詳細(xì)解釋。這里只要理解，本輪循環(huán)一定早于次輪循環(huán)執(zhí)行即可。

Node 規(guī)定，process.nextTick和Promise的回調(diào)函數(shù)，追加在本輪循環(huán)，即同步任務(wù)一旦執(zhí)行完成，就開始執(zhí)行它們。而setTimeout、setInterval、setImmediate的回調(diào)函數(shù)，追加在次輪循環(huán)。

這就是說，文首那段代碼的第三行和第四行，一定比第一行和第二行更早執(zhí)行。

// 下面兩行，次輪循環(huán)執(zhí)行

setTimeout(() => console.log(1));

setImmediate(() => console.log(2));

// 下面兩行，本輪循環(huán)執(zhí)行

process.nextTick(() => console.log(3));

Promise.resolve().then(() => console.log(4));

三、process.nextTick()

process.nextTick這個名字有點誤導(dǎo)，它是在本輪循環(huán)執(zhí)行的，而且是所有異步任務(wù)里面最快執(zhí)行的。

Node 執(zhí)行完所有同步任務(wù)，接下來就會執(zhí)行process.nextTick的任務(wù)隊列。所以，下面這行代碼是第二個輸出結(jié)果。

process.nextTick(() => console.log(3));

基本上，如果你希望異步任務(wù)盡可能快地執(zhí)行，那就使用process.nextTick。

四、微任務(wù)

根據(jù)語言規(guī)格，Promise對象的回調(diào)函數(shù)，會進(jìn)入異步任務(wù)里面的”微任務(wù)”（microtask）隊列。

微任務(wù)隊列追加在process.nextTick隊列的后面，也屬于本輪循環(huán)。所以，下面的代碼總是先輸出3，再輸出4。

process.nextTick(() => console.log(3));

Promise.resolve().then(() => console.log(4));

// 3

// 4

注意，只有前一個隊列全部清空以后，才會執(zhí)行下一個隊列。

process.nextTick(() => console.log(1));

Promise.resolve().then(() => console.log(2));

process.nextTick(() => console.log(3));

Promise.resolve().then(() => console.log(4));

// 1

// 3

// 2

// 4

上面代碼中，全部process.nextTick的回調(diào)函數(shù)，執(zhí)行都會早于Promise的。

至此，本輪循環(huán)的執(zhí)行順序就講完了。

1. 同步任務(wù)
2. process.nextTick()
3. 微任務(wù)

五、事件循環(huán)的概念

下面開始介紹次輪循環(huán)的執(zhí)行順序，這就必須理解什么是事件循環(huán)（event loop）了。

Node 的官方文檔是這樣介紹的。

“When Node.js starts, it initializes the event loop, processes the provided input script which may make async API calls, schedule timers, or call process.nextTick(), then begins processing the event loop.”

這段話很重要，需要仔細(xì)讀。它表達(dá)了三層意思。

首先，有些人以為，除了主線程，還存在一個單獨的事件循環(huán)線程。不是這樣的，只有一個主線程，事件循環(huán)是在主線程上完成的。

其次，Node 開始執(zhí)行腳本時，會先進(jìn)行事件循環(huán)的初始化，但是這時事件循環(huán)還沒有開始，會先完成下面的事情。

• 同步任務(wù)
• 發(fā)出異步請求
• 規(guī)劃定時器生效的時間
• 執(zhí)行process.nextTick()等等

最后，上面這些事情都干完了，事件循環(huán)就正式開始了。

六、事件循環(huán)的六個階段

事件循環(huán)會無限次地執(zhí)行，一輪又一輪。只有異步任務(wù)的回調(diào)函數(shù)隊列清空了，才會停止執(zhí)行。

每一輪的事件循環(huán)，分成六個階段。這些階段會依次執(zhí)行。

1. timers
2. I/O callbacks
3. idle, prepare
4. poll
5. check
6. close callbacks

每個階段都有一個先進(jìn)先出的回調(diào)函數(shù)隊列。只有一個階段的回調(diào)函數(shù)隊列清空了，該執(zhí)行的回調(diào)函數(shù)都執(zhí)行了，事件循環(huán)才會進(jìn)入下一個階段。

下面簡單介紹一下每個階段的含義，詳細(xì)介紹可以看官方文檔，也可以參考 libuv 的源碼解讀。

（1）timers

這個是定時器階段，處理setTimeout()和setInterval()的回調(diào)函數(shù)。進(jìn)入這個階段后，主線程會檢查一下當(dāng)前時間，是否滿足定時器的條件。如果滿足就執(zhí)行回調(diào)函數(shù)，否則就離開這個階段。

（2）I/O callbacks

除了以下操作的回調(diào)函數(shù)，其他的回調(diào)函數(shù)都在這個階段執(zhí)行。

• setTimeout()和setInterval()的回調(diào)函數(shù)
• setImmediate()的回調(diào)函數(shù)
• 用于關(guān)閉請求的回調(diào)函數(shù)，比如socket.on('close', ...)

（3）idle, prepare

該階段只供 libuv 內(nèi)部調(diào)用，這里可以忽略。

（4）Poll

這個階段是輪詢時間，用于等待還未返回的 I/O 事件，比如服務(wù)器的回應(yīng)、用戶移動鼠標(biāo)等等。

這個階段的時間會比較長。如果沒有其他異步任務(wù)要處理（比如到期的定時器），會一直停留在這個階段，等待 I/O 請求返回結(jié)果。

（5）check

該階段執(zhí)行setImmediate()的回調(diào)函數(shù)。

（6）close callbacks

該階段執(zhí)行關(guān)閉請求的回調(diào)函數(shù)，比如socket.on('close', ...)。

七、事件循環(huán)的示例

下面是來自官方文檔的一個示例。

const fs = require('fs');

const timeoutScheduled = Date.now();

// 異步任務(wù)一：100ms 后執(zhí)行的定時器

setTimeout(() => {

const delay = Date.now() - timeoutScheduled;

console.log(${delay}ms);

}, 100);

// 異步任務(wù)二：至少需要 200ms 的文件讀取

fs.readFile('test.js', () => {

const startCallback = Date.now();

while (Date.now() - startCallback < 200) {

// 什么也不做

}

});

上面代碼有兩個異步任務(wù)，一個是 100ms 后執(zhí)行的定時器，一個是至少需要 200ms 的文件讀取。請問運行結(jié)果是什么？

腳本進(jìn)入第一輪事件循環(huán)以后，沒有到期的定時器，也沒有已經(jīng)可以執(zhí)行的 I/O 回調(diào)函數(shù)，所以會進(jìn)入 Poll 階段，等待內(nèi)核返回文件讀取的結(jié)果。由于讀取小文件一般不會超過 100ms，所以在定時器到期之前，Poll 階段就會得到結(jié)果，因此就會繼續(xù)往下執(zhí)行。

第二輪事件循環(huán)，依然沒有到期的定時器，但是已經(jīng)有了可以執(zhí)行的 I/O 回調(diào)函數(shù)，所以會進(jìn)入 I/O callbacks 階段，執(zhí)行fs.readFile的回調(diào)函數(shù)。這個回調(diào)函數(shù)需要 200ms，也就是說，在它執(zhí)行到一半的時候，100ms 的定時器就會到期。但是，必須等到這個回調(diào)函數(shù)執(zhí)行完，才會離開這個階段。

第三輪事件循環(huán)，已經(jīng)有了到期的定時器，所以會在 timers 階段執(zhí)行定時器。最后輸出結(jié)果大概是200多毫秒。

八、setTimeout 和 setImmediate

由于setTimeout在 timers 階段執(zhí)行，而setImmediate在 check 階段執(zhí)行。所以，setTimeout會早于setImmediate完成。

setTimeout(() => console.log(1));

setImmediate(() => console.log(2));

上面代碼應(yīng)該先輸出1，再輸出2，但是實際執(zhí)行的時候，結(jié)果卻是不確定，有時還會先輸出2，再輸出1。

這是因為setTimeout的第二個參數(shù)默認(rèn)為0。但是實際上，Node 做不到0毫秒，最少也需要1毫秒，根據(jù)官方文檔，第二個參數(shù)的取值范圍在1毫秒到2147483647毫秒之間。也就是說，setTimeout(f, 0)等同于setTimeout(f, 1)。

實際執(zhí)行的時候，進(jìn)入事件循環(huán)以后，有可能到了1毫秒，也可能還沒到1毫秒，取決于系統(tǒng)當(dāng)時的狀況。如果沒到1毫秒，那么 timers 階段就會跳過，進(jìn)入 check 階段，先執(zhí)行setImmediate的回調(diào)函數(shù)。

但是，下面的代碼一定是先輸出2，再輸出1。

const fs = require('fs');

fs.readFile('test.js', () => {

setTimeout(() => console.log(1));

setImmediate(() => console.log(2));

});

上面代碼會先進(jìn)入 I/O callbacks 階段，然后是 check 階段，最后才是 timers 階段。因此，setImmediate才會早于setTimeout執(zhí)行。

九、參考鏈接

• The Node.js Event Loop, Timers, and process.nextTick(), by Node.js
• Handling IO?–?NodeJS Event Loop, by Deepal Jayasekara
• setImmediate() vs nextTick() vs setTimeout(fn,0) – in depth explanation, by Paul Shan
• Node.js event loop workflow & lifecycle in low level, by Paul Shan

（完）