[[420503]]

一 前言

本文講詳細講解 nodejs 中兩個比較難以理解的部分異步I/O和事件循環(huán)，對 nodejs 核心知識點，做梳理和補充。

送人玫瑰，手有余香，希望閱讀后感覺不錯的同學，可以給點個贊，鼓勵我繼續(xù)創(chuàng)作前端硬文。

老規(guī)矩我們帶上疑問開始今天的分析??????：

• 1 說說 nodejs 的異步I/O ?
• 2 說說 nodejs 的事件循環(huán)機制 ?
• 3 介紹一下 nodejs 中事件循環(huán)的各個階段 ?
• 4 nodejs 中 promise 和 nextTick 的區(qū)別?
• 5 nodejs 中 setImmediate 和 setTimeout 區(qū)別 ?
• 6 setTimeout 是精確的嗎，什么情況影響 setTimeout 的執(zhí)行?
• 7 nodejs 中事件循環(huán)和瀏覽器有什么不同 ?

二 異步I/O

概念

處理器訪問任何寄存器和 Cache 等封裝以外的數(shù)據(jù)資源都可以當成 I/O 操作，包括內(nèi)存，磁盤，顯卡等外部設備。在 Nodejs 中像開發(fā)者調(diào)用 fs 讀取本地文件或網(wǎng)絡請求等操作都屬于I/O操作。(最普遍抽象 I/O 是文件操作和 TCP/UDP 網(wǎng)絡操作)

Nodejs 為單線程的，在單線程模式下，任務都是順序執(zhí)行的，但是前面的任務如果用時過長，那么勢必會影響到后續(xù)任務的進行，通常 I/O 與 cpu 之間的計算是可以并行進行的，但是同步的模式下，I/O的進行會導致后續(xù)任務的等待，這樣阻塞了任務的執(zhí)行，也造成了資源不能很好的利用。

為了解決如上的問題，Nodejs 選擇了異步I/O的模式，讓單線程不再阻塞，更合理的使用資源。

如何合理的看待Nodejs中異步I/O

前端開發(fā)者可能更清晰瀏覽器環(huán)境下的 JS 的異步任務，比如發(fā)起一次 ajax 請求，正如 ajax 是瀏覽器提供給 js 執(zhí)行環(huán)境下可以調(diào)用的 api 一樣 ，在 Nodejs 中提供了 http 模塊可以讓 js 做相同的事。比如監(jiān)聽|發(fā)送 http 請求，除了 http 之外，nodejs 還有操作本地文件的 fs 文件系統(tǒng)等。

如上 fs http 這些任務在 nodejs 中叫做 I/O 任務。理解了 I/O 任務之后，來分析一下在 Nodejs 中，I/O 任務的兩種形態(tài)——阻塞和非阻塞。

nodejs中阻塞和非阻塞IO

nodejs 對于大部分的 I/O 操作都提供了阻塞和非阻塞兩種用法。阻塞指的是執(zhí)行 I/O 操作的時候必須等待結果，才往下執(zhí)行 js 代碼。如下一下阻塞代碼

阻塞I/O

/* TODO:  阻塞 */ 
const fs = require('fs'); 
const data = fs.readFileSync('./file.js'); 
console.log(data) 

• 代碼阻塞 ：讀取同級目錄下的 file.js 文件，結果 data 為 buffer 結構，這樣當讀取過程中，會阻塞代碼的執(zhí)行，所以 console.log(data) 將被阻塞，只有當結果返回的時候，才能正常打印 data 。
• 異常處理 ：如上操作有一個致命點就是，如果出現(xiàn)了異常，(比如在同級目錄下沒有 file.js 文件)，就會讓整個程序報錯，接下來的代碼講不會執(zhí)行。通常需要 try catch來捕獲錯誤邊界。代碼如下：

/* TODO: 阻塞 - 捕獲異常  */ 
try{ 
    const fs = require('fs'); 
    const data = fs.readFileSync('./file1.js'); 
    console.log(data) 
}catch(e){ 
    console.log('發(fā)生錯誤：',e) 
} 
console.log('正常執(zhí)行') 

如上即便發(fā)生了錯誤，也不會影響到后續(xù)代碼的執(zhí)行以及應用程序發(fā)生錯誤導致的退出。

阻塞 I/O 造成代碼執(zhí)行等待 I/O 結果，浪費等待時間，CPU 的處理能力得不到充分利用，I/O 失敗還會讓整整個線程退出。阻塞 I / O 在整個調(diào)用棧上示意圖如下：

非阻塞I/O

Nodejs 的非阻塞 I/O 采用的是異步模式，就是剛剛介紹的異步I/O。首先看一下異步模式下的 I/O 操作：

/* TODO: 非阻塞 - 異步 I/O */ 
const fs = require('fs') 
fs.readFile('./file.js',(err,data)=>{ 
    console.log(err,data) // null  <Buffer 63 6f 6e 73 6f 6c 65 2e 6c 6f 67 28 27 68 65 6c 6c 6f 2c 77 6f 72 6c 64 27 29> 
}) 
console.log(111) // 111 先被打印～ 
 
fs.readFile('./file1.js',(err,data)=>{ 
    console.log(err,data) // 保存  [ no such file or directory, open './file1.js'] ，找不到文件。 
}) 

• 回調(diào) callback 被異步執(zhí)行，返回的第一個參數(shù)是錯誤信息，如果沒有錯誤，那么返回 null ，第二個參數(shù)為 fs.readFile 執(zhí)行得到的真正內(nèi)容。
• 這種異步的形式可以會優(yōu)雅的捕獲到執(zhí)行 I/O 中出現(xiàn)的錯誤，比如說如上當讀取 file1.js 文件時候，出現(xiàn)了找不到對應文件的異常行為，會直接通過第一個參數(shù)形式傳遞到 callback 中。

比如如上的 callback ，作為一個異步回調(diào)函數(shù)，就像 setTimeout(fn) 的 fn 一樣，不會阻塞代碼執(zhí)行。會在得到結果后觸發(fā)，對于 Nodejs 異步執(zhí)行 I/O 回調(diào)的細節(jié)，接下來會慢慢剖析。

對于異步 I/O 的處理， Nodejs 內(nèi)部使用了線程池來處理異步 I/O 任務，線程池中會有多個 I/O 線程來同時處理異步的 I/O 操作，比如如上的的例子中，在整個 I/O 模型中會這樣。

