瀏覽器的事件循環,前端再熟悉不過了,每天都會接觸的東西。但我以前一直都是死記硬背:事件任務隊列分爲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>
- 首先,script標籤中的代碼作爲一個任務放入js線程的任務隊列,js線程被喚醒,然後取出該任務執行
- 首先執行
console.log(1)
,然後執行setTimeout
,向定時器線程添加一個任務,接着執行console.log(3)
,這時js線程的任務隊列爲空,js線程進入休眠 - 大約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>
- 首先,script標籤中的代碼作爲一個任務放入js線程的任務隊列,js線程被喚醒,然後取出該任務執行
- 然後執行
new Promise
以及Promise中的resolve
,resolve後,promise的then的回調函數會作爲需要延遲執行的任務,放到當前執行的所有同步代碼之後 - 接着執行
setTimeout
,向定時器線程添加一個任務 - 此時同步代碼執行完畢,接着執行被延遲執行的任務,也就是promise的then的回調函數,即執行
console.log(3)
- 最後,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
*/