解析Node.js的事件循環機制

這篇文章帶給大家的內容是關於解析Node.js的事件循環機制，有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。

在瀏覽器篇已經對事件循環機制和一些相關的概念作了詳細介紹，但主要是針對瀏覽器端的研究，Node環境是否也一樣呢？先看一個demo：

setTimeout(()=>{
    console.log('timer1')
    Promise.resolve().then(function() {
        console.log('promise1')
    })}, 0)setTimeout(()=>{
    console.log('timer2')
    Promise.resolve().then(function() {
        console.log('promise2')
    })}, 0)

肉眼編譯運行一下，蒽，在瀏覽器的結果就是下面這個了，道理都懂，就不累述了。

timer1
promise1
timer2
promise2

那麼Node下執行看看，咦。 。 。奇怪，跟瀏覽器的運作結果不一樣~

timer1
timer2
promise1
promise2

範例說明，瀏覽器和Node.js 的事件循環機制是有差別的，一起來看個究竟吧~

Node.js的事件處理

Node.js採用V8作為js的解析引擎，而I/O處理方面使用了自己設計的libuv，libuv是基於事件驅動的跨平台抽象層，封裝了不同作業系統一些底層特性，對外提供統一的API，事件循環機制也是它裡面的實現，核心原始碼參考：

int uv_run(uv_loop_t* loop, uv_run_mode mode) {
  int timeout;
  int r;
  int ran_pending;
  r = uv__loop_alive(loop);
  if (!r)
    uv__update_time(loop);
  while (r != 0 && loop->stop_flag == 0) {
    uv__update_time(loop);
    // timers阶段
    uv__run_timers(loop);
    // I/O callbacks阶段
    ran_pending = uv__run_pending(loop);
    // idle阶段
    uv__run_idle(loop);
    // prepare阶段
    uv__run_prepare(loop);
    timeout = 0;
    if ((mode == UV_RUN_ONCE && !ran_pending) || mode == UV_RUN_DEFAULT)
      timeout = uv_backend_timeout(loop);
    // poll阶段
    uv__io_poll(loop, timeout);
    // check阶段
    uv__run_check(loop);
    // close callbacks阶段
    uv__run_closing_handles(loop);
    if (mode == UV_RUN_ONCE) {
      uv__update_time(loop);
      uv__run_timers(loop);
    }
    r = uv__loop_alive(loop);
    if (mode == UV_RUN_ONCE || mode == UV_RUN_NOWAIT)
      break;
  }
  if (loop->stop_flag != 0)
    loop->stop_flag = 0;
  return r;
}

根據Node.js官方介紹，每次事件循環都包含了6個階段，對應libuv 原始碼中的實現，如下圖所示

timers 階段：這個階段執行timer（setTimeout、setInterval）的回呼

#I/ O callbacks 階段：執行一些系統呼叫錯誤，例如網路通訊的錯誤回呼

idle, prepare 階段：僅node內部使用

poll 階段：取得新的I/O事件, 適當的條件下node將阻塞在這裡

check 階段：執行setImmediate() 的回呼

close callbacks 階段：執行socket 的close 事件回呼

我們重點看timers、poll 、check這3個階段就好，因為日常開發的絕大部分非同步任務都是在這3個階段處理的。

timers 階段

timers 是事件循環的第一個階段，Node 會去檢查有無已過期的timer，如果有則把它的回調壓入timer的任務隊列中等待執行，事實上，Node 並不能保證timer在預設時間到了就會立即執行，因為Node對timer的過期檢查不一定可靠，它會受機器上其它運行程序影響，或者那個時間點主線程不空閒。例如下面的程式碼，setTimeout() 和 setImmediate() 的執行順序是不確定的。

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

但把它們放到一個I/O回呼裡面，就一定是 setImmediate() 先執行，因為poll階段後面就是check階段。

poll 階段

poll 階段主要有2個功能：

#處理poll 佇列的事件

當有已逾時的timer，執行它的回調函數

even loop將同步執行poll佇列裡的回調，直到佇列為空或執行的回呼達到系統上限（上限具體多少未詳），接下來even loop會去檢查有無預設的setImmediate( )，分兩種情況：