接下來將一起探索一下異步 I/O 執(zhí)行過程。

事件循環(huán)

和瀏覽器一樣，Nodejs 也有自身的執(zhí)行模型——事件循環(huán)( eventLoop )，事件循環(huán)的執(zhí)行模型受到宿主環(huán)境的影響，它不屬于 javascript 執(zhí)行引擎( 例如 v8 )的一部分，這就導致了不同宿主環(huán)境下事件循環(huán)模式和機制可能不同，直觀的體現(xiàn)就是 Nodejs 和瀏覽器環(huán)境下對微任務( microtask )和宏任務( macrotask )處理存在差異。對于 Nodejs 的事件循環(huán)及其每一個階段，接下來會詳細探討。

Nodejs 的事件循環(huán)有多個階段，其中有一個專門處理 I/O 回調(diào)的階段，每一個執(zhí)行階段我們可以稱之為 Tick ， 每一個 Tick 都會查詢是否還有事件以及關聯(lián)的回調(diào)函數(shù) ，如上異步 I/O 的回調(diào)函數(shù)，會在 I/O 處理階段檢查當前 I/O 是否完成，如果完成，那么執(zhí)行對應的 I/O 回調(diào)函數(shù)，那么這個檢查 I/O 是否完成的觀察者我們稱之為 I/O 觀察者。

觀察者

如上提到了 I/O 觀察者的概念，也講了 Nodejs 中會有多個階段，事實上每一個階段都有一個或者多個對應的觀察者，它們的工作很明確就是在每一次對應的 Tick 過程中，對應的觀察者查找有沒有對應的事件執(zhí)行，如果有，那么取出來執(zhí)行。

瀏覽器的事件來源于用戶的交互和一些網(wǎng)絡請求比如 ajax 等， Nodejs 中，事件來源于網(wǎng)絡請求 http ，文件 I/O 等，這些事件都有對應的觀察者，我這里枚舉出一些重要的觀察者。

• 文件 I/O 操作 —— I/O 觀察者;
• 網(wǎng)絡 I/O 操作 —— 網(wǎng)絡 I/O 觀察者;
• process.nextTick —— idle 觀察者
• setImmediate —— check 觀察者
• setTimeout/setInterval —— 延時器觀察者
• ...

在 Nodejs 中，對應觀察者接收對應類型的事件，事件循環(huán)過程中，會向這些觀察者詢問有沒有該執(zhí)行的任務，如果有，那么觀察者會取出任務，交給事件循環(huán)去執(zhí)行。

請求對象與線程池

從 JavaScript 調(diào)用到計算機系統(tǒng)執(zhí)行完 I/O 回調(diào)，請求對象充當著很重要的作用，我們還是以一次異步 I/O 操作為例

請求對象： 比如之前調(diào)用 fs.readFile ，本質(zhì)上調(diào)用 libuv 上的方法創(chuàng)建一個請求對象。這個請求對象上保留著此次 I/O 請求的信息，包括此次 I/O 的主體和回調(diào)函數(shù)等。然后異步調(diào)用的第一階段就完成了，JavaScript 會繼續(xù)往下執(zhí)行執(zhí)行棧上的代碼邏輯，當前的 I/O 操作將以請求對象的形式放入到線程池中，等待執(zhí)行。達到了異步 I/O 的目的。

線程池： Nodejs 的線程池在 Windows 下有內(nèi)核( IOCP )提供，在 Unix 系統(tǒng)中由 libuv 自行實現(xiàn)， 線程池用來執(zhí)行部分的 I/O (系統(tǒng)文件的操作)，線程池大小默認為 4 ，多個文件系統(tǒng)操作的請求可能阻塞到一個線程中。那么線程池里面的 I/O 操作是怎么執(zhí)行的呢?上一步說到，一次異步 I/O 會把請求對象放在線程池中，首先會判斷當前線程池是否有可用的線程，如果線程可用，那么會執(zhí)行請求對象的 I/O 操作，并把執(zhí)行后的結果返回給請求對象。在事件循環(huán)中的 I/O 處理階段，I/O 觀察者會獲取到已經(jīng)完成的 I/O 對象，然后取出回調(diào)函數(shù)和結果調(diào)用執(zhí)行。I/O 回調(diào)函數(shù)就這樣執(zhí)行，而且在回調(diào)函數(shù)的參數(shù)重獲取到結果。

異步 I/O 操作機制

上述講了整個異步 I/O 的執(zhí)行流程，從一個異步 I/O 的觸發(fā)，到 I/O 回調(diào)到執(zhí)行。事件循環(huán) ，觀察者 ，請求對象 ，線程池 構成了整個異步 I/O 執(zhí)行模型。

用一幅圖表示四者的關系：

總結上述過程：

• 第一階段：每一次異步 I/O 的調(diào)用，首先在 nodejs 底層設置請求參數(shù)和回調(diào)函 callback，形成請求對象。
• 第二階段：形成的請求對象，會被放入線程池，如果線程池有空閑的 I/O 線程，會執(zhí)行此次 I/O 任務，得到結果。
• 第三階段：事件循環(huán)中 I/O 觀察者，會從請求對象中找到已經(jīng)得到結果的 I/O 請求對象，取出結果和回調(diào)函數(shù)，將回調(diào)函數(shù)放入事件循環(huán)中，執(zhí)行回調(diào)，完成整個異步 I/O 任務。

對于如何感知異步 I/O 任務執(zhí)行完畢的?以及如何獲取完成的任務的呢?libuv 作為中間層， 在不同平臺上，采用手段不同，在 unix 下通過 epoll 輪詢，在 Windows 下通過內(nèi)核( IOCP )來實現(xiàn) ，F(xiàn)reeBSD 下通過 kqueue 實現(xiàn)。

三 事件循環(huán)

事件循環(huán)機制由宿主環(huán)境實現(xiàn)

上述中已經(jīng)提及了事件循環(huán)不是 JavaScript 引擎的一部分 ，事件循環(huán)機制由宿主環(huán)境實現(xiàn)，所以不同宿主環(huán)境下事件循環(huán)不同 ，不同宿主環(huán)境指的是瀏覽器環(huán)境還是 nodejs 環(huán)境 ，但在不同操作系統(tǒng)中，nodejs 的宿主環(huán)境也是不同的，接下來用一幅圖描述一下 Nodejs 中的事件循環(huán)和 javascript 引擎之間的關系。

