摘要：二瀏覽器端在講解事件循環之前先談談中同步代碼異步代碼的執行流程。三端我自己認為的事件循環和瀏覽器端還是有點區別的，它的事件循環依靠引擎。四總結本篇主要介紹了瀏覽器和對于事件循環機制實現，由于能力水平有限，其中可能有誤之處歡迎指出。

前幾天聽公司一個公司三年的前端說“今天又學到了一個知識點-微任務、宏任務”，我問他這是什么東西，由于在吃飯他淺淺的說了下，當時沒太理解就私下學習整理一番，由于談微任務、宏任務必談到事件循環，于是就有了這篇博客。

在談到事件循環機制之前我們需要知道一些基礎知識就是:

js是單線程的

js一開始是作為腳本語言運行在客戶端

其實js是單線程在它作為腳本語言操作dom的時候就決定了。那么此時就有一個性能問題，那么js在瀏覽器端是如何處理這個問題的呢？同時，js在后臺Node中又是如何解決的呢？這就是本篇需要介紹的事件循環機制，這里我將分別以瀏覽器和Node兩個方面來分析。

在講解事件循環之前先談談js中同步代碼、異步代碼的執行流程。

js引擎在執行通過代碼的過程中，會安裝順序依次存儲到一個地方去，這個地方就叫做執行棧，當我們調用一個方法的時候，js會生成一個和這個方法相對應的上下文(context)。這個執行環境中存在著這個方法的私有作用域，上層作用域的指向，方法的參數，這個作用域中定義的變量以及這個作用域的this對象。

function a() {
    console.log("method a execute...");
}
function b() {
    a();
}
function c() {
    b();
}
c();

以上面例子分析:js在執行的時候會有一個全局上下文,我們這里就稱為GContext,下面分析步驟

調用c(),c入棧,此時棧中內容為:GContext->c-contextC

接著調用b(),b入棧,此時棧中內容為:GContext->c->contextC->b->contextB

接著調用a(),a入棧,此時棧中內容為:GContext->c->contextC->b->contextB-c->contextC

a執行完,a出棧,此時棧中內容為:GContext->c->contextC->b->contextB

b執行完,b出棧,此時棧中內容為:GContext->c->contextC

c執行完,b出棧,此時棧中內容為:GContext

全部執行完,釋放資源

ok,上面是同步代碼的執行,上面會涉及到兩個核心概念:執行整個代碼的線程我們稱之為主線程,存放方法執行的地方我們稱之為執行棧.

上面說完了同步過程，那這里來談談異步的過程。js引擎在遇到一個異步事件,不會一直等待返回結果而是將它掛起。當異步任務執行完之后會將結果加入到和執行棧中不同的任務隊列當中,注意的是:此時放入隊列不會立即執行其回調,而是當主線程執行完執行棧中所有的任務之后再去隊列中查找是否有任務,如果有則取出排在第一位的事件然后將回調放入執行棧并執行其代碼。如此反復就構成了事件循環。

這里同樣有一個核心概念：任務隊列

上面提到js執行異步方法的時候會將其返回結果放到隊列中，這是比較籠統的，具體來說，js會根據任務的類型將其放入不同的隊列，任務類型有兩種:微任務、宏任務。那么其對應的哪些是微任務、哪些是宏任務呢？

微任務：Promise、process.nextTick()、整體代碼script、Object.observer、MutationObserver

宏任務：setTimeout()、setInterval()

瀏覽器在執行的時候,先從宏任務隊列中取出一個宏任務執行宏,然后在執行該宏任務下的所有的微任務,這是一個循環;然后再取出并執行下一個宏任務,再執行所有的微任務,這是第二個循環,以此類推.

注意:整個javascript代碼是第一個宏任務

const process = require("process")
setTimeout(function () {// 分發宏任務到EventQueue
    console.log("1");
}, 0);
setTimeout(() => {
    console.log("11");
}, 0);
setTimeout(() => {
    console.log("111");
}, 0);
new Promise(function (resolve) {
    console.log("2");
    resolve();
}).then(function () {// 發送微任務
    console.log("3");
});

