深刻瀏覽器事件循環的本質

瀏覽器的事件循環，前端再熟悉不過了，天天都會接觸的東西。但我之前一直都是死記硬背：事件任務隊列分爲macrotask和microtask，瀏覽器先從macrotask取出一個任務執行，再執行microtask內的全部任務，接着又去macrotask取出一個任務執行...，這樣一直循環下去。可是對於下面的代碼，我一直懵逼，setTimeout屬於macrotask，按照上面的規則，setTimeout應該先被取出來執行啊，可是我卻被執行結果打臉了。

<script>
    setTimeout(() => {
        console.log(1)
    }, 0)
    new Promise((resolve) => {
        console.log(2)
        resolve()
    }).then(() => {
        console.log(3)
    })
    // 我曾經的預期是：2 1 3
    // 實際輸出：2 3 1
</script>

通過再仔細看別人對任務隊列的介紹，才知道，同步執行的js代碼其實就算一個macrotask（準確說是每個script標籤內的代碼都是一個macrotask），因此上面的規則中說的 先取出一個macrotask執行 是沒有問題的。
網上不少文章都是像上面這樣解釋的，我也一直認爲這是HTML對事件循環的規範，咱們記着就是。直到最近看了李銀城大佬的文章（見文末的參考連接），我才恍然大悟，以前看的文章都沒有明確地從瀏覽器的多線程模型這個角度分析，因此讓咱們以爲瀏覽器的事件循環是基於上述的約定，但其實這是瀏覽器的多線程模型致使的結果。

macrotask的本質

macrotask本質上是瀏覽器多個線程之間通訊的一個消息隊列
在chrome裏，每一個頁面都對應一個進程，該進程又有多個線程，好比js線程、渲染線程、io線程、網絡線程、定時器線程等，這些線程之間的通訊，是經過向對方的任務隊列中添加一個任務（PostTask）來實現的。

瀏覽器的各類線程都是常駐線程，它們運行在一個for死循環裏面，每一個線程都有屬於本身的若干任務隊列，線程本身或者其它線程均可能經過PostTask向這些任務隊列添加任務，這些線程會不斷地從本身的任務隊列中取出任務執行，或者是處於睡眠狀態直到設定的時間或者是有人PostTask的時候把它們喚醒。

能夠簡單地理解爲，瀏覽器的各個線程都在不停地從本身的任務隊列中取出任務，執行，再取出任務，再執行，這樣無限循環下去。

如下面的代碼爲例：

<script>
    console.log(1)
    setTimeout(() => {
        console.log(2)
    }, 1000)
    console.log(3)
</script>

1. 首先，script標籤中的代碼做爲一個任務放入js線程的任務隊列，js線程被喚醒，而後取出該任務執行
2. 首先執行console.log(1)，而後執行setTimeout，向定時器線程添加一個任務，接着執行console.log(3)，這時js線程的任務隊列爲空，js線程進入休眠
3. 大約1000ms後，定時器線程向js線程的任務隊列添加定時任務（定時器的回調），js線程又被喚醒，執行定時回調函數，最後執行console.log(2)。

能夠看到，所謂的macrotask並非瀏覽器定義了哪些任務是macrotask，瀏覽器各個線程只是忠實地循環本身的任務隊列，不停地執行其中的任務而已。

microtask

比起macrotask是瀏覽器的多線程模型形成的「假象」，microtask是確實存在的一個隊列，microtask是屬於當前線程的，而不是其餘線程PostTask過來的任務，只是延遲執行了而已（準確地說是放到了當前執行的同步代碼以後執行），好比Promise.then、MutationObserver都屬於這種狀況。

如下面的代碼爲例：

<script>
    new Promise((resolve) => {
       resolve()
       console.log(1)
       setTimeout(() => {
         console.log(2)
       },0)
    }).then(() => {
        console.log(3)
    })
    // 輸出：1 3 2
</script>

1. 首先，script標籤中的代碼做爲一個任務放入js線程的任務隊列，js線程被喚醒，而後取出該任務執行
2. 而後執行new Promise以及Promise中的resolve，resolve後，promise的then的回調函數會做爲須要延遲執行的任務，放到當前執行的全部同步代碼以後
3. 接着執行setTimeout，向定時器線程添加一個任務
4. 此時同步代碼執行完畢，接着執行被延遲執行的任務，也就是promise的then的回調函數，即執行console.log(3)
5. 最後，js線程的任務隊列爲空，js線程進入休眠，大約1000ms後，定時器線程向js線程的任務隊列添加定時任務（定時器的回調），js線程又被喚醒，執行定時回調函數，即console.log(2)。

總結

經過上面的分析，能夠看到，文章開頭提到的規則：瀏覽器先從macrotask取出一個任務執行，再執行microtask內的全部任務，接着又去macrotask取出一個任務執行...，並無說錯，但這只是瀏覽器執行機制形成的現象，而不是說瀏覽器按照這樣的規則去執行的代碼。

最後，看了這篇文章，你們可以基於瀏覽器的運行機制，分析出下面代碼的執行結果了嗎（ps：不要用死記硬背的規則去分析喲）

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')
    })
// 執行結果
/*  start
    promise 1
    promise 2
    setInterval
    setTimeout 1
    promise 3
    promise 4
    setInterval
    setTimeout 2
    promise 5
    promise 6
*/

參考

從Chrome源碼看事件循環