以 libuv 下 nodejs 的事件循環(huán)為參考，關系如下：

以瀏覽器下 javaScript 的事件循環(huán)為參考，關系如下：

事件循環(huán)本質(zhì)上就像一個 while 循環(huán)，如下所示，我來用一段代碼模擬事件循環(huán)的執(zhí)行流程。

const queue = [ ... ]   // queue 里面放著待處理事件 
while(true){ 
    //開始循環(huán) 
    //執(zhí)行 queue 中的任務 
    //.... 
 
    if(queue.length ===0){ 
       return // 退出進程 
    } 
} 

• Nodejs 啟動后，就像創(chuàng)建一個 while 循環(huán)一樣，queue 里面放著待處理的事件，每一次循環(huán)過程中，如果還有事件，那么取出事件，執(zhí)行事件，如果存在事件關聯(lián)的回調(diào)函數(shù)，那么執(zhí)行回調(diào)函數(shù)，然后開始下一次循環(huán)。
• 如果循環(huán)體中沒有事件，那么將退出進程。

我總結了流程圖如下所示：

那么如何事件循環(huán)是如何處理這些任務的呢?我們列出 Nodejs 中一些常用的事件任務：

• setTimeout 或 setInterval 延時器計時器。
• 異步 I/O 任務：文件任務 ，網(wǎng)絡請求等。
• setImmediate 任務。
• process.nextTick 任務。
• Promise 微任務。

接下來會一一講到 ，這些任務的原理以及 nodejs 是如何處理這些任務的。

1 事件循環(huán)階段

對于不同的事件任務，會在不同的事件循環(huán)階段執(zhí)行。根據(jù) nodejs 官方文檔，在通常情況下，nodejs 中的事件循環(huán)根據(jù)不同的操作系統(tǒng)可能存在特殊的階段，但總體是可以分為以下 6 個階段 (代碼塊的六個階段) ：

/* 
   ┌───────────────────────────┐ 
┌─>│           timers          │     -> 定時器，延時器的執(zhí)行     
│  └─────────────┬─────────────┘ 
│  ┌─────────────┴─────────────┐ 
│  │     pending callbacks     │     -> i/o 
│  └─────────────┬─────────────┘ 
│  ┌─────────────┴─────────────┐ 
│  │       idle, prepare       │ 
│  └─────────────┬─────────────┘      ┌───────────────┐ 
│  ┌─────────────┴─────────────┐      │   incoming:   │ 
│  │           poll            │<─────┤  connections, │ 
│  └─────────────┬─────────────┘      │   data, etc.  │ 
│  ┌─────────────┴─────────────┐      └───────────────┘ 
│  │           check           │ 
│  └─────────────┬─────────────┘ 
│  ┌─────────────┴─────────────┐ 
└──┤      close callbacks      │ 
   └───────────────────────────┘ 
*/ 

• 第一階段：timer ，timer 階段主要做的事是，執(zhí)行 setTimeout 或 setInterval 注冊的回調(diào)函數(shù)。
• 第二階段：pending callback ，大部分 I/O 回調(diào)任務都是在 poll 階段執(zhí)行的，但是也會存在一些上一次事件循環(huán)遺留的被延時的 I/O 回調(diào)函數(shù)，那么此階段就是為了調(diào)用之前事件循環(huán)延遲執(zhí)行的 I/O 回調(diào)函數(shù)。
• 第三階段：idle prepare 階段，僅用于 nodejs 內(nèi)部模塊的使用。
• 第四階段：poll 輪詢階段，這個階段主要做兩件事，一這個階段會執(zhí)行異步 I/O 的回調(diào)函數(shù);二 計算當前輪詢階段阻塞后續(xù)階段的時間。
• 第五階段：check階段，當 poll 階段回調(diào)函數(shù)隊列為空的時候，開始進入 check 階段，主要執(zhí)行 setImmediate 回調(diào)函數(shù)。
• 第六階段：close階段，執(zhí)行注冊 close 事件的回調(diào)函數(shù)。

對于每一個階段的執(zhí)行特點和對應的事件任務，我接下來會詳細剖析。我們看一下六個階段在底層源碼中是怎么樣體現(xiàn)的。

我們看一下 libuv 下 nodejs 的事件循環(huán)的源代碼(在 unix 和 win 有點差別，不過不影響流程，這里以 unix 為例子。)：

libuv/src/unix/core.c

int uv_run(uv_loop_t* loop, uv_run_mode mode) { 
  // 省去之前的流程。 
  while (r != 0 && loop->stop_flag == 0) { 
 
    /* 更新事件循環(huán)的時間 */  
    uv__update_time(loop); 
 
    /*第一階段：timer 階段執(zhí)行  */ 
    uv__run_timers(loop); 
 
    /*第二階段：pending 階段 */ 
    ran_pending = uv__run_pending(loop); 
 
    /*第三階段：idle prepare 階段 */ 
    uv__run_idle(loop); 
    uv__run_prepare(loop); 
 
    timeout = 0; 
    if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT) 
     /* 計算 timeout 時間  */ 
      timeout = uv_backend_timeout(loop); 
     
    /* 第四階段：poll 階段 */ 
    uv__io_poll(loop, timeout); 
 
    /* 第五階段：check 階段 */ 
    uv__run_check(loop); 
    /* 第六階段：close 階段  */ 
    uv__run_closing_handles(loop); 
    /* 判斷當前線程還有任務 */  
     r = uv__loop_alive(loop); 
 
    /* 省去之后的流程 */ 
  } 
  return r; 
} 

我們看到六個階段是按序執(zhí)行的，只有完成上一階段的任務，才能進行下一階段

當 uv__loop_alive 判斷當前事件循環(huán)沒有任務，那么退出線程。

2 任務隊列

在整個事件循環(huán)過程中，有四個隊列(實際的數(shù)據(jù)結構不是隊列)是在 libuv 的事件循環(huán)中進行的，還有兩個隊列是在 nodejs 中執(zhí)行的分別是 promise 隊列 和 nextTick 隊列。

在 NodeJS 中不止一個隊列，不同類型的事件在它們自己的隊列中入隊。在處理完一個階段后，移向下一個階段之前，事件循環(huán)將會處理兩個中間隊列，直到兩個中間隊列為空。

libuv 處理任務隊列

