本篇文章帶大家深度理解Node中的事件循環(huán)，希望對(duì)大家有所幫助！

node.js極速入門課程：進(jìn)入學(xué)習(xí)

ALL THE TIME，我們寫的的大部分javascript代碼都是在瀏覽器環(huán)境下編譯運(yùn)行的，因此可能我們對(duì)瀏覽器的事件循環(huán)機(jī)制了解比Node.JS的事件循環(huán)更深入一些，但是最近寫開始深入NodeJS學(xué)習(xí)的時(shí)候，發(fā)現(xiàn)NodeJS的事件循環(huán)機(jī)制和瀏覽器端有很大的區(qū)別，特此記錄來深入的學(xué)習(xí)了下，以幫助自己及小伙伴們忘記后查閱及理解。

什么是事件循環(huán)

首先我們需要了解一下最基礎(chǔ)的一些東西，比如這個(gè)事件循環(huán)，事件循環(huán)是指Node.js執(zhí)行非阻塞I/O操作，盡管==JavaScript是單線程的==,但由于大多數(shù)==內(nèi)核都是多線程==的，Node.js會(huì)盡可能將操作裝載到系統(tǒng)內(nèi)核。因此它們可以處理在后臺(tái)執(zhí)行的多個(gè)操作。當(dāng)其中一個(gè)操作完成時(shí)，內(nèi)核會(huì)告訴Node.js，以便Node.js可以將相應(yīng)的回調(diào)添加到輪詢隊(duì)列中以最終執(zhí)行?！鞠嚓P(guān)教程推薦：nodejs視頻教程】

當(dāng)Node.js啟動(dòng)時(shí)會(huì)初始化event loop, 每一個(gè)event loop都會(huì)包含按如下順序六個(gè)循環(huán)階段：

   ┌───────────────────────┐ ┌─>│        timers         │ │  └──────────┬────────────┘ │  ┌──────────┴────────────┐ │  │     I/O callbacks     │ │  └──────────┬────────────┘ │  ┌──────────┴────────────┐ │  │     idle, prepare     │ │  └──────────┬────────────┘      ┌───────────────┐ │  ┌──────────┴────────────┐      │   incoming:   │ │  │         poll          │<─────┤  connections, │ │  └──────────┬────────────┘      │   data, etc.  │ │  ┌──────────┴────────────┐      └───────────────┘ │  │        check          │ │  └──────────┬────────────┘ │  ┌──────────┴────────────┐ └──┤    close callbacks    │    └───────────────────────┘

• 1. timers 階段: 這個(gè)階段執(zhí)行 setTimeout(callback) 和 setInterval(callback) 預(yù)定的 callback;
• 2. I/O callbacks 階段: 此階段執(zhí)行某些系統(tǒng)操作的回調(diào)，例如TCP錯(cuò)誤的類型。 例如，如果TCP套接字在嘗試連接時(shí)收到 ECONNREFUSED，則某些* nix系統(tǒng)希望等待報(bào)告錯(cuò)誤。 這將操作將等待在==I/O回調(diào)階段==執(zhí)行;
• 3. idle, prepare 階段: 僅node內(nèi)部使用;
• 4. poll 階段: 獲取新的I/O事件, 例如操作讀取文件等等，適當(dāng)?shù)臈l件下node將阻塞在這里;
• 5. check 階段: 執(zhí)行 setImmediate() 設(shè)定的callbacks;
• 6. close callbacks 階段: 比如 socket.on(‘close’, callback) 的callback會(huì)在這個(gè)階段執(zhí)行;

事件循環(huán)詳解

這個(gè)圖是整個(gè) Node.js 的運(yùn)行原理，從左到右，從上到下，Node.js 被分為了四層，分別是 應(yīng)用層、V8引擎層、Node API層 和 LIBUV層。

• 應(yīng)用層： 即 JavaScript 交互層，常見的就是 Node.js 的模塊，比如 http，fs
• V8引擎層： 即利用 V8 引擎來解析JavaScript 語法，進(jìn)而和下層 API 交互
• NodeAPI層： 為上層模塊提供系統(tǒng)調(diào)用，一般是由 C 語言來實(shí)現(xiàn)，和操作系統(tǒng)進(jìn)行交互 。
• LIBUV層： 是跨平臺(tái)的底層封裝，實(shí)現(xiàn)了 事件循環(huán)、文件操作等，是 Node.js 實(shí)現(xiàn)異步的核心 。

