摘要:瀏覽器的事件循環,前端再熟悉不過了,每天都會接觸的東西。可以看到,所謂的并不是瀏覽器定義了哪些任務是,瀏覽器各個線程只是忠實地循環自己的任務隊列,不停地執行其中的任務而已。
瀏覽器的事件循環,前端再熟悉不過了,每天都會接觸的東西。但我以前一直都是死記硬背:事件任務隊列分為macrotask和microtask,瀏覽器先從macrotask取出一個任務執行,再執行microtask內的所有任務,接著又去macrotask取出一個任務執行...,這樣一直循環下去。但是對于下面的代碼,我一直懵逼,setTimeout屬于macrotask,按照上面的規則,setTimeout應該先被取出來執行啊,但是我卻被執行結果打臉了。
經過再仔細看別人對任務隊列的介紹,才知道,同步執行的js代碼其實就算一個macrotask(準確說是每一個script標簽內的代碼都是一個macrotask),所以上面的規則中說的 先取出一個macrotask執行 是沒有問題的。
網上很多文章都是像上面這樣解釋的,我也一直認為這是HTML對事件循環的規范,我們記著就是。直到最近看了李銀城大佬的文章(見文末的參考鏈接),我才恍然大悟,之前看的文章都沒有明確地從瀏覽器的多線程模型這個角度分析,所以讓我們覺得瀏覽器的事件循環是基于上述的約定,但其實這是瀏覽器的多線程模型導致的結果。
macrotask本質上是瀏覽器多個線程之間通信的一個消息隊列
在chrome里,每個頁面都對應一個進程,該進程又有多個線程,比如js線程、渲染線程、io線程、網絡線程、定時器線程等,這些線程之間的通信,是通過向對方的任務隊列中添加一個任務(PostTask)來實現的。
瀏覽器的各種線程都是常駐線程,它們運行在一個for死循環里面,每個線程都有屬于自己的若干任務隊列,線程自己或者其它線程都可能通過PostTask向這些任務隊列添加任務,這些線程會不斷地從自己的任務隊列中取出任務執行,或者是處于睡眠狀態直到設定的時間或者是有人PostTask的時候把它們喚醒。
可以簡單地理解為,瀏覽器的各個線程都在不停地從自己的任務隊列中取出任務,執行,再取出任務,再執行,這樣無限循環下去。
以下面的代碼為例:
首先,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標簽中的代碼作為一個任務放入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 */參考
從Chrome源碼看事件循環
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/99112.html
摘要:換句話說當一個異步過程調用發出后,調用者不會立刻得到結果,而是調用發出后,被調用者通過狀態通知或回調函數處理這個調用。 JavaScript單線程機制 JavaScript的一個語言特性(也是這門語言的核心)就是單線程。什么是單線程呢?簡單地說就是同一時間只能做一件事,當有多個任務時,只能按照一個順序一個完成了再執行下一個 為什么JS是單線程的呢? JS最初被設計用在瀏覽器中,作為...
摘要:圖片轉引自的演講和兩個定時器中回調的執行邏輯便是典型的機制。異步編程關于異步編程我的理解是,在執行環境所提供的異步機制之上,在應用編碼層面上實現整體流程控制的異步風格。 問題背景 在一次開發任務中,需要實現如下一個餅狀圖動畫,基于canvas進行繪圖,但由于對于JS運行環境中異步機制的不了解,所以遇到了一個棘手的問題,始終無法解決,之后在與同事交流之后才恍然大悟。問題的根節在于經典的J...
摘要:提出標準,允許腳本創建多個線程,但是子線程完全受主線程控制,且不得操作。所以,這個新標準并沒有改變單線程的本質。事件循環主線程線程只會做一件事,就是從消息隊列里面取消息執行消息,再取消息再執行。工作線程是生產者,主線程是消費者。 最近項目中遇到了一個場景,其實很常見,就是定時獲取接口刷新數據。那么問題來了,假設我設置的定時時間為1s,而數據接口返回大于1s,應該用同步阻塞還是異步?我們...
閱讀 1217·2019-08-30 15:55
閱讀 964·2019-08-30 15:55
閱讀 2164·2019-08-30 15:44
閱讀 2895·2019-08-29 14:17
閱讀 1141·2019-08-29 12:45
閱讀 3316·2019-08-26 10:48
閱讀 3144·2019-08-23 18:18
閱讀 2614·2019-08-23 16:47