事件循環(huán)的每一個階段，都會執(zhí)行對應任務隊列里面的內(nèi)容。

• timer 隊列( PriorityQueue )：本質(zhì)上的數(shù)據(jù)結構是二叉最小堆，二叉最小堆的根節(jié)點獲取最近的時間線上的 timer 對應的回調(diào)函數(shù)。
• I/O 事件隊列：存放 I/O 任務。
• Immediate 隊列( ImmediateList )：多個 Immediate ，node 層用鏈表數(shù)據(jù)結構儲存。
• 關閉回調(diào)事件隊列：放置待 close 的回調(diào)函數(shù)。

非 libuv 中間隊列

• nextTick 隊列 ：存放 nextTick 的回調(diào)函數(shù)。這個是在 nodejs 中特有的。
• Microtasks 微隊列 Promise ：存放 promise 的回調(diào)函數(shù)。

中間隊列的執(zhí)行特點：

• 首先要明白兩個中間隊列并非在 libuv 中被執(zhí)行，它們都是在 nodejs 層執(zhí)行的，在 libuv 層處理每一個階段的任務之后，會和 node 層進行通訊，那么會優(yōu)先處理兩個隊列中的任務。
• nextTick 任務的優(yōu)先級要大于 Microtasks 任務中的 Promise 回調(diào)。也就是說 node 會首先清空 nextTick 中的任務，然后才是 Promise 中的任務。為了驗證這個結論，例舉一個打印結果的題目如下：

/* TODO: 打印順序  */ 
setTimeout(()=>{ 
    console.log('setTimeout 執(zhí)行') 
},0) 
 
const p = new Promise((resolve)=>{ 
     console.log('Promise執(zhí)行') 
     resolve() 
}) 
p.then(()=>{ 
    console.log('Promise 回調(diào)執(zhí)行') 
}) 
 
process.nextTick(()=>{ 
    console.log('nextTick 執(zhí)行') 
}) 
console.log('代碼執(zhí)行完畢') 

如上代碼塊中的 nodejs 中的執(zhí)行順序是什么?

效果：

打印結果：Promise執(zhí)行 -> 代碼執(zhí)行完畢 -> nextTick 執(zhí)行 -> Promise 回調(diào)執(zhí)行 -> setTimeout 執(zhí)行

解釋：很好理解為什么這么打印，在主代碼事件循環(huán)中，Promise執(zhí)行 和 代碼執(zhí)行完畢 最先被打印，nextTick 被放入 nextTick 隊列中，Promise 回調(diào)放入 Microtasks 隊列中，setTimeout 被放入 timer 堆中。接下來主循環(huán)完成，開始清空兩個隊列中的內(nèi)容，首先清空 nextTick 隊列，nextTick 執(zhí)行 被打印，接下來清空 Microtasks 隊列，Promise 回調(diào)執(zhí)行 被打印，最后再判斷事件循環(huán) loop 中還有 timer 任務，那么開啟新的事件循環(huán) ，首先執(zhí)行，timer 任務，setTimeout 執(zhí)行被打印。整個流程完畢。

• 無論是 nextTick 的任務，還是 promise 中的任務， 兩個任務中的代碼會阻塞事件循環(huán)的有序進行，導致 I/O 餓死的情況發(fā)生，所以需要謹慎處理兩個任務中的邏輯。比如如下：

/* TODO: 阻塞 I/O 情況 */ 
process.nextTick(()=>{ 
    const now = +new Date() 
    /* 阻塞代碼三秒鐘 */ 
    while( +new Date() < now + 3000 ){} 
}) 
 
fs.readFile('./file.js',()=>{ 
    console.log('I/O: file ') 
}) 
 
setTimeout(() => { 
    console.log('setTimeout: ') 
}, 0); 

效果：

三秒鐘， 事件循環(huán)中的 timer 任務和 I/O 任務，才被有序執(zhí)行。也就是說 nextTick 中的代碼，阻塞了事件循環(huán)的有序進行。

3 事件循環(huán)流程圖

接下來用流程圖，表示事件循環(huán)的六大階段的執(zhí)行順序，以及兩個優(yōu)先隊列的執(zhí)行邏輯。

4 timer 階段 -> 計時器 timer / 延時器 interval

延時器計時器觀察者(Expired timers and intervals)：延時器計時器觀察者用來檢查通過 setTimeout 或 setInterval創(chuàng)建的異步任務，內(nèi)部原理和異步 I/O 相似，不過定期器/延時器內(nèi)部實現(xiàn)沒有用線程池。通過setTimeout 或 setInterval定時器對象會被插入到延時器計時器觀察者內(nèi)部的二叉最小堆中，每次事件循環(huán)過程中，會從二叉最小堆頂部取出計時器對象，判斷 timer/interval 是否過期，如果有，然后調(diào)用它，出隊。再檢查當前隊列的第一個，直到?jīng)]有過期的，移到下一個階段。

libuv 層如何處理 timer

首先一起看一下 libuv 層是如何處理的 timer

libuv/src/timer.c

void uv__run_timers(uv_loop_t* loop) { 
  struct heap_node* heap_node; 
  uv_timer_t* handle; 
 
  for (;;) { 
    /* 找到 loop 中 timer_heap 中的根節(jié)點 （ 值最小 ） */   
    heap_node = heap_min((struct heap*) &loop->timer_heap); 
    /*  */ 
    if (heap_node == NULL) 
      break; 
 
    handle = container_of(heap_node, uv_timer_t, heap_node); 
    if (handle->timeout > loop->time) 
      /*  執(zhí)行時間大于事件循環(huán)事件，那么不需要在此次 loop 中執(zhí)行  */ 
      break; 
 
    uv_timer_stop(handle); 
    uv_timer_again(handle); 
    handle->timer_cb(handle); 
  } 
} 

• 如上 handle timeout 可以理解成過期時間，也就是計時器回到函數(shù)的執(zhí)行時間。
• 當 timeout 大于當前事件循環(huán)的開始時間時，即表示還沒有到執(zhí)行時機，回調(diào)函數(shù)還不應該被執(zhí)行。那么根據(jù)二叉最小堆的性質(zhì)，父節(jié)點始終比子節(jié)點小，那么根節(jié)點的時間節(jié)點都不滿足執(zhí)行時機的話，其他的 timer 也不滿足執(zhí)行時間。此時，退出 timer 階段的回調(diào)函數(shù)執(zhí)行，直接進入事件循環(huán)下一階段。
• 當過期時間小于當前事件循環(huán) tick 的開始時間時，表示至少存在一個過期的計時器，那么循環(huán)迭代計時器最小堆的根節(jié)點，并調(diào)用該計時器所對應的回調(diào)函數(shù)。每次循環(huán)迭代時都會更新最小堆的根節(jié)點為最近時間節(jié)點的計時器。