每個(gè)循環(huán)階段內(nèi)容詳解

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

• 注意：技術(shù)上來說，poll 階段控制 timers 什么時(shí)候執(zhí)行。

• 注意：這個(gè)下限時(shí)間有個(gè)范圍：[1, 2147483647]，如果設(shè)定的時(shí)間不在這個(gè)范圍，將被設(shè)置為1。

I/O callbacks階段 這個(gè)階段執(zhí)行一些系統(tǒng)操作的回調(diào)。比如TCP錯(cuò)誤，如一個(gè)TCP socket在想要連接時(shí)收到ECONNREFUSED, 類unix系統(tǒng)會(huì)等待以報(bào)告錯(cuò)誤，這就會(huì)放到 I/O callbacks 階段的隊(duì)列執(zhí)行. 名字會(huì)讓人誤解為執(zhí)行I/O回調(diào)處理程序, 實(shí)際上I/O回調(diào)會(huì)由poll階段處理.

poll階段 poll 階段有兩個(gè)主要功能：（1）執(zhí)行下限時(shí)間已經(jīng)達(dá)到的timers的回調(diào)，（2）然后處理 poll 隊(duì)列里的事件。 當(dāng)event loop進(jìn)入 poll 階段，并且 沒有設(shè)定的 timers（there are no timers scheduled），會(huì)發(fā)生下面兩件事之一：

• 如果 poll 隊(duì)列不空，event loop會(huì)遍歷隊(duì)列并同步執(zhí)行回調(diào)，直到隊(duì)列清空或執(zhí)行的回調(diào)數(shù)到達(dá)系統(tǒng)上限；

• 如果 poll 隊(duì)列為空，則發(fā)生以下兩件事之一：

  • 如果代碼已經(jīng)被setImmediate()設(shè)定了回調(diào), event loop將結(jié)束 poll 階段進(jìn)入 check 階段來執(zhí)行 check 隊(duì)列（里面的回調(diào) callback）。
  • 如果代碼沒有被setImmediate()設(shè)定回調(diào)，event loop將阻塞在該階段等待回調(diào)被加入 poll 隊(duì)列，并立即執(zhí)行。

• 但是，當(dāng)event loop進(jìn)入 poll 階段，并且 有設(shè)定的timers，一旦 poll 隊(duì)列為空（poll 階段空閑狀態(tài)）： event loop將檢查timers,如果有1個(gè)或多個(gè)timers的下限時(shí)間已經(jīng)到達(dá)，event loop將繞回 timers 階段，并執(zhí)行 timer 隊(duì)列。

check階段 這個(gè)階段允許在 poll 階段結(jié)束后立即執(zhí)行回調(diào)。如果 poll 階段空閑，并且有被setImmediate()設(shè)定的回調(diào)，event loop會(huì)轉(zhuǎn)到 check 階段而不是繼續(xù)等待。

• setImmediate() 實(shí)際上是一個(gè)特殊的timer，跑在event loop中一個(gè)獨(dú)立的階段。它使用libuv的API 來設(shè)定在 poll 階段結(jié)束后立即執(zhí)行回調(diào)。

• 通常上來講，隨著代碼執(zhí)行，event loop終將進(jìn)入 poll 階段，在這個(gè)階段等待 incoming connection, request 等等。但是，只要有被setImmediate()設(shè)定了回調(diào)，一旦 poll 階段空閑，那么程序?qū)⒔Y(jié)束 poll 階段并進(jìn)入 check 階段，而不是繼續(xù)等待 poll 事件們 （poll events）。

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

這里呢，我們通過偽代碼來說明一下，這個(gè)流程：

