摘要：瀏覽器的事件循環(huán)，前端再熟悉不過了，每天都會(huì)接觸的東西。可以看到，所謂的并不是瀏覽器定義了哪些任務(wù)是，瀏覽器各個(gè)線程只是忠實(shí)地循環(huán)自己的任務(wù)隊(duì)列，不停地執(zhí)行其中的任務(wù)而已。

瀏覽器的事件循環(huán)，前端再熟悉不過了，每天都會(huì)接觸的東西。但我以前一直都是死記硬背：事件任務(wù)隊(duì)列分為macrotask和microtask，瀏覽器先從macrotask取出一個(gè)任務(wù)執(zhí)行，再執(zhí)行microtask內(nèi)的所有任務(wù)，接著又去macrotask取出一個(gè)任務(wù)執(zhí)行...，這樣一直循環(huán)下去。但是對(duì)于下面的代碼，我一直懵逼，setTimeout屬于macrotask，按照上面的規(guī)則，setTimeout應(yīng)該先被取出來執(zhí)行啊，但是我卻被執(zhí)行結(jié)果打臉了。

經(jīng)過再仔細(xì)看別人對(duì)任務(wù)隊(duì)列的介紹，才知道，同步執(zhí)行的js代碼其實(shí)就算一個(gè)macrotask（準(zhǔn)確說是每一個(gè)script標(biāo)簽內(nèi)的代碼都是一個(gè)macrotask），所以上面的規(guī)則中說的 先取出一個(gè)macrotask執(zhí)行 是沒有問題的。
網(wǎng)上很多文章都是像上面這樣解釋的，我也一直認(rèn)為這是HTML對(duì)事件循環(huán)的規(guī)范，我們記著就是。直到最近看了李銀城大佬的文章（見文末的參考鏈接），我才恍然大悟，之前看的文章都沒有明確地從瀏覽器的多線程模型這個(gè)角度分析，所以讓我們覺得瀏覽器的事件循環(huán)是基于上述的約定，但其實(shí)這是瀏覽器的多線程模型導(dǎo)致的結(jié)果。

macrotask本質(zhì)上是瀏覽器多個(gè)線程之間通信的一個(gè)消息隊(duì)列
在chrome里，每個(gè)頁(yè)面都對(duì)應(yīng)一個(gè)進(jìn)程，該進(jìn)程又有多個(gè)線程，比如js線程、渲染線程、io線程、網(wǎng)絡(luò)線程、定時(shí)器線程等，這些線程之間的通信，是通過向?qū)Ψ降娜蝿?wù)隊(duì)列中添加一個(gè)任務(wù)（PostTask）來實(shí)現(xiàn)的。

瀏覽器的各種線程都是常駐線程，它們運(yùn)行在一個(gè)for死循環(huán)里面，每個(gè)線程都有屬于自己的若干任務(wù)隊(duì)列，線程自己或者其它線程都可能通過PostTask向這些任務(wù)隊(duì)列添加任務(wù)，這些線程會(huì)不斷地從自己的任務(wù)隊(duì)列中取出任務(wù)執(zhí)行，或者是處于睡眠狀態(tài)直到設(shè)定的時(shí)間或者是有人PostTask的時(shí)候把它們喚醒。

可以簡(jiǎn)單地理解為，瀏覽器的各個(gè)線程都在不停地從自己的任務(wù)隊(duì)列中取出任務(wù)，執(zhí)行，再取出任務(wù)，再執(zhí)行，這樣無限循環(huán)下去。

以下面的代碼為例：

首先，script標(biāo)簽中的代碼作為一個(gè)任務(wù)放入js線程的任務(wù)隊(duì)列，js線程被喚醒，然后取出該任務(wù)執(zhí)行

首先執(zhí)行console.log(1)，然后執(zhí)行setTimeout，向定時(shí)器線程添加一個(gè)任務(wù)，接著執(zhí)行console.log(3)，這時(shí)js線程的任務(wù)隊(duì)列為空，js線程進(jìn)入休眠