如上是 timer 階段在 libuv 中執(zhí)行特點。接下里分析一下 node 中是如何處理定時器延時器的。

node 層如何處理 timer

在 Nodejs 中 setTimeout 和 setInterval 是 nodejs 自己實現(xiàn)的，來一起看一下實現(xiàn)細節(jié)：

node/lib/timers.js

function setTimeout(callback，after){ 
    //... 
    /* 判斷參數(shù)邏輯 */ 
    //.. 
    /* 創(chuàng)建一個 timer 觀察者 */ 
    const timeout = new Timeout(callback, after, args, false, true); 
    /* 將 timer 觀察者插入到 timer 堆中  */ 
    insert(timeout, timeout._idleTimeout); 
 
    return timeout; 
} 

setTimeout：邏輯很簡單，就是創(chuàng)建一個 timer 時間觀察者，然后放入計時器堆中。

那么 Timeout 做了些什么呢?

node/lib/internal/timers.js

function Timeout(callback, after, args, isRepeat, isRefed) { 
  after *= 1  
  if (!(after >= 1 && after <= 2 ** 31 - 1)) { 
    after = 1 // 如果延時器 timeout 為 0 ，或者是大于 2 ** 31 - 1 ，那么設置成 1  
  } 
  this._idleTimeout = after; // 延時時間  
  this._idlePrev = this; 
  this._idleNext = this; 
  this._idleStart = null; 
  this._onTimeout = null; 
  this._onTimeout = callback; // 回調(diào)函數(shù) 
  this._timerArgs = args; 
  this._repeat = isRepeat ? after : null; 
  this._destroyed = false;   
 
  initAsyncResource(this, 'Timeout'); 
} 

在 nodejs 中無論 setTimeout 還是 setInterval 本質(zhì)上都是 Timeout 類。超出最大時間閥 2 ** 31 - 1 或者 setTimeout(callback, 0) ，_idleTimeout 會被設置成 1 ，轉(zhuǎn)換為 setTimeout(callback, 1) 來執(zhí)行。

timer 處理流程圖

用一副流程圖描述一下，我們創(chuàng)建一個 timer ，再到 timer 在事件循環(huán)里面執(zhí)行的流程。

timer 特性

這里有兩點需要注意：

• 執(zhí)行機制 ：延時器計時器觀察者，每一次都會執(zhí)行一個，執(zhí)行一個之后會清空 nextTick 和 Promise， 過期時間是決定兩者是否執(zhí)行的重要因素，還有一點 poll 會計算阻塞 timer 執(zhí)行的時間，對 timer 階段任務的執(zhí)行也有很重要的影響。

驗證結論一次執(zhí)行一個 timer 任務 ，先來看一段代碼片段：

setTimeout(()=>{ 
    console.log('setTimeout1:') 
    process.nextTick(()=>{ 
        console.log('nextTick') 
    }) 
},0) 
setTimeout(()=>{ 
    console.log('setTimeout2:') 
},0) 

打印結果：

nextTick 隊列是在事件循環(huán)的每一階段結束執(zhí)行的，兩個延時器的閥值都是 0 ，如果在 timer 階段一次性執(zhí)行完，過期任務的話，那么打印 setTimeout1 -> setTimeout2 -> nextTick ，實際上先執(zhí)行一個 timer 任務，然后執(zhí)行 nextTick 任務，最后再執(zhí)行下一個 timer 任務。

• 精度問題 ：關于 setTimeout 的計數(shù)器問題，計時器并非精確的，盡管在 nodejs 的事件循環(huán)非常的快，但是從延時器 timeout 類的創(chuàng)建，會占用一些事件，再到上下文執(zhí)行， I/O 的執(zhí)行，nextTick 隊列執(zhí)行，Microtasks 執(zhí)行，都會阻塞延時器的執(zhí)行。甚至在檢查 timer 過期的時候，也會消耗一些 cpu 時間。
• 性能問題 ：如果想用 setTimeout(fn,0) 來執(zhí)行一些非立即調(diào)用的任務，那么性能上不如 process.nextTick 實在，首先 setTimeout 精度不夠，還有一點就是里面有定時器對象，并需要在 libuv 底層執(zhí)行，占用一定性能，所以可以用 process.nextTick 解決這種場景。

5 pending 階段

pending 階段用來處理此次事件循環(huán)之前延時的 I/O 回調(diào)函數(shù)。首先看一下在 libuv 中執(zhí)行時機。

libuv/src/unix/core.c

static int uv__run_pending(uv_loop_t* loop) { 
  QUEUE* q; 
  QUEUE pq; 
  uv__io_t* w 
  /* pending_queue 為空，清空隊列 ，返回 0  */ 
  if (QUEUE_EMPTY(&loop->pending_queue)) 
    return 0; 
   
  QUEUE_MOVE(&loop->pending_queue, &pq); 
  while (!QUEUE_EMPTY(&pq)) { /* pending_queue 不為空的情況，清空 I/O 回調(diào)。返回 1  */ 
    q = QUEUE_HEAD(&pq); 
    QUEUE_REMOVE(q); 
    QUEUE_INIT(q); 
    w = QUEUE_DATA(q, uv__io_t, pending_queue); 
    w->cb(loop, w, POLLOUT); 
  } 
  return 1; 
} 

• 如果存放 I/O 回調(diào)的任務的 pending_queue 是空的，那么直接返回 0。
• 如果 pending_queue 有 I/O 回調(diào)任務，那么執(zhí)行回調(diào)任務。

6 idle, prepare 階段

idle 做一些 libuv 一些內(nèi)部操作， prepare 為接下來的 I/O 輪詢做一些準備工作。接下來一起解析一下比較重要 poll 階段。

7 poll I / O 輪詢階段

在正式講解 poll 階段做哪些事情之前，首先看一下，在 libuv 中，輪詢階段的執(zhí)行邏輯：