// 事件循環(huán)本身相當(dāng)于一個(gè)死循環(huán)，當(dāng)代碼開始執(zhí)行的時(shí)候，事件循環(huán)就已經(jīng)啟動(dòng)了 // 然后順序調(diào)用不同階段的方法 while(true){ // timer階段     timer() // I/O callbacks階段     IO() // idle階段     IDLE() // poll階段     poll() // check階段     check() // close階段     close() } // 在一次循環(huán)中，當(dāng)事件循環(huán)進(jìn)入到某一階段，加入進(jìn)入到check階段，突然timer階段的事件就緒，也會(huì)等到當(dāng)前這次循環(huán)結(jié)束，再去執(zhí)行對(duì)應(yīng)的timer階段的回調(diào)函數(shù)  // 下面看這里例子 const fs = require('fs')  // timers階段 const startTime = Date.now(); setTimeout(() => {     const endTime = Date.now()     console.log(`timers: ${endTime - startTime}`) }, 1000)  // poll階段(等待新的事件出現(xiàn)) const readFileStart =  Date.now(); fs.readFile('./Demo.txt', (err, data) => {     if (err) throw err     let endTime = Date.now()     // 獲取文件讀取的時(shí)間     console.log(`read time: ${endTime - readFileStart}`)     // 通過while循環(huán)將fs回調(diào)強(qiáng)制阻塞5000s     while(endTime - readFileStart < 5000){         endTime = Date.now()     }  })   // check階段 setImmediate(() => {     console.log('check階段') }) /*控制臺(tái)打印check階段read time: 9timers: 5008通過上述結(jié)果進(jìn)行分析，1.代碼執(zhí)行到定時(shí)器setTimeOut，目前timers階段對(duì)應(yīng)的事件列表為空，在1000s后才會(huì)放入事件2.事件循環(huán)進(jìn)入到poll階段，開始不斷的輪詢監(jiān)聽事件3.fs模塊異步執(zhí)行，根據(jù)文件大小，可能執(zhí)行時(shí)間長短不同，這里我使用的小文件，事件大概在9s左右4.setImmediate執(zhí)行，poll階段暫時(shí)未監(jiān)測到事件，發(fā)現(xiàn)有setImmediate函數(shù)，跳轉(zhuǎn)到check階段執(zhí)行check階段事件（打印check階段），第一次時(shí)間循環(huán)結(jié)束，開始下一輪事件循環(huán)5.因?yàn)闀r(shí)間仍未到定時(shí)器截止時(shí)間，所以事件循環(huán)有一次進(jìn)入到poll階段，進(jìn)行輪詢6.讀取文件完畢，fs產(chǎn)生了一個(gè)事件進(jìn)入到poll階段的事件隊(duì)列，此時(shí)事件隊(duì)列準(zhǔn)備執(zhí)行callback，所以會(huì)打印（read time: 9），人工阻塞了5s，雖然此時(shí)timer定時(shí)器事件已經(jīng)被添加，但是因?yàn)檫@一階段的事件循環(huán)為完成，所以不會(huì)被執(zhí)行，（如果這里是死循環(huán)，那么定時(shí)器代碼永遠(yuǎn)無法執(zhí)行）7.fs回調(diào)阻塞5s后，當(dāng)前事件循環(huán)結(jié)束，進(jìn)入到下一輪事件循環(huán)，發(fā)現(xiàn)timer事件隊(duì)列有事件，所以開始執(zhí)行 打印timers: 5008ps：1.將定時(shí)器延遲時(shí)間改為5ms的時(shí)候，小于文件讀取時(shí)間，那么就會(huì)先監(jiān)聽到timers階段有事件進(jìn)入，從而進(jìn)入到timers階段執(zhí)行，執(zhí)行完畢繼續(xù)進(jìn)行事件循環(huán)check階段timers: 6read time: 50082.將定時(shí)器事件設(shè)置為0ms，會(huì)在進(jìn)入到poll階段的時(shí)候發(fā)現(xiàn)timers階段已經(jīng)有callback，那么會(huì)直接執(zhí)行，然后執(zhí)行完畢在下一階段循環(huán)，執(zhí)行check階段，poll隊(duì)列的回調(diào)函數(shù)timers: 2check階段read time: 7 */

走進(jìn)案例解析

我們來看一個(gè)簡單的EventLoop的例子：

const fs = require('fs'); let counts = 0;  // 定義一個(gè) wait 方法 function wait (mstime) {   let date = Date.now();   while (Date.now() - date < mstime) {     // do nothing   } }  // 讀取本地文件 操作IO function asyncOperation (callback) {   fs.readFile(__dirname + '/' + __filename, callback); }  const lastTime = Date.now();  // setTimeout setTimeout(() => {   console.log('timers', Date.now() - lastTime + 'ms'); }, 0);  // process.nextTick process.nextTick(() => {   // 進(jìn)入event loop   // timers階段之前執(zhí)行   wait(20);   asyncOperation(() => {     console.log('poll');   });   });  /** * timers 21ms * poll */

這里呢，為了讓這個(gè)setTimeout優(yōu)先于fs.readFile 回調(diào), 執(zhí)行了process.nextTick, 表示在進(jìn)入timers階段前, 等待20ms后執(zhí)行文件讀取.