// 輸出
2
3
1
11
111

在瀏覽器端,在我們執行一片script的時候,當遇到同步代碼，依次進入執行棧，遇到異步代碼，將其掛起，繼續執行其它方法，當異步方法執行完之后根據任務類型進入到任務隊列，在執行棧執行完，主線程空閑下來了之后會到任務隊列中取任務回調并執行。

我自己認為Node的事件循環和瀏覽器端還是有點區別的，它的事件循環依靠libuv引擎。

該圖來自官網，這里展示了在node的事件循環的6個階段。

timers:該階段執行定時器的回調,如setTimeout() 和 setInterval()。

I/O callbacks:該階段執行除了close事件，定時器和setImmediate()的回調外的所有回調

idle, prepare:內部使用

poll:等待新的I/O事件，node在一些特殊情況下會阻塞在這里

check: setImmediate()的回調會在這個階段執行

close callbacks: 例如socket.on("close", ...)這種close事件的回調

對于我們來說我們更關注 timer、poll、check這三個階段即可。

poll 階段有兩個主要的功能：

處理poll隊列（poll quenue）的事件(callback);

執行timers的callback,當到達timers指定的時間時;

poll 階段的邏輯

如果event loop進入了 poll階段，且代碼未設定timer，將會發生下面情況：

a、如果poll queue不為空，event loop將同步的執行queue里的callback,直至queue為空，或執行的callback到達系統上限;

b、如果poll queue為空，將會發生下面情況：

* 如果代碼已經被setImmediate()設定了callback, event loop將結束poll階段進入check階段，并執行check階段的queue (check階段的queue是 setImmediate設定的)
* 如果代碼沒有設定setImmediate(callback)，event loop將阻塞在該階段等待callbacks加入poll queue;

如果event loop進入了 poll階段，且代碼設定了timer：

如果poll queue進入空狀態時（即poll 階段為空閑狀態），event loop將檢查timers,

如果有1個或多個timers時間時間已經到達，event loop將按循環順序進入 timers 階段，并執行timer queue

這兩個函數的功能還是類似的,不同的是他們處于EventLoop的不同階段:timer、check。

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

上面兩行代碼會輸出順序是什么呢?其實兩種可能都有.
1.當setTimeout的0ms并不能做到絕對0ms,如果已經過了timer階段,那么此時setTimeout就會在下一次循環中執行,也就是說先setInterval、再setTimeout。
2.第二種可能就是正常流程了,先timer、再check

如果上面的代碼再一個IO操作作呢?如:

require("fs").readFile(__filename,()=>{
    setImmediate(()=>console.log("setInterval"));
    setTimeout(() => {console.log("setTimeout")});
})

此時只可能出現一種情況,先setInterval、再setTimeout，因為在io中已經執行過了timer(readFile時處于IO callback)。
下面一起來看如下代碼:

setTimeout(() => {
    console.log("timer1")
    Promise.resolve().then(() => console.log("promise1"));
    process.nextTick(() => console.log("nextTick1"))
}, 0);
setTimeout(() => {
    console.log("timer2")
    Promise.resolve().then(() => console.log("promise2"));
    process.nextTick(() => console.log("nextTick2"))
}, 0);

按照我的理解,它的輸出應該是如下:先timer、然后切換階段的時候執行微任務.

// 情況1
timer1
timer2
nextTick1
nextTick2
promise1
promise2

可是并不是,它的輸出一直是:

// 情況2
timer1
nextTick1
promise1
timer2
nextTick2
promise2

后臺晚上查資料因為Node11對EventLoop作了修改,為了和瀏覽器兼容。于是呼我切換到10.8.0,發現上面兩種情況都有(情況1比例大于情況2)。這點暫時還未查明什么原因。

node中的6個階段每個階段執行完都會伴隨著執行微任務,同個MicroTask隊列下process.tick()會優于Promise。

本篇主要介紹了瀏覽器和Node對于事件循環機制實現，由于能力水平有限，其中可能有誤之處歡迎指出。

歡迎關注公眾號: