分析Node.js中的event-loop機(jī)制

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

libuv

在學(xué)習(xí)event-loop之前，先了解下node的libuv。libuv負(fù)責(zé)不同操作系統(tǒng)上的不同I/O模型的實(shí)現(xiàn)，并且把不同的實(shí)現(xiàn)抽象為能應(yīng)用與第三方應(yīng)用程序的API。

問題

在正式學(xué)習(xí)event-loop前，先思考一個(gè)問題

    setTimeout(() => {
      console.log("timer1");
      Promise.resolve().then(() => {
        console.log("promise1");
      });
    }, 0);

    setTimeout(() => {
      console.log("timer2");
      Promise.resolve().then(() => {
        console.log("promise2");
      });
    }, 0);

這段代碼在瀏覽器中運(yùn)行的結(jié)果是怎樣的？

在node中運(yùn)行的結(jié)果又是怎樣的呢？

在node8.6之前：

node8.6之后：

為什么會(huì)有這樣的結(jié)果，我們稍后分析!

nodeJs 中的event-loop

首先，來看一張圖：

在圖中可以看到6個(gè)階段，分別是：timers，pending callbacks,idle/prepare，poll，check，close callbacks。

• timers階段：主要執(zhí)行setTimeOut,setInterval的回調(diào)

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

• idle/prepare階段：只在系統(tǒng)內(nèi)部使用(這個(gè)階段我們控制干涉不了)

• poll階段：獲取新的I/O事件，比如獲取一個(gè)讀取文件的I/O回調(diào)。在適合的情況下，nodejs將阻塞在這個(gè)階段

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

• 比如執(zhí)行sokect的destory,close事件回調(diào)

每一個(gè)階段都遵循一個(gè)FIFO(先入先出)的規(guī)則來執(zhí)行任務(wù)隊(duì)列里面的任務(wù)。 在這六個(gè)階段中，我們著重需要關(guān)注的是timers，poll,check階段。我們?nèi)粘ｉ_發(fā)中的絕大部分異步任務(wù)都是在這三個(gè)階段處理的。

timers

我們先來說一說timers階段。
timers是事件循環(huán)的第一個(gè)階段，nodejs會(huì)去檢查有沒有已經(jīng)過期了的timer，如果有，就將它的回調(diào)放入隊(duì)列中。但是nodejs并不能保證timer在預(yù)設(shè)事件到了就會(huì)立即執(zhí)行回調(diào)，這是因?yàn)閚odejs對timer的過期檢查不一定靠譜，它會(huì)受機(jī)器上其他運(yùn)行程序的影響，或者是會(huì)遇到當(dāng)前主線程不空閑的情況。
對于這里的不確定性，官網(wǎng)上舉了一個(gè)例子：
先聲明一個(gè)setTimeOut,然后外部讀取一個(gè)文件，當(dāng)讀取文件操作超過定時(shí)器的時(shí)間，這樣一來讀文件操作就會(huì)把定時(shí)器的回調(diào)延后，這就是前面說的主線程不空閑的情況。

poll

poll階段主要是執(zhí)行兩件事情：

1、處理poll階段的任務(wù)隊(duì)列

2、當(dāng)有了已經(jīng)超時(shí)的timer執(zhí)行它的回調(diào)函數(shù)

在上圖中，我們還可以看到：在poll階段執(zhí)行完poll任務(wù)隊(duì)列的任務(wù)之后，會(huì)去檢查有無預(yù)設(shè)的setImmediate,如果有，則進(jìn)入check階段，如果沒有，則nodejs將會(huì)阻塞在這里。

這里我們就會(huì)有一個(gè)疑問了，如果阻塞在poll階段，那我們設(shè)置的timer豈不是執(zhí)行不了了嗎？
其實(shí)當(dāng)event-loop阻塞在poll階段時(shí)，nodejs會(huì)有一個(gè)檢查機(jī)制，它會(huì)去檢查timers隊(duì)列是否為空，如果不為空，則重新進(jìn)入timers階段。

check

check階段主要時(shí)執(zhí)行setImmediate的回調(diào)函數(shù)。