timeout = 0; 
  if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT) 
    /* 計算 timeout   */ 
    timeout = uv_backend_timeout(loop); 
    /* 進入 I/O 輪詢 */ 
    uv__io_poll(loop, timeout); 

初始化超時時間 timeout = 0 ，通過 uv_backend_timeout 計算本次 poll 階段的超時時間。超時時間會影響到異步 I/O 和后續(xù)事件循環(huán)的執(zhí)行。

timeout代表什么

首先要明白不同 timeout ，在 I/O 輪詢中代表什么意思。

• 當 timeout = 0 的時候，說明 poll 階段不會阻塞事件循環(huán)的進行，那么說明有更迫切執(zhí)行的任務。那么當前的 poll 階段不會發(fā)生阻塞，會盡快進入下一階段，盡快結束當前 tick，進入下一次事件循環(huán)，那么這些緊急任務將被執(zhí)行。
• 當 timeout = -1時，說明會一直阻塞事件循環(huán)，那么此時就可以停留在異步 I/O 的 poll 階段，等待新的 I/O 任務完成。
• 當 timeout等于常數(shù)的情況，說明此時 io poll 循環(huán)階段能夠停留的時間，那么什么時候會存在 timeout 為常數(shù)呢，將馬上揭曉。

獲取timeout

timeout 的獲取是通過 uv_backend_timeout 那么如何獲得的呢?

int uv_backend_timeout(const uv_loop_t* loop) { 
    /* 當前事件循環(huán)任務停止 ，不阻塞 */ 
  if (loop->stop_flag != 0) 
    return 0; 
   /* 當前事件循環(huán) loop 不活躍的時候 ，不阻塞 */ 
  if (!uv__has_active_handles(loop) && !uv__has_active_reqs(loop)) 
    return 0; 
  /* 當 idle 句柄隊列不為空時，返回 0，即不阻塞。 */ 
  if (!QUEUE_EMPTY(&loop->idle_handles)) 
    return 0; 
   /* i/o pending 隊列不為空的時候。 */   
  if (!QUEUE_EMPTY(&loop->pending_queue)) 
    return 0; 
   /* 有關閉回調(diào) */ 
  if (loop->closing_handles) 
    return 0; 
  /* 計算有沒有延時最小的延時器 ｜ 定時器 */ 
  return uv__next_timeout(loop); 
} 

uv_backend_timeout 主要做的事情是：

• 當前事件循環(huán)停止時，不阻塞。
• 當前事件循環(huán) loop 不活躍的時候 ，不阻塞。
• 當 idle 隊列 ( setImmediate ) 不為空時，返回 0，不阻塞。
• i/o pending 隊列不為空的時候，不阻塞。
• 有關閉回調(diào)函數(shù)的時候，不阻塞。
• 如果上述均不滿足，那么通過 uv__next_timeout 計算有沒有延時閥值最小的定時器 | 延時器( 最急迫執(zhí)行 )，返回延時時間。

接下來看一下 uv__next_timeout 邏輯。

int uv__next_timeout(const uv_loop_t* loop) { 
  const struct heap_node* heap_node; 
  const uv_timer_t* handle; 
  uint64_t diff; 
  /* 找到延時時間最小的 timer  */ 
  heap_node = heap_min((const struct heap*) &loop->timer_heap); 
  if (heap_node == NULL) /* 如何沒有 timer，那么返回 -1 ，一直進入 poll 狀態(tài)  */ 
    return -1;  
 
  handle = container_of(heap_node, uv_timer_t, heap_node); 
   /* 有過期的 timer 任務，那么返回 0，poll 階段不阻塞 */ 
  if (handle->timeout <= loop->time) 
    return 0; 
  /* 返回當前最小閥值的 timer 與 當前事件循環(huán)的事件相減，得出來的時間，可以證明 poll 可以停留多長時間 */  
  diff = handle->timeout - loop->time; 
  return (int) diff; 
} 

uv__next_timeout 做的事情如下：

• 找到時間閥值最小的 timer (最優(yōu)先執(zhí)行的)，如何沒有 timer，那么返回 -1 。poll 階段將無限制阻塞。這樣的好處是一旦有 I/O 執(zhí)行完畢 ，I/O 回調(diào)函數(shù)會直接加入到 poll ，接下來就會執(zhí)行對應的回調(diào)函數(shù)。
• 如果有 timer ，但是 timeout <= loop.time 證明已經(jīng)過期了，那么返回 0，poll 階段不阻塞，優(yōu)先執(zhí)行過期任務。
• 如果沒有過期，返回當前最小閥值的 timer 與 當前事件循環(huán)的事件相減得值，即是可以證明 poll 可以停留多長時間。當停留完畢，證明有過期 timer ，那么進入到下一個 tick。

執(zhí)行io_poll

接下來就是 uv__io_poll 真正的執(zhí)行，里面有一個 epoll_wait 方法，根據(jù) timeout ，來輪詢有沒有 I/O 完成，有得話那么執(zhí)行 I/O 回調(diào)。這也是 unix 下異步I/O 實現(xiàn)的重要環(huán)節(jié)。

poll階段本質(zhì)

接下來總結一下 poll 階段的本質(zhì)：

• poll 階段就是通過 timeout 來判斷，是否阻塞事件循環(huán)。poll 也是一種輪詢，輪詢的是 i/o 任務，事件循環(huán)傾向于 poll 階段的持續(xù)進行，其目的就是更快的執(zhí)行 I/O 任務。如果沒有其他任務，那么將一直處于 poll 階段。
• 如果有其他階段更緊急待執(zhí)行的任務，比如 timer ，close ，那么 poll 階段將不阻塞，會進行下一個 tick 階段。

poll 階段流程圖

我把整個 poll 階段做的事用流程圖表示，省去了一些細枝末節(jié)。

8 check 階段

如果 poll 階段進入 idle 狀態(tài)并且 setImmediate 函數(shù)存在回調(diào)函數(shù)時，那么 poll 階段將打破無限制的等待狀態(tài)，并進入 check 階段執(zhí)行 check 階段的回調(diào)函數(shù)。

check 做的事就是處理 setImmediate 回調(diào)。，先來看一下 Nodejs 中是怎么定義的 setImmediate。

Nodejs 底層中的 setImmediate

setImmediate定義

node/lib/timer.js