大約1000ms后，定時(shí)器線程向js線程的任務(wù)隊(duì)列添加定時(shí)任務(wù)（定時(shí)器的回調(diào)），js線程又被喚醒，執(zhí)行定時(shí)回調(diào)函數(shù)，最后執(zhí)行console.log(2)。

可以看到，所謂的macrotask并不是瀏覽器定義了哪些任務(wù)是macrotask，瀏覽器各個(gè)線程只是忠實(shí)地循環(huán)自己的任務(wù)隊(duì)列，不停地執(zhí)行其中的任務(wù)而已。

比起macrotask是瀏覽器的多線程模型造成的“假象”，microtask是確實(shí)存在的一個(gè)隊(duì)列，microtask是屬于當(dāng)前線程的，而不是其他線程PostTask過來的任務(wù)，只是延遲執(zhí)行了而已（準(zhǔn)確地說是放到了當(dāng)前執(zhí)行的同步代碼之后執(zhí)行），比如Promise.then、MutationObserver都屬于這種情況。

以下面的代碼為例：

首先，script標(biāo)簽中的代碼作為一個(gè)任務(wù)放入js線程的任務(wù)隊(duì)列，js線程被喚醒，然后取出該任務(wù)執(zhí)行

然后執(zhí)行new Promise以及Promise中的resolve，resolve后，promise的then的回調(diào)函數(shù)會(huì)作為需要延遲執(zhí)行的任務(wù)，放到當(dāng)前執(zhí)行的所有同步代碼之后

接著執(zhí)行setTimeout，向定時(shí)器線程添加一個(gè)任務(wù)

此時(shí)同步代碼執(zhí)行完畢，接著執(zhí)行被延遲執(zhí)行的任務(wù)，也就是promise的then的回調(diào)函數(shù)，即執(zhí)行console.log(3)

最后，js線程的任務(wù)隊(duì)列為空，js線程進(jìn)入休眠，大約1000ms后，定時(shí)器線程向js線程的任務(wù)隊(duì)列添加定時(shí)任務(wù)（定時(shí)器的回調(diào)），js線程又被喚醒，執(zhí)行定時(shí)回調(diào)函數(shù)，即console.log(2)。

通過上面的分析，可以看到，文章開頭提到的規(guī)則：瀏覽器先從macrotask取出一個(gè)任務(wù)執(zhí)行，再執(zhí)行microtask內(nèi)的所有任務(wù)，接著又去macrotask取出一個(gè)任務(wù)執(zhí)行...，并沒有說錯(cuò)，但這只是瀏覽器執(zhí)行機(jī)制造成的現(xiàn)象，而不是說瀏覽器按照這樣的規(guī)則去執(zhí)行的代碼。

最后，看了這篇文章，大家能夠基于瀏覽器的運(yùn)行機(jī)制，分析出下面代碼的執(zhí)行結(jié)果了嗎（ps：不要用死記硬背的規(guī)則去分析喲）

console.log("start")

const interval = setInterval(() => {  
  console.log("setInterval")
}, 0)

setTimeout(() => {  
  console.log("setTimeout 1")
  Promise.resolve()
      .then(() => {
        console.log("promise 3")
      })
      .then(() => {
        console.log("promise 4")
      })
      .then(() => {
        setTimeout(() => {
          console.log("setTimeout 2")
          Promise.resolve()
              .then(() => {
                console.log("promise 5")
              })
              .then(() => {
                console.log("promise 6")
              })
              .then(() => {
                clearInterval(interval)
              })
        }, 0)
      })
}, 0)

Promise.resolve()
    .then(() => {  
        console.log("promise 1")
    })
    .then(() => {
        console.log("promise 2")
    })
// 執(zhí)行結(jié)果
/*  start
    promise 1
    promise 2
    setInterval
    setTimeout 1
    promise 3
    promise 4
    setInterval
    setTimeout 2
    promise 5
    promise 6
*/

從Chrome源碼看事件循環(huán)