Node.js事件循環(huán)機(jī)制實(shí)例代碼分析

這篇文章主要介紹“Node.js事件循環(huán)機(jī)制實(shí)例代碼分析”，在日常操作中，相信很多人在Node.js事件循環(huán)機(jī)制實(shí)例代碼分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Node.js事件循環(huán)機(jī)制實(shí)例代碼分析”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

先看一個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)

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

timer1
promise1
timer2
promise2

那么Node下執(zhí)行看看，咦。。。奇怪，跟瀏覽器的運(yùn)行結(jié)果并不一樣~

timer1
timer2
promise1
promise2

例子說明，瀏覽器和 Node.js 的事件循環(huán)機(jī)制是有區(qū)別的，一起來看個究竟吧~

Node.js的事件處理

Node.js采用V8作為js的解析引擎，而I/O處理方面使用了自己設(shè)計(jì)的libuv，libuv是一個基于事件驅(qū)動的跨平臺抽象層，封裝了不同操作系統(tǒng)一些底層特性，對外提供統(tǒng)一的API，事件循環(huán)機(jī)制也是它里面的實(shí)現(xiàn)，核心源碼參考：

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;
}

根據(jù)Node.js官方介紹，每次事件循環(huán)都包含了6個階段，對應(yīng)到 libuv 源碼中的實(shí)現(xiàn)

timers 階段：這個階段執(zhí)行timer（setTimeout、setInterval）的回調(diào)

I/O callbacks 階段：執(zhí)行一些系統(tǒng)調(diào)用錯誤，比如網(wǎng)絡(luò)通信的錯誤回調(diào)

idle, prepare 階段：僅node內(nèi)部使用

poll 階段：獲取新的I/O事件, 適當(dāng)?shù)臈l件下node將阻塞在這里

check 階段：執(zhí)行 setImmediate() 的回調(diào)

close callbacks 階段：執(zhí)行 socket 的 close 事件回調(diào)

我們重點(diǎn)看timers、poll、check這3個階段就好，因?yàn)槿粘ｉ_發(fā)中的絕大部分異步任務(wù)都是在這3個階段處理的。

timers 階段

timers 是事件循環(huán)的第一個階段，Node 會去檢查有無已過期的timer，如果有則把它的回調(diào)壓入timer的任務(wù)隊(duì)列中等待執(zhí)行，事實(shí)上，Node 并不能保證timer在預(yù)設(shè)時間到了就會立即執(zhí)行，因?yàn)镹ode對timer的過期檢查不一定靠譜，它會受機(jī)器上其它運(yùn)行程序影響，或者那個時間點(diǎn)主線程不空閑。比如下面的代碼，setTimeout() 和 setImmediate() 的執(zhí)行順序是不確定的。

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

但是把它們放到一個I/O回調(diào)里面，就一定是 setImmediate() 先執(zhí)行，因?yàn)閜oll階段后面就是check階段。

poll 階段

poll 階段主要有2個功能：

處理 poll 隊(duì)列的事件

當(dāng)有已超時的 timer，執(zhí)行它的回調(diào)函數(shù)

even loop將同步執(zhí)行poll隊(duì)列里的回調(diào)，直到隊(duì)列為空或執(zhí)行的回調(diào)達(dá)到系統(tǒng)上限（上限具體多少未詳），接下來even loop會去檢查有無預(yù)設(shè)的setImmediate()，分兩種情況：

若有預(yù)設(shè)的setImmediate(), event loop將結(jié)束poll階段進(jìn)入check階段，并執(zhí)行check階段的任務(wù)隊(duì)列

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

注意一個細(xì)節(jié)，沒有setImmediate()會導(dǎo)致event loop阻塞在poll階段，這樣之前設(shè)置的timer豈不是執(zhí)行不了了？所以咧，在poll階段event loop會有一個檢查機(jī)制，檢查timer隊(duì)列是否為空，如果timer隊(duì)列非空，event loop就開始下一輪事件循環(huán)，即重新進(jìn)入到timer階段。

check 階段

setImmediate()的回調(diào)會被加入check隊(duì)列中， 從event loop的階段圖可以知道，check階段的執(zhí)行順序在poll階段之后。

小結(jié)

event loop 的每個階段都有一個任務(wù)隊(duì)列

當(dāng) event loop 到達(dá)某個階段時，將執(zhí)行該階段的任務(wù)隊(duì)列，直到隊(duì)列清空或執(zhí)行的回調(diào)達(dá)到系統(tǒng)上限后，才會轉(zhuǎn)入下一個階段

當(dāng)所有階段被順序執(zhí)行一次后，稱 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')
  })
  })

執(zhí)行結(jié)果應(yīng)該都沒有疑問了

readFile
immediate
timeout

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

瀏覽器環(huán)境下，microtask的任務(wù)隊(duì)列是每個macrotask執(zhí)行完之后執(zhí)行。

而在Node.js中，microtask會在事件循環(huán)的各個階段之間執(zhí)行，也就是一個階段執(zhí)行完畢，就會去執(zhí)行microtask隊(duì)列的任務(wù)。

demo回顧

回顧文章最開始的demo，全局腳本（main()）執(zhí)行，將2個timer依次放入timer隊(duì)列，main()執(zhí)行完畢，調(diào)用?？臻e，任務(wù)隊(duì)列開始執(zhí)行；

首先進(jìn)入timers階段，執(zhí)行timer1的回調(diào)函數(shù)，打印timer1，并將promise1.then回調(diào)放入microtask隊(duì)列，同樣的步驟執(zhí)行timer2，打印timer2；

至此，timer階段執(zhí)行結(jié)束，event loop進(jìn)入下一個階段之前，執(zhí)行microtask隊(duì)列的所有任務(wù)，依次打印promise1、promise2。

對比瀏覽器端的處理過程：

process.nextTick() VS setImmediate()

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

來自官方文檔有意思的一句話，從語義角度看，setImmediate() 應(yīng)該比 process.nextTick() 先執(zhí)行才對，而事實(shí)相反，命名是歷史原因也很難再變。

process.nextTick() 會在各個事件階段之間執(zhí)行，一旦執(zhí)行，要直到nextTick隊(duì)列被清空，才會進(jìn)入到下一個事件階段，所以如果遞歸調(diào)用 process.nextTick()，會導(dǎo)致出現(xiàn)I/O starving（饑餓）的問題，比如下面例子的readFile已經(jīng)完成，但它的回調(diào)一直無法執(zhí)行：

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()的運(yùn)行結(jié)果：

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

替換成setImmediate()，運(yùn)行結(jié)果：

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

這是因?yàn)榍短渍{(diào)用的 setImmediate() 回調(diào)，被排到了下一次event loop才執(zhí)行，所以不會出現(xiàn)阻塞。

到此，關(guān)于“Node.js事件循環(huán)機(jī)制實(shí)例代碼分析”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！