function setImmediate(callback, arg1, arg2, arg3) { 
  validateCallback(callback); /* 校驗一下回調(diào)函數(shù) */ 
   /* 創(chuàng)建一個 Immediate 類   */ 
   return new Immediate(callback, args); 
} 

• 當調(diào)用 setImmediate 本質(zhì)上調(diào)用 nodejs 中的 setImmediate 方法，首先校驗回調(diào)函數(shù)，然后創(chuàng)建一個 Immediate 類。接下來看一下 Immediate 類。
• node/lib/internal/timers.js

class Immediate{ 
   constructor(callback, args) { 
    this._idleNext = null; 
    this._idlePrev = null; /* 初始化參數(shù) */ 
    this._onImmediate = callback; 
    this._argv = args; 
    this._destroyed = false; 
    this[kRefed] = false; 
 
    initAsyncResource(this, 'Immediate'); 
    this.ref(); 
    immediateInfo[kCount]++; 
     
    immediateQueue.append(this); /* 添加 */ 
  } 
} 

• Immediate 類會初始化一些參數(shù)，然后將當前 Immediate 類，插入到 immediateQueue 鏈表中。
• immediateQueue 本質(zhì)上是一個鏈表，存放每一個 Immediate。

setImmediate執(zhí)行

poll 階段之后，會馬上到 check 階段，執(zhí)行 immediateQueue 里面的 Immediate。在每一次事件循環(huán)中，會先執(zhí)行一個setImmediate 回調(diào)，然后清空 nextTick 和 Promise 隊列的內(nèi)容。為了驗證這個結論，同樣和 setTimeout 一樣，看一下如下代碼塊：

setImmediate(()=>{ 
    console.log('setImmediate1') 
    process.nextTick(()=>{ 
        console.log('nextTick') 
    }) 
}) 
 
setImmediate(()=>{ 
    console.log('setImmediate2') 
}) 

打印 setImmediate1 -> nextTick -> setImmediate2 ，在每一次事件循環(huán)中，執(zhí)行一個 setImmediate ，然后執(zhí)行清空 nextTick 隊列，在下一次事件循環(huán)中，執(zhí)行另外一個 setImmediate2 。

setImmediate執(zhí)行流程圖

setTimeout & setImmediate

接下來對比一下 setTimeout 和 setImmediate，如果開發(fā)者期望延時執(zhí)行的異步任務，那么接下來對比一下 setTimeout(fn,0) 和 setImmediate(fn) 區(qū)別。

• setTimeout 是 用于在設定閥值的最小誤差內(nèi)，執(zhí)行回調(diào)函數(shù)，setTimeout 存在精度問題，創(chuàng)建 setTimeout 和 poll 階段都可能影響到 setTimeout 回調(diào)函數(shù)的執(zhí)行。
• setImmediate 在 poll 階段之后，會馬上進入 check 階段，會執(zhí)行 setImmediate回調(diào)。

如果 setTimeout 和 setImmediate 在一起，那么誰先執(zhí)行呢?

首先寫一個 demo：

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

猜測

先猜測一下，setTimeout 發(fā)生 timer 階段，setImmediate 發(fā)生在 check 階段，timer 階段早于 check 階段，那么 setTimeout 優(yōu)先于 setImmediate 打印。但事實是這樣嗎?

實際打印結果

從以上打印結果上看， setTimeout 和 setImmediate 執(zhí)行時機是不確定的，為什么會造成這種情況，上文中講到即使 setTimeout 第二個參數(shù)為 0，在 nodejs 中也會被處理 setTimeout(fn,1)。當主進程的同步代碼執(zhí)行之后，會進入到事件循環(huán)階段，第一次進入 timer 中，此時 settimeout 對應的 timer 的時間閥值為 1，若在前文 uv__run_timer(loop) 中，系統(tǒng)時間調(diào)用和時間比較的過程總耗時沒有超過 1ms 的話，在 timer 階段會發(fā)現(xiàn)沒有過期的計時器，那么當前 timer 就不會執(zhí)行，接下來到 check 階段，就會執(zhí)行 setImmediate 回調(diào)，此時的執(zhí)行順序是：setImmediate -> setTimeout。

但是如果總耗時超過一毫秒的話，執(zhí)行順序就會發(fā)生變化，在 timer 階段，取出過期的 setTimeout 任務執(zhí)行，然后到 check 階段，再執(zhí)行 setImmediate ，此時 setTimeout -> setImmediate。

造成這種情況發(fā)生的原因是：timer 的時間檢查距當前事件循環(huán) tick 的間隔可能小于 1ms 也可能大于 1ms 的閾值，所以決定了 setTimeout 在第一次事件循環(huán)執(zhí)行與否。

接下來我用代碼阻塞的情況，會大概率造成 setTimeout 一直優(yōu)先于 setImmediate 執(zhí)行。

/* TODO:  setTimeout & setImmediate */ 
setImmediate(()=>{ 
    console.log( 'setImmediate' ) 
}) 
 
setTimeout(()=>{ 
    console.log('setTimeout') 
},0) 
/* 用 100000 循環(huán)阻塞代碼，促使 setTimeout 過期 */ 
for(let i=0;i<100000;i++){ 
} 

效果：

100000 循環(huán)阻塞代碼，這樣會讓 setTimeout 超過時間閥值執(zhí)行，這樣就保證了每次先執(zhí)行 setTimeout -> setImmediate 。

特殊情況：確定順序一致性。我們看一下特殊的情況。

const fs = require('fs') 
fs.readFile('./file.js',()=>{ 
    setImmediate(()=>{ 
        console.log( 'setImmediate' ) 
    }) 
    setTimeout(()=>{ 
        console.log('setTimeout') 
    },0) 
}) 

如上情況就會造成，setImmediate 一直優(yōu)先于 setTimeout 執(zhí)行，至于為什么，來一起分析一下原因。

• 首先分析一下異步任務——主進程中有一個異步 I/O 任務，I/O 回調(diào)中有一個 setImmediate 和 一個 setTimeout 。
• 在 poll 階段會執(zhí)行 I/O 回調(diào)。然后處理一個 setImmediate

萬變不離其宗，只要掌握了如上各個階段的特性，那么對于不同情況的執(zhí)行情況，就可以清晰的分辨出來。

9 close 階段

close 階段用于執(zhí)行一些關閉的回調(diào)函數(shù)。執(zhí)行所有的 close 事件。接下來看一下 close 事件 libuv 的實現(xiàn)。