1. nextTick 與 setImmediate

• process.nextTick 不屬于事件循環(huán)的任何一個(gè)階段，它屬于該階段與下階段之間的過渡, 即本階段執(zhí)行結(jié)束, 進(jìn)入下一個(gè)階段前, 所要執(zhí)行的回調(diào)。有給人一種插隊(duì)的感覺.

• setImmediate 的回調(diào)處于check階段, 當(dāng)poll階段的隊(duì)列為空, 且check階段的事件隊(duì)列存在的時(shí)候，切換到check階段執(zhí)行，參考nodejs進(jìn)階視頻講解：進(jìn)入學(xué)習(xí)

nextTick 遞歸的危害

由于nextTick具有插隊(duì)的機(jī)制，nextTick的遞歸會(huì)讓事件循環(huán)機(jī)制無法進(jìn)入下一個(gè)階段. 導(dǎo)致I/O處理完成或者定時(shí)任務(wù)超時(shí)后仍然無法執(zhí)行, 導(dǎo)致了其它事件處理程序處于饑餓狀態(tài). 為了防止遞歸產(chǎn)生的問題, Node.js 提供了一個(gè) process.maxTickDepth (默認(rèn) 1000)。

const fs = require('fs'); let counts = 0;  function wait (mstime) {   let date = Date.now();   while (Date.now() - date < mstime) {     // do nothing   } }  function nextTick () {   process.nextTick(() => {     wait(20);     console.log('nextTick');     nextTick();   }); }  const lastTime = Date.now();  setTimeout(() => {   console.log('timers', Date.now() - lastTime + 'ms'); }, 0);  nextTick();

此時(shí)永遠(yuǎn)無法跳到timer階段去執(zhí)行setTimeout里面的回調(diào)方法, 因?yàn)樵谶M(jìn)入timers階段前有不斷的nextTick插入執(zhí)行. 除非執(zhí)行了1000次到了執(zhí)行上限，所以上面這個(gè)案例會(huì)不斷地打印出nextTick字符串

2. setImmediate

如果在一個(gè)I/O周期內(nèi)進(jìn)行調(diào)度，setImmediate() 將始終在任何定時(shí)器（setTimeout、setInterval）之前執(zhí)行.

3. setTimeout 與 setImmediate

• setImmediate()被設(shè)計(jì)在 poll 階段結(jié)束后立即執(zhí)行回調(diào)；
• setTimeout()被設(shè)計(jì)在指定下限時(shí)間到達(dá)后執(zhí)行回調(diào);

無 I/O 處理情況下：

setTimeout(function timeout () {   console.log('timeout'); },0);  setImmediate(function immediate () {   console.log('immediate'); });

執(zhí)行結(jié)果：

C:Users92809Desktopnode_test>node test.js timeout immediate  C:Users92809Desktopnode_test>node test.js timeout immediate  C:Users92809Desktopnode_test>node test.js timeout immediate  C:Users92809Desktopnode_test>node test.js immediate timeout

從結(jié)果，我們可以發(fā)現(xiàn)，這里打印輸出出來的結(jié)果，并沒有什么固定的先后順序，偏向于隨機(jī)，為什么會(huì)發(fā)生這樣的情況呢？

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

如果沒有到1ms，那么在timers階段的時(shí)候，下限時(shí)間沒到，setTimeout回調(diào)不執(zhí)行，事件循環(huán)來到了poll階段，這個(gè)時(shí)候隊(duì)列為空，于是往下繼續(xù)，先執(zhí)行了setImmediate()的回調(diào)函數(shù)，之后在下一個(gè)事件循環(huán)再執(zhí)行setTimemout的回調(diào)函數(shù)。

問題總結(jié)：而我們?cè)?=執(zhí)行啟動(dòng)代碼==的時(shí)候，進(jìn)入timers的時(shí)間延遲其實(shí)是==隨機(jī)的==，并不是確定的，所以會(huì)出現(xiàn)兩個(gè)函數(shù)執(zhí)行順序隨機(jī)的情況。

那我們?cè)賮砜匆欢未a：

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

打印結(jié)果如下：

C:Users92809Desktopnode_test>node test.js immediate timeout  C:Users92809Desktopnode_test>node test.js immediate timeout  C:Users92809Desktopnode_test>node test.js immediate timeout  # ... 省略 n 多次使用 node test.js 命令 ，結(jié)果都輸出 immediate timeout

