摘要：問題引入接觸過事件循環(huán)的同學大都會糾結一個點，就是在中和執(zhí)行順序的隨機性。當隊列被執(zhí)行完，或者執(zhí)行的回調(diào)數(shù)量達到上限后，事件循環(huán)才會進入下一個階段。嵌套的在下一個事件循環(huán)的階段執(zhí)行回調(diào)輸出嵌套的。

接觸過事件循環(huán)的同學大都會糾結一個點，就是在Node中setTimeout和setImmediate執(zhí)行順序的隨機性。

比如說下面這段代碼：

setTimeout(() => {
    console.log("setTimeout");
}, 0);
setImmediate(() => {
    console.log("setImmediate");
})

執(zhí)行的結果是這樣子的：

為什么會出現(xiàn)這種情況呢？別急，我們先往下看。

我們都知道，JavaScript是單線程的語言，對I/O的控制是通過異步來實現(xiàn)的，具體是通過“事件循環(huán)”機制來實現(xiàn)。

對于JavaScript中的單線程，指的是JavaScript執(zhí)行在單線程中，而內(nèi)部I/O任務其實是另有線程池來完成的。

在瀏覽器中，我們討論事件循環(huán)，是以“從宏任務隊列中取一個任務執(zhí)行，再取出微任務隊列中的所有任務”來分析執(zhí)行代碼的。但是在Node環(huán)境中并不適用。具體的瀏覽器事件循環(huán)解析：傳送門

在Node中，事件循環(huán)的模型和瀏覽器相比大致相同，而最大的不同點在于Node中事件循環(huán)分不同的階段。具體我們下面會討論到。本文核心也在這里。

下面是事件循環(huán)不同階段的示意圖：

每個階段都有一個先進先出的回調(diào)隊列要執(zhí)行。而每個階段都有自己的特殊之處。簡單來說，就是當事件循環(huán)進入某個階段后，會執(zhí)行該階段特定的任意操作，然后才會執(zhí)行這個階段里的回調(diào)。當隊列被執(zhí)行完，或者執(zhí)行的回調(diào)數(shù)量達到上限后，事件循環(huán)才會進入下一個階段。

以下是各個階段詳情。

一個timer指定一個下限時間而不是準確時間，在達到這個下限時間后執(zhí)行回調(diào)。在指定的時間過后，timers會盡早的執(zhí)行回調(diào)，但是系統(tǒng)調(diào)度或者其他回調(diào)的執(zhí)行可能會延遲它們。

從技術上來說，poll階段控制timers什么時候執(zhí)行，而執(zhí)行的具體位置在timers。

下限的時間有一個范圍：[1, 2147483647]，如果設定的時間不在這個范圍，將被設置為1。

這個階段執(zhí)行一些系統(tǒng)操作的回調(diào)，比如說TCP連接發(fā)生錯誤。

系統(tǒng)內(nèi)部的一些調(diào)用。

這是最復雜的一個階段。

poll階段有兩個主要的功能：一是執(zhí)行下限時間已經(jīng)達到的timers的回調(diào)，一是處理poll隊列里的事件。

注：Node很多API都是基于事件訂閱完成的，這些API的回調(diào)應該都在poll階段完成。

以下是Node官網(wǎng)的介紹：

筆者把官網(wǎng)陳述的情況以不同的條件分解，更加的清楚。（如果有誤，師請改正。）

當事件循環(huán)進入poll階段：

poll隊列不為空的時候，事件循環(huán)肯定是先遍歷隊列并同步執(zhí)行回調(diào)，直到隊列清空或執(zhí)行回調(diào)數(shù)達到系統(tǒng)上限。

poll隊列為空的時候，這里有兩種情況。

如果代碼已經(jīng)被setImmediate()設定了回調(diào)，那么事件循環(huán)直接結束poll階段進入check階段來執(zhí)行check隊列里的回調(diào)。

如果代碼沒有被設定setImmediate()設定回調(diào)：

如果有被設定的timers，那么此時事件循環(huán)會檢查timers，如果有一個或多個timers下限時間已經(jīng)到達，那么事件循環(huán)將繞回timers階段，并執(zhí)行timers的有效回調(diào)隊列。

如果沒有被設定timers，這個時候事件循環(huán)是阻塞在poll階段等待回調(diào)被加入poll隊列。

這個階段允許在poll階段結束后立即執(zhí)行回調(diào)。如果poll階段空閑，并且有被setImmediate()設定的回調(diào)，那么事件循環(huán)直接跳到check執(zhí)行而不是阻塞在poll階段等待回調(diào)被加入。

setImmediate()實際上是一個特殊的timer，跑在事件循環(huán)中的一個獨立的階段。它使用libuv的API來設定在poll階段結束后立即執(zhí)行回調(diào)。

注：setImmediate()具有最高優(yōu)先級，只要poll隊列為空，代碼被setImmediate()，無論是否有timers達到下限時間，setImmediate()的代碼都先執(zhí)行。

如果一個socket或handle被突然關掉（比如socket.destroy()），close事件將在這個階段被觸發(fā)，否則將通過process.nextTick()觸發(fā)。

代碼重現(xiàn)，我們會發(fā)現(xiàn)setTimeout和setImmediate在Node環(huán)境下執(zhí)行是靠“隨緣法則”的。

比如說下面這段代碼：

setTimeout(() => {
    console.log("setTimeout");
}, 0);
setImmediate(() => {
    console.log("setImmediate");
})

執(zhí)行的結果是這樣子的：

為什么會這樣子呢？

這里我們要根據(jù)前面的那個事件循環(huán)不同階段的圖解來說明一下：