libuv/src/unix/core.c

static void uv__run_closing_handles(uv_loop_t* loop) { 
  uv_handle_t* p; 
  uv_handle_t* q; 
 
  p = loop->closing_handles; 
  loop->closing_handles = NULL; 
 
  while (p) { 
    q = p->next_closing; 
    uv__finish_close(p); 
    p = q; 
  } 
} 

• uv__run_closing_handles 這個方法循環(huán)執(zhí)行 close 隊列里面的回調(diào)函數(shù)。

10 Nodejs 事件循環(huán)總結

接下來總結一下 Nodejs 事件循環(huán)。

• Nodejs 的事件循環(huán)分為 6 大階段。分別為 timer 階段，pending 階段，prepare 階段，poll 階段， check 階段，close 階段。
• nextTick 隊列和 Microtasks 隊列執(zhí)行特點，在每一階段完成后執(zhí)行， nextTick 優(yōu)先級大于 Microtasks ( Promise )。
• poll 階段主要處理 I/O，如果沒有其他任務，會處于輪詢阻塞階段。
• timer 階段主要處理定時器/延時器，它們并非準確的，而且創(chuàng)建需要額外的性能浪費，它們的執(zhí)行還收到 poll 階段的影響。
• pending 階段處理 I/O 過期的回調(diào)任務。
• check 階段處理 setImmediate。setImmediate 和 setTimeout 執(zhí)行時機和區(qū)別。

四 Nodejs事件循環(huán)習題演練

接下來為了更清楚事件循環(huán)流程，這里出兩道事件循環(huán)的問題。作為實踐：

習題一

process.nextTick(function(){ 
    console.log('1'); 
}); 
process.nextTick(function(){ 
    console.log('2'); 
     setImmediate(function(){ 
        console.log('3'); 
    }); 
    process.nextTick(function(){ 
        console.log('4'); 
    }); 
}); 
 
setImmediate(function(){ 
    console.log('5'); 
     process.nextTick(function(){ 
        console.log('6'); 
    }); 
    setImmediate(function(){ 
        console.log('7'); 
    }); 
}); 
 
setTimeout(e=>{ 
    console.log(8); 
    new Promise((resolve,reject)=>{ 
        console.log(8+'promise'); 
        resolve(); 
    }).then(e=>{ 
        console.log(8+'promise+then'); 
    }) 
},0) 
 
setTimeout(e=>{ console.log(9); },0) 
 
setImmediate(function(){ 
    console.log('10'); 
    process.nextTick(function(){ 
        console.log('11'); 
    }); 
    process.nextTick(function(){ 
        console.log('12'); 
    }); 
    setImmediate(function(){ 
        console.log('13'); 
    }); 
}); 
 
console.log('14'); 
 new Promise((resolve,reject)=>{ 
    console.log(15); 
    resolve(); 
}).then(e=>{ 
    console.log(16); 
}) 

如果剛看這個 demo 可以會發(fā)蒙，不過上述講到了整個事件循環(huán)，再來看這個問題就很輕松了，下面來分析一下整體流程：

• 第一階段：首先開始啟動 js 文件，那么進入第一次事件循環(huán)，那么先會執(zhí)行同步任務：

最先打印：

打印console.log('14');

打印console.log(15);

nextTick 隊列：

nextTick -> console.log(1) nextTick -> console.log(2) -> setImmediate(3) -> nextTick(4)

Promise隊列

Promise.then(16)

check隊列

setImmediate(5) -> nextTick(6) -> setImmediate(7) setImmediate(10) -> nextTick(11) -> nextTick(12) -> setImmediate(13)

timer隊列

setTimeout(8) -> promise(8+'promise') -> promise.then(8+'promise+then') setTimeout(9)

• 第二階段：在進入新的事件循環(huán)之前，清空 nextTick 隊列，和 promise 隊列，順序是 nextTick 隊列大于 Promise 隊列。

清空 nextTick ，打印：

console.log('1');

console.log('2'); 執(zhí)行第二個 nextTick 的時候，又有一個 nextTick ，所以會把這個 nextTick 也加入到隊列中。接下來馬上執(zhí)行。console.log('4')

接下來清空Microtasks

console.log(16);

此時的 check 隊列加入了新的 setImmediate。

check隊列setImmediate(5) -> nextTick(6) -> setImmediate(7) setImmediate(10) -> nextTick(11) -> nextTick(12) -> setImmediate(13) setImmediate(3)

• 然后進入新的事件循環(huán)，首先執(zhí)行 timer 里面的任務。執(zhí)行第一個 setTimeout。

執(zhí)行第一個 timer:

console.log(8); 此時發(fā)現(xiàn)一個 Promise 。在正常的執(zhí)行上下文中：console.log(8+'promise'); 然后將 Promise.then 加入到 nextTick 隊列中。接下里會馬上清空 nextTick 隊列。console.log(8+'promise+then');

執(zhí)行第二個 timer:

console.log(9)

接下來到了 check 階段，執(zhí)行 check 隊列里面的內(nèi)容：

執(zhí)行第一個 check:

console.log(5); 此時發(fā)現(xiàn)一個 nextTick ，然后還有一個 setImmediate 將 setImmediate 加入到 check 隊列中。然后執(zhí)行 nextTick 。console.log(6)

執(zhí)行第二個 check

console.log(10)

此時發(fā)現(xiàn)兩個 nextTick 和一個 setImmediate 。接下來清空 nextTick 隊列。將 setImmediate 添加到隊列中。

console.log(11)

console.log(12)

此時的 check 隊列是這樣的：

setImmediate(3) setImmediate(7) setImmediate(13)

接下來按順序清空 check 隊列。打印

console.log(3)

console.log(7)

console.log(13)

到此為止，執(zhí)行整個事件循環(huán)。那么整體打印內(nèi)容如下：

五 總結

本文主要講的內(nèi)容如下：

• 異步 I/O 介紹及其內(nèi)部原理。
• Nodejs 的事件循環(huán)，六大階段。
• Nodejs 中 setTimeout ，setImmediate ， 異步 i/o ，nextTick ，Promise 的原理及其區(qū)別。
• Nodejs 事件循環(huán)實踐。

參考資料

 

• 從 libuv 看 nodejs 事件循環(huán)
• 深入淺出Nodejs
• Node.js 事件循環(huán)的工作流程 & 生命周期