這里，為啥和上面的隨機(jī)timer不一致呢，我們來分析下原因：

原因如下：fs.readFile的回調(diào)是在poll階段執(zhí)行的，當(dāng)其回調(diào)執(zhí)行完畢之后，poll隊(duì)列為空，而setTimeout入了timers的隊(duì)列，此時(shí)有代碼 setImmediate()，于是事件循環(huán)先進(jìn)入check階段執(zhí)行回調(diào)，之后在下一個(gè)事件循環(huán)再在timers階段中執(zhí)行回調(diào)。

當(dāng)然，下面的小案例同理：

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

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

綜上所演示，我們可以總結(jié)如下：

• 如果兩者都在主模塊中調(diào)用，那么執(zhí)行先后取決于進(jìn)程性能，也就是你的電腦好撇，當(dāng)然也就是隨機(jī)。
• 如果兩者都不在主模塊調(diào)用（被一個(gè)異步操作包裹），那么**setImmediate的回調(diào)永遠(yuǎn)先執(zhí)行**。

4. nextTick 與 Promise

概念：對(duì)于這兩個(gè)，我們可以把它們理解成一個(gè)微任務(wù)。也就是說，它其實(shí)不屬于事件循環(huán)的一部分。 那么他們是在什么時(shí)候執(zhí)行呢？ 不管在什么地方調(diào)用，他們都會(huì)在其所處的事件循環(huán)最后，事件循環(huán)進(jìn)入下一個(gè)循環(huán)的階段前執(zhí)行。

setTimeout(() => {     console.log('timeout0');     new Promise((resolve, reject) => { resolve('resolved') }).then(res => console.log(res));     new Promise((resolve, reject) => {       setTimeout(()=>{         resolve('timeout resolved')       })     }).then(res => console.log(res));     process.nextTick(() => {         console.log('nextTick1');         process.nextTick(() => {             console.log('nextTick2');         });     });     process.nextTick(() => {         console.log('nextTick3');     });     console.log('sync');     setTimeout(() => {         console.log('timeout2');     }, 0); }, 0);

控制臺(tái)打印如下：

C:Users92809Desktopnode_test>node test.js timeout0 sync nextTick1 nextTick3 nextTick2 resolved timeout2 timeout resolved

最總結(jié)：timers階段執(zhí)行外層setTimeout的回調(diào)，遇到同步代碼先執(zhí)行，也就有timeout0、sync的輸出。遇到process.nextTick及Promise后入微任務(wù)隊(duì)列，依次nextTick1、nextTick3、nextTick2、resolved入隊(duì)后出隊(duì)輸出。之后，在下一個(gè)事件循環(huán)的timers階段，執(zhí)行setTimeout回調(diào)輸出timeout2以及微任務(wù)Promise里面的setTimeout，輸出timeout resolved。（這里要說明的是 微任務(wù)nextTick優(yōu)先級(jí)要比Promise要高）

5. 最后案例

代碼片段1：

setImmediate(function(){   console.log("setImmediate");   setImmediate(function(){     console.log("嵌套setImmediate");   });   process.nextTick(function(){     console.log("nextTick");   }) });  /*     C:Users92809Desktopnode_test>node test.js    setImmediate    nextTick    嵌套setImmediate*/

解析：

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

代碼片段2：

async function async1(){     console.log('async1 start')     await async2()     console.log('async1 end')   } async function async2(){     console.log('async2') } console.log('script start') setTimeout(function(){     console.log('setTimeout0')  },0)   setTimeout(function(){     console.log('setTimeout3')  },3)   setImmediate(() => console.log('setImmediate')); process.nextTick(() => console.log('nextTick')); async1(); new Promise(function(resolve){     console.log('promise1')     resolve();     console.log('promise2') }).then(function(){     console.log('promise3') }) console.log('script end')

打印結(jié)果為：

C:Users92809Desktopnode_test>node test.js script start async1 start async2 promise1 promise2 script end nextTick promise3 async1 end setTimeout0 setTimeout3 setImmediate

大家呢，可以先看著代碼，默默地在心底走一變代碼，然后對(duì)比輸出的結(jié)果，當(dāng)然最后三位，我個(gè)人認(rèn)為是有點(diǎn)問題的，畢竟在主模塊運(yùn)行，大家的答案，最后三位可能會(huì)有偏差；