若有預設的setImmediate(), event loop將結束poll階段進入check階段，並執行check階段的任務隊列

若沒有預設的setImmediate()，event loop將阻塞在該階段等待

注意一個細節，沒有setImmediate()會導致event loop阻塞在poll階段，這樣之前設定的timer豈不是執行不了了？所以咧，在poll階段event loop會有檢查機制，檢查timer隊列是否為空，如果timer隊列非空，event loop就開始下一輪事件循環，也就是重新進入timer階段。

check 階段

setImmediate()的回呼會被加入check佇列中， 從event loop的階段圖可以知道，check階段的執行順序在poll階段之後。

小結

event loop 的每個階段都有一個任務隊列

當event loop 到達某個階段時，將執行該階段的任務隊列，直到隊列清空或執行的回呼達到系統上限後，才會轉入下一個階段

當所有階段被順序執行一次後，稱event loop 完成了一個tick

講得好有道理，可是沒有demo我還是懂不全啊，憋急，now！

const fs = require('fs')fs.readFile('test.txt', () => {
  console.log('readFile')
  setTimeout(() => {
    console.log('timeout')
  }, 0)
  setImmediate(() => {
    console.log('immediate')
  })
  })

執行結果應該都沒有疑問了

readFile
immediate
timeout

Node.js 與瀏覽器的Event Loop 差異

回顧上一篇，瀏覽器環境下，microtask的任務佇列是每個macrotask執行完之後執行。

而在Node.js中，microtask會在事件循環的各個階段之間執行，也就是一個階段執行完畢，就會去執行microtask佇列的任務。

demo回顧

回顧文章最開始的demo，全域腳本（main()）執行，將2個timer依次放入timer佇列，main()執行完畢，呼叫堆疊空閒，任務佇列開始執行；

首先进入timers阶段，执行timer1的回调函数，打印timer1，并将promise1.then回调放入microtask队列，同样的步骤执行timer2，打印timer2；

至此，timer阶段执行结束，event loop进入下一个阶段之前，执行microtask队列的所有任务，依次打印promise1、promise2。

对比浏览器端的处理过程：

process.nextTick() VS setImmediate()

In essence, the names should be swapped. process.nextTick() fires more immediately than setImmediate()

来自官方文档有意思的一句话，从语义角度看，setImmediate() 应该比 process.nextTick() 先执行才对，而事实相反，命名是历史原因也很难再变。

process.nextTick() 会在各个事件阶段之间执行，一旦执行，要直到nextTick队列被清空，才会进入到下一个事件阶段，所以如果递归调用 process.nextTick()，会导致出现I/O starving（饥饿）的问题，比如下面例子的readFile已经完成，但它的回调一直无法执行：

const fs = require('fs')const starttime = Date.now()let endtime
fs.readFile('text.txt', () => {
  endtime = Date.now()
  console.log('finish reading time: ', endtime - starttime)})let index = 0function handler () {
  if (index++ >= 1000) return
  console.log(`nextTick ${index}`)
  process.nextTick(handler)
  // console.log(`setImmediate ${index}`)
  // setImmediate(handler)}handler()

process.nextTick()的运行结果：

nextTick 1
nextTick 2
......
nextTick 999
nextTick 1000
finish reading time: 170

替换成setImmediate()，运行结果：

setImmediate 1
setImmediate 2
finish reading time: 80
......
setImmediate 999
setImmediate 1000

这是因为嵌套调用的 setImmediate() 回调，被排到了下一次event loop才执行，所以不会出现阻塞。

总结

1、Node.js 的事件循环分为6个阶段

2、浏览器和Node 环境下，microtask 任务队列的执行时机不同

Node.js中，microtask 在事件循环的各个阶段之间执行

浏览器端，microtask 在事件循环的 macrotask 执行完之后执行

3、递归的调用process.nextTick()会导致I/O starving，官方推荐使用setImmediate()

以上是解析Node.js的事件循環機制的詳細內容。更多資訊請關注PHP中文網其他相關文章！