摘要：二瀏覽器端在講解事件循環(huán)之前先談?wù)勚型酱a異步代碼的執(zhí)行流程。三端我自己認(rèn)為的事件循環(huán)和瀏覽器端還是有點(diǎn)區(qū)別的，它的事件循環(huán)依靠引擎。四總結(jié)本篇主要介紹了瀏覽器和對(duì)于事件循環(huán)機(jī)制實(shí)現(xiàn)，由于能力水平有限，其中可能有誤之處歡迎指出。

前幾天聽(tīng)公司一個(gè)公司三年的前端說(shuō)“今天又學(xué)到了一個(gè)知識(shí)點(diǎn)-微任務(wù)、宏任務(wù)”，我問(wèn)他這是什么東西，由于在吃飯他淺淺的說(shuō)了下，當(dāng)時(shí)沒(méi)太理解就私下學(xué)習(xí)整理一番，由于談微任務(wù)、宏任務(wù)必談到事件循環(huán)，于是就有了這篇博客。

在談到事件循環(huán)機(jī)制之前我們需要知道一些基礎(chǔ)知識(shí)就是:

js是單線(xiàn)程的

js一開(kāi)始是作為腳本語(yǔ)言運(yùn)行在客戶(hù)端

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

在講解事件循環(huán)之前先談?wù)刯s中同步代碼、異步代碼的執(zhí)行流程。

js引擎在執(zhí)行通過(guò)代碼的過(guò)程中，會(huì)安裝順序依次存儲(chǔ)到一個(gè)地方去，這個(gè)地方就叫做執(zhí)行棧，當(dāng)我們調(diào)用一個(gè)方法的時(shí)候，js會(huì)生成一個(gè)和這個(gè)方法相對(duì)應(yīng)的上下文(context)。這個(gè)執(zhí)行環(huán)境中存在著這個(gè)方法的私有作用域，上層作用域的指向，方法的參數(shù)，這個(gè)作用域中定義的變量以及這個(gè)作用域的this對(duì)象。

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

以上面例子分析:js在執(zhí)行的時(shí)候會(huì)有一個(gè)全局上下文,我們這里就稱(chēng)為GContext,下面分析步驟

調(diào)用c(),c入棧,此時(shí)棧中內(nèi)容為:GContext->c-contextC

接著調(diào)用b(),b入棧,此時(shí)棧中內(nèi)容為:GContext->c->contextC->b->contextB

接著調(diào)用a(),a入棧,此時(shí)棧中內(nèi)容為:GContext->c->contextC->b->contextB-c->contextC

a執(zhí)行完,a出棧,此時(shí)棧中內(nèi)容為:GContext->c->contextC->b->contextB

b執(zhí)行完,b出棧,此時(shí)棧中內(nèi)容為:GContext->c->contextC

c執(zhí)行完,b出棧,此時(shí)棧中內(nèi)容為:GContext

全部執(zhí)行完,釋放資源

ok,上面是同步代碼的執(zhí)行,上面會(huì)涉及到兩個(gè)核心概念:執(zhí)行整個(gè)代碼的線(xiàn)程我們稱(chēng)之為主線(xiàn)程,存放方法執(zhí)行的地方我們稱(chēng)之為執(zhí)行棧.

上面說(shuō)完了同步過(guò)程，那這里來(lái)談?wù)劗惒降倪^(guò)程。js引擎在遇到一個(gè)異步事件,不會(huì)一直等待返回結(jié)果而是將它掛起。當(dāng)異步任務(wù)執(zhí)行完之后會(huì)將結(jié)果加入到和執(zhí)行棧中不同的任務(wù)隊(duì)列當(dāng)中,注意的是:此時(shí)放入隊(duì)列不會(huì)立即執(zhí)行其回調(diào),而是當(dāng)主線(xiàn)程執(zhí)行完執(zhí)行棧中所有的任務(wù)之后再去隊(duì)列中查找是否有任務(wù),如果有則取出排在第一位的事件然后將回調(diào)放入執(zhí)行棧并執(zhí)行其代碼。如此反復(fù)就構(gòu)成了事件循環(huán)。

這里同樣有一個(gè)核心概念：任務(wù)隊(duì)列

上面提到j(luò)s執(zhí)行異步方法的時(shí)候會(huì)將其返回結(jié)果放到隊(duì)列中，這是比較籠統(tǒng)的，具體來(lái)說(shuō)，js會(huì)根據(jù)任務(wù)的類(lèi)型將其放入不同的隊(duì)列，任務(wù)類(lèi)型有兩種:微任務(wù)、宏任務(wù)。那么其對(duì)應(yīng)的哪些是微任務(wù)、哪些是宏任務(wù)呢？

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

宏任務(wù)：setTimeout()、setInterval()

瀏覽器在執(zhí)行的時(shí)候,先從宏任務(wù)隊(duì)列中取出一個(gè)宏任務(wù)執(zhí)行宏,然后在執(zhí)行該宏任務(wù)下的所有的微任務(wù),這是一個(gè)循環(huán);然后再取出并執(zhí)行下一個(gè)宏任務(wù),再執(zhí)行所有的微任務(wù),這是第二個(gè)循環(huán),以此類(lèi)推.