小總結(jié)

event-loop的每個(gè)階段都有一個(gè)隊(duì)列，當(dāng)event-loop達(dá)到某個(gè)階段之后，將執(zhí)行這個(gè)階段的任務(wù)隊(duì)列，直到隊(duì)列清空或者達(dá)到系統(tǒng)規(guī)定的最大回調(diào)限制之后，才會(huì)進(jìn)入下一個(gè)階段。當(dāng)所有階段都執(zhí)行完成一次之后，稱event-loop完成一個(gè)tick。

案例

上面我們說完了event-loop的理論部分，但是光有理論我們也還是不能很清晰的理解event-loop。下面我們就根據(jù)幾個(gè)demo來更加深入的理解下event-loop！

demo1

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

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

可見執(zhí)行結(jié)果跟我們前面的分析時(shí)一致的！

demo2

    const fs = require("fs");
    const EventEmitter = require("events").EventEmitter;
    let pos = 0;
    const messenger = new EventEmitter();

    messenger.on("message", function (msg) {
      console.log(++pos + " message:" + msg); //
    });

    console.log(++pos + " first"); //

    process.nextTick(function () {
      console.log(++pos + " nextTick"); //
    });

    messenger.emit("message", "hello!");
    fs.stat(__filename, function () {
      console.log(++pos + " stat"); //
    });

    setTimeout(function () {
      console.log(++pos + " quick timer"); //
    }, 0);
    setTimeout(function () {
      console.log(++pos + " long timer"); //
    }, 30);
    setImmediate(function () {
      console.log(++pos + " immediate"); //
    });

    console.log(++pos + " last"); //

結(jié)果：

了解下瀏覽器和node的event-loop差異在什么地方

在node 8.6 之前：

瀏覽器中的微任務(wù)隊(duì)列會(huì)在每個(gè)宏任務(wù)執(zhí)行完成之后執(zhí)行，而node中的微任務(wù)會(huì)在事件循環(huán)的各個(gè)階段之間執(zhí)行，即每個(gè)階段執(zhí)行完成之后會(huì)去執(zhí)行微任務(wù)隊(duì)列。

在8.6之后：

瀏覽器和node中微任務(wù)的執(zhí)行是一致的！

所以，在文章開頭，我們提出的思考的問題就有了結(jié)果。

關(guān)于 process.nextTick()和setImmediate

process.nextTick()

語法：process.nextTick(callback,agrs)

執(zhí)行時(shí)機(jī)：

這個(gè)函數(shù)其實(shí)是獨(dú)立于 Event Loop 之外的，它有一個(gè)自己的隊(duì)列，當(dāng)每個(gè)階段完成后，如果存在 nextTick 隊(duì)列，就會(huì)清空隊(duì)列中的所有回調(diào)函數(shù)，并且優(yōu)先于其他 microtask 執(zhí)行。遞歸的調(diào)用process.nextTick()會(huì)導(dǎo)致I/O starving，官方推薦使用setImmediate()

關(guān)于starving現(xiàn)象的說明：

    const fs = require("fs");
    fs.readFile("test.txt", (err, msg) => {
      console.log("readFile");
    });

    let index = 0;

    function handler() {
      if (index >= 30) return;
      index++;
      console.log("nextTick" + index);
      process.nextTick(handler);
    }

    handler();

運(yùn)行結(jié)果:

可以看到，等到nextTick函數(shù)唄執(zhí)行30次之后，讀取文件的回調(diào)才被執(zhí)行！這樣的現(xiàn)象被稱為 I/O 饑餓。

當(dāng)我們把 process.nextTick 換為 setImmediate

    const fs = require("fs");
    fs.readFile("test.txt", (err, msg) => {
      console.log("readFile");
    });

    let index = 0;

    function handler() {
      if (index >= 30) return;
      index++;
      console.log("nextTick" + index);
      setImmediate(handler);
    }

    handler();

結(jié)果：

造成這兩種差異的原因是，嵌套調(diào)用的setImmediate的回調(diào)被排到了下一次event-loop中去！

event-loop核心思維導(dǎo)圖

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