首先進入的是timers階段，如果我們的機器性能一般，那么進入timers階段，一毫秒已經(jīng)過去了（setTimeout(fn, 0)等價于setTimeout(fn, 1)），那么setTimeout的回調(diào)會首先執(zhí)行。

如果沒有到一毫秒，那么在timers階段的時候，下限時間沒到，setTimeout回調(diào)不執(zhí)行，事件循環(huán)來到了poll階段，這個時候隊列為空，此時有代碼被setImmediate()，于是先執(zhí)行了setImmediate()的回調(diào)函數(shù)，之后在下一個事件循環(huán)再執(zhí)行setTimemout的回調(diào)函數(shù)。

而我們在執(zhí)行代碼的時候，進入timers的時間延遲其實是隨機的，并不是確定的，所以會出現(xiàn)兩個函數(shù)執(zhí)行順序隨機的情況。

那我們再來看一段代碼：

var fs = require("fs")

fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log("timeout");
    }, 0);
    setImmediate(() => {
        console.log("immediate");
    });
});

這里我們就會發(fā)現(xiàn)，setImmediate永遠先于setTimeout執(zhí)行。

原因如下：

fs.readFile的回調(diào)是在poll階段執(zhí)行的，當其回調(diào)執(zhí)行完畢之后，poll隊列為空，而setTimeout入了timers的隊列，此時有代碼被setImmediate()，于是事件循環(huán)先進入check階段執(zhí)行回調(diào)，之后在下一個事件循環(huán)再在timers階段中執(zhí)行有效回調(diào)。

同樣的，這段代碼也是一樣的道理：

setTimeout(() => {
    setImmediate(() => {
        console.log("setImmediate");
    });
    setTimeout(() => {
        console.log("setTimeout");
    }, 0);
}, 0);

以上的代碼在timers階段執(zhí)行外部的setTimeout回調(diào)后，內(nèi)層的setTimeout和setImmediate入隊，之后事件循環(huán)繼續(xù)往后面的階段走，走到poll階段的時候發(fā)現(xiàn)隊列為空，此時有代碼被setImmedate()，所以直接進入check階段執(zhí)行響應回調(diào)（注意這里沒有去檢測timers隊列中是否有成員到達下限事件，因為setImmediate()優(yōu)先）。之后在第二個事件循環(huán)的timers階段中再去執(zhí)行相應的回調(diào)。

綜上，我們可以總結：

如果兩者都在主模塊中調(diào)用，那么執(zhí)行先后取決于進程性能，也就是隨機。

如果兩者都不在主模塊調(diào)用（被一個異步操作包裹），那么setImmediate的回調(diào)永遠先執(zhí)行。

對于這兩個，我們可以把它們理解成一個微任務。也就是說，它其實不屬于事件循環(huán)的一部分。

那么他們是在什么時候執(zhí)行呢？

不管在什么地方調(diào)用，他們都會在其所處的事件循環(huán)最后，事件循環(huán)進入下一個循環(huán)的階段前執(zhí)行。

舉個?：

setTimeout(() => {
    console.log("timeout0");
    process.nextTick(() => {
        console.log("nextTick1");
        process.nextTick(() => {
            console.log("nextTick2");
        });
    });
    process.nextTick(() => {
        console.log("nextTick3");
    });
    console.log("sync");
    setTimeout(() => {
        console.log("timeout2");
    }, 0);
}, 0);

結果是：

再解釋一下：

timers階段執(zhí)行外層setTimeout的回調(diào)，遇到同步代碼先執(zhí)行，也就有timeout0、sync的輸出。遇到process.nextTick后入微任務隊列，依次nextTick1、nextTick3、nextTick2入隊后出隊輸出。之后，在下一個事件循環(huán)的timers階段，執(zhí)行setTimeout回調(diào)輸出timeout2。

下面給出兩段代碼，如果能夠理解其執(zhí)行順序說明你已經(jīng)理解透徹。

代碼1：

setImmediate(function(){
  console.log("setImmediate");
  setImmediate(function(){
    console.log("嵌套setImmediate");
  });
  process.nextTick(function(){
    console.log("nextTick");
  })
});

// setImmediate
// nextTick
// 嵌套setImmediate

解析：事件循環(huán)check階段執(zhí)行回調(diào)函數(shù)輸出setImmediate，之后輸出nextTick。嵌套的setImmediate在下一個事件循環(huán)的check階段執(zhí)行回調(diào)輸出嵌套的setImmediate。

代碼2：

var fs = require("fs");

function someAsyncOperation (callback) {
  // 假設這個任務要消耗 95ms
  fs.readFile("/path/to/file", callback);
}

var timeoutScheduled = Date.now();

setTimeout(function () {

  var delay = Date.now() - timeoutScheduled;

  console.log(delay + "ms have passed since I was scheduled");
}, 100);


// someAsyncOperation要消耗 95 ms 才能完成
someAsyncOperation(function () {

  var startCallback = Date.now();

  // 消耗 10ms...
  while (Date.now() - startCallback < 10) {
    ; // do nothing
  }

});

解析：事件循環(huán)進入poll階段發(fā)現(xiàn)隊列為空，并且沒有代碼被setImmediate()。于是在poll階段等待timers下限時間到達。當?shù)鹊?b>95ms時，fs.readFile首先執(zhí)行了，它的回調(diào)被添加進poll隊列并同步執(zhí)行，耗時10ms。此時總共時間累積105ms。等到poll隊列為空的時候，事件循環(huán)會查看最近到達的timer的下限時間，發(fā)現(xiàn)已經(jīng)到達，再回到timers階段，執(zhí)行timer的回調(diào)。

如果有什么問題，歡迎留言交流探討。

參考鏈接：

https://nodejs.org/en/docs/gu...

https://github.com/creeperyan...