瀏覽器事件循環的深入了解（程式碼範例）

這篇文章帶給大家的內容是關於瀏覽器事件循環的深入了解（程式碼範例），有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。

瀏覽器的事件循環，前端再熟悉不過了，每天都會接觸的東西。但我以前一直都是死記硬背：事件任務隊列分為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
*/

以上是瀏覽器事件循環的深入了解（程式碼範例）的詳細內容。更多資訊請關注PHP中文網其他相關文章！