注意:整個(gè)javascript代碼是第一個(gè)宏任務(wù)

const process = require("process")
setTimeout(function () {// 分發(fā)宏任務(wù)到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 () {// 發(fā)送微任務(wù)
    console.log("3");
});

// 輸出
2
3
1
11
111

在瀏覽器端,在我們執(zhí)行一片script的時(shí)候,當(dāng)遇到同步代碼，依次進(jìn)入執(zhí)行棧，遇到異步代碼，將其掛起，繼續(xù)執(zhí)行其它方法，當(dāng)異步方法執(zhí)行完之后根據(jù)任務(wù)類(lèi)型進(jìn)入到任務(wù)隊(duì)列，在執(zhí)行棧執(zhí)行完，主線(xiàn)程空閑下來(lái)了之后會(huì)到任務(wù)隊(duì)列中取任務(wù)回調(diào)并執(zhí)行。

我自己認(rèn)為Node的事件循環(huán)和瀏覽器端還是有點(diǎn)區(qū)別的，它的事件循環(huán)依靠libuv引擎。

該圖來(lái)自官網(wǎng)，這里展示了在node的事件循環(huán)的6個(gè)階段。

timers:該階段執(zhí)行定時(shí)器的回調(diào),如setTimeout() 和 setInterval()。

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

idle, prepare:內(nèi)部使用

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

check: setImmediate()的回調(diào)會(huì)在這個(gè)階段執(zhí)行

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

對(duì)于我們來(lái)說(shuō)我們更關(guān)注 timer、poll、check這三個(gè)階段即可。

poll 階段有兩個(gè)主要的功能：

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

執(zhí)行timers的callback,當(dāng)?shù)竭_(dá)timers指定的時(shí)間時(shí);

poll 階段的邏輯

如果event loop進(jìn)入了 poll階段，且代碼未設(shè)定timer，將會(huì)發(fā)生下面情況：

a、如果poll queue不為空，event loop將同步的執(zhí)行queue里的callback,直至queue為空，或執(zhí)行的callback到達(dá)系統(tǒng)上限;

b、如果poll queue為空，將會(huì)發(fā)生下面情況：

* 如果代碼已經(jīng)被setImmediate()設(shè)定了callback, event loop將結(jié)束poll階段進(jìn)入check階段，并執(zhí)行check階段的queue (check階段的queue是 setImmediate設(shè)定的)
* 如果代碼沒(méi)有設(shè)定setImmediate(callback)，event loop將阻塞在該階段等待callbacks加入poll queue;

如果event loop進(jìn)入了 poll階段，且代碼設(shè)定了timer：

如果poll queue進(jìn)入空狀態(tài)時(shí)（即poll 階段為空閑狀態(tài)），event loop將檢查timers,

如果有1個(gè)或多個(gè)timers時(shí)間時(shí)間已經(jīng)到達(dá)，event loop將按循環(huán)順序進(jìn)入 timers 階段，并執(zhí)行timer queue

這兩個(gè)函數(shù)的功能還是類(lèi)似的,不同的是他們處于EventLoop的不同階段:timer、check。

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

上面兩行代碼會(huì)輸出順序是什么呢?其實(shí)兩種可能都有.
1.當(dāng)setTimeout的0ms并不能做到絕對(duì)0ms,如果已經(jīng)過(guò)了timer階段,那么此時(shí)setTimeout就會(huì)在下一次循環(huán)中執(zhí)行,也就是說(shuō)先setInterval、再setTimeout。
2.第二種可能就是正常流程了,先timer、再check

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

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

此時(shí)只可能出現(xiàn)一種情況,先setInterval、再setTimeout，因?yàn)樵趇o中已經(jīng)執(zhí)行過(guò)了timer(readFile時(shí)處于IO callback)。
下面一起來(lái)看如下代碼:

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

按照我的理解,它的輸出應(yīng)該是如下:先timer、然后切換階段的時(shí)候執(zhí)行微任務(wù).

// 情況1
timer1
timer2
nextTick1
nextTick2
promise1
promise2

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

// 情況2
timer1
nextTick1
promise1
timer2
nextTick2
promise2

后臺(tái)晚上查資料因?yàn)镹ode11對(duì)EventLoop作了修改,為了和瀏覽器兼容。于是呼我切換到10.8.0,發(fā)現(xiàn)上面兩種情況都有(情況1比例大于情況2)。這點(diǎn)暫時(shí)還未查明什么原因。

node中的6個(gè)階段每個(gè)階段執(zhí)行完都會(huì)伴隨著執(zhí)行微任務(wù),同個(gè)MicroTask隊(duì)列下process.tick()會(huì)優(yōu)于Promise。

本篇主要介紹了瀏覽器和Node對(duì)于事件循環(huán)機(jī)制實(shí)現(xiàn)，由于能力水平有限，其中可能有誤之處歡迎指出。

歡迎關(guān)注公眾號(hào):