總結：JavaScript異步、事件循環與消息隊列、微任務與宏任務

前言

原文

Philip Roberts 在演講 great talk at JSConf on the event loop 中說：要是用一句話來形容 JavaScript，我可能會這樣：

「JavaScript 是單線程、異步、非阻塞、解釋型腳本語言。」

• 單線程 ?
• 異步 ? ?
• 非阻塞 ? ? ?

而後，這又牽扯到了事件循環、消息隊列，還有微任務、宏任務這些。

做爲一個初學者，對這些瞭解甚少。

這幾天翻閱了很多資料，彷佛瞭解到了一二，是時候總結一下了，它們困擾了我好一段時間，就像學高數那會兒本身去理解一個概念同樣。

單線程與多線程

單線程語言：JavaScript 的設計就是爲了處理瀏覽器網頁的交互（DOM操做的處理、UI動畫等），決定了它是一門單線程語言。

若是有多個線程，它們同時在操做 DOM，那網頁將會一團糟。

JavaScript 是單線程的，那麼處理任務是一件接着一件處理，從上往下順序執行：

console.log('script start')
console.log('do something...')
console.log('script end')

// script start
// do something...
// script end
複製代碼

上面的代碼會依次打印: "script start" >> "do something..." >> "script end"

那若是一個任務的處理耗時（或者是等待）好久的話，如：網絡請求、定時器、等待鼠標點擊等，後面的任務也就會被阻塞，也就是說會阻塞全部的用戶交互（按鈕、滾動條等），會帶來極不友好的體驗。

可是：

console.log('script start')

console.log('do something...')

setTimeout(() => {
  console.log('timer over')
}, 1000)

// 點擊頁面
console.log('click page')

console.log('script end')

// script start
// do something...
// click page
// script end
// timer over
複製代碼

"timer over" 在 "script end" 後再打印，也就是說計時器並無阻塞後面的代碼。那，發生了什麼？

其實，JavaScript 單線程指的是瀏覽器中負責解釋和執行 JavaScript 代碼的只有一個線程，即爲JS引擎線程，可是瀏覽器的渲染進程是提供多個線程的，以下：

• JS引擎線程
• 事件觸發線程
• 定時觸發器線程
• 異步http請求線程
• GUI渲染線程

瀏覽器渲染進程參考這裏

當遇到計時器、DOM事件監聽或者是網絡請求的任務時，JS引擎會將它們直接交給 webapi，也就是瀏覽器提供的相應線程（如定時器線程爲setTimeout計時、異步http請求線程處理網絡請求）去處理，而JS引擎線程繼續後面的其餘任務，這樣便實現了 異步非阻塞。

定時器觸發線程也只是爲 setTimeout(..., 1000) 定時而已，時間一到，還會把它對應的回調函數(callback)交給 消息隊列 去維護，JS引擎線程會在適當的時候去消息隊列取出消息並執行。

JS引擎線程何時去處理呢？消息隊列又是什麼？

這裏，JavaScript 經過 事件循環 event loop 的機制來解決這個問題。

這個放在後面再討論吧！

同步與異步

上面說到了異步，JavaScript 中有同步代碼與異步代碼。

下面即是同步：

console.log('hello 0')

console.log('hello 1')

console.log('hello 2')

// hello 0
// hello 1
// hello 2
複製代碼

它們會依次執行，執行完了後便會返回結果（打印結果）。

setTimeout(() => {
  console.log('hello 0')
}, 1000)

console.log('hello 1')

// hello 1
// hello 0
複製代碼

上面的 setTimeout 函數便不會馬上返回結果，而是發起了一個異步，setTimeout 即是異步的發起函數或者是註冊函數，() => {...} 即是異步的回調函數。

這裏，JS引擎線程只會關心異步的發起函數是誰、回調函數是什麼？並將異步交給 webapi 去處理，而後繼續執行其餘任務。

異步通常是如下：

• 網絡請求
• 計時器
• DOM時間監聽
• ...

事件循環與消息隊列

回到事件循環 event loop

其實 事件循環 機制和 消息隊列 的維護是由事件觸發線程控制的。

事件觸發線程 一樣是瀏覽器渲染引擎提供的，它會維護一個 消息隊列。

JS引擎線程遇到異步（DOM事件監聽、網絡請求、setTimeout計時器等...），會交給相應的線程單獨去維護異步任務，等待某個時機（計時器結束、網絡請求成功、用戶點擊DOM），而後由 事件觸發線程 將異步對應的 回調函數 加入到消息隊列中，消息隊列中的回調函數等待被執行。

同時，JS引擎線程會維護一個 執行棧，同步代碼會依次加入執行棧而後執行，結束會退出執行棧。

若是執行棧裏的任務執行完成，即執行棧爲空的時候（即JS引擎線程空閒），事件觸發線程纔會從消息隊列取出一個任務（即異步的回調函數）放入執行棧中執行。

消息隊列是相似隊列的數據結構，遵循先入先出(FIFO)的規則。

執行完了後，執行棧再次爲空，事件觸發線程會重複上一步操做，再取出一個消息隊列中的任務，這種機制就被稱爲事件循環（event loop）機制。

仍是上面的代碼：

console.log('script start')

setTimeout(() => {
  console.log('timer over')
}, 1000)

// 點擊頁面
console.log('click page')

console.log('script end')

// script start
// click page
// script end
// timer over
複製代碼

執行過程：

1. 主代碼塊（script）依次加入執行棧，依次執行，主代碼塊爲：

   • console.log('script start')
   • setTimeout()
   • console.log('click page')
   • console.log('script end')

2. console.log() 爲同步代碼，JS引擎線程處理，打印 "script start"，出棧；

3. 遇到異步函數 setTimeout，交給定時器觸發線程（異步觸發函數爲：setTimeout，回調函數爲：() => { ... }），JS引擎線程繼續，出棧；

4. console.log() 爲同步代碼，JS引擎線程處理，打印 "click page"，出棧；

5. console.log() 爲同步代碼，JS引擎線程處理，打印 "script end"，出棧；

6. 執行棧爲空，也就是JS引擎線程空閒，這時從消息隊列中取出（若是有的話）一條任務（callback）加入執行棧，並執行；

7. 重複第6步。

8. （此步的位置不肯定）某個時刻（1000ms後），定時器觸發線程通知事件觸發線程，事件觸發線程將回調函數 () => { ... } 加入消息隊列隊尾，等待JS引擎線程執行。

能夠看出，setTimeout異步函數對應的回調函數( () => {} )會在執行棧爲空，主代碼塊執行完了後纔會執行。

零延時：

console.log('script start')

setTimeout(() => {
  console.log('timer 1 over')
}, 1000)

setTimeout(() => {
  console.log('timer 2 over')
}, 0)

console.log('script end')

// script start
// script end
// timer 2 over
// timer 1 over
複製代碼

這裏會先打印 "timer 2 over"，而後打印 "timer 1 over"，儘管 timer 1 先被定時器觸發線程處理，可是 timer 2 的callback會先加入消息隊列。

上面，timer 2 的延時爲 0ms，HTML5標準規定 setTimeout 第二個參數不得小於4（不一樣瀏覽器最小值會不同），不足會自動增長，因此 "timer 2 over" 仍是會在 "script end" 以後。

就算延時爲 0ms，只是 timer 2 的回調函數會當即加入消息隊列而已，回調的執行仍是得等執行棧爲空（JS引擎線程空閒）時執行。

其實 setTimeout 的第二個參數並不能表明回調執行的準確的延時事件，它只能表示回調執行的最小延時時間，由於回調函數進入消息隊列後須要等待執行棧中的同步任務執行完成，執行棧爲空時纔會被執行。

宏任務與微任務

以上機制在ES5的狀況下夠用了，可是ES6會有一些問題。

Promise一樣是用來處理異步的：

console.log('script start')

setTimeout(function() {
    console.log('timer over')
}, 0)

Promise.resolve().then(function() {
    console.log('promise1')
}).then(function() {
    console.log('promise2')
})

console.log('script end')

// script start
// script end
// promise1
// promise2
// timer over
複製代碼

WTF?? "promise 1" "promise 2" 在 "timer over" 以前打印了？

這裏有一個新概念：macrotask（宏任務） 和 microtask（微任務）。

全部任務分爲 macrotask 和 microtask:

• macrotask：主代碼塊、setTimeout、setInterval等（能夠看到，事件隊列中的每個事件都是一個 macrotask，如今稱之爲宏任務隊列）

• microtask：Promise、process.nextTick等

JS引擎線程首先執行主代碼塊。

每次執行棧執行的代碼就是一個宏任務，包括任務隊列(宏任務隊列)中的，由於執行棧中的宏任務執行完會去取任務隊列（宏任務隊列）中的任務加入執行棧中，即一樣是事件循環的機制。

在執行宏任務時遇到Promise等，會建立微任務（.then()裏面的回調），並加入到微任務隊列隊尾。

microtask必然是在某個宏任務執行的時候建立的，而在下一個宏任務開始以前，瀏覽器會對頁面從新渲染(task >> 渲染 >> 下一個task(從任務隊列中取一個))。同時，在上一個宏任務執行完成後，渲染頁面以前，會執行當前微任務隊列中的全部微任務。

也就是說，在某一個macrotask執行完後，在從新渲染與開始下一個宏任務以前，就會將在它執行期間產生的全部microtask都執行完畢（在渲染前）。

這樣就能夠解釋 "promise 1" "promise 2" 在 "timer over" 以前打印了。"promise 1" "promise 2" 作爲微任務加入到微任務隊列中，而 "timer over" 作爲宏任務加入到宏任務隊列中，它們同時在等待被執行，可是微任務隊列中的全部微任務都會在開始下一個宏任務以前都被執行完。

在node環境下，process.nextTick的優先級高於Promise，也就是說：在宏任務結束後會先執行微任務隊列中的nextTickQueue，而後纔會執行微任務中的Promise。

執行機制：

1. 執行一個宏任務（棧中沒有就從事件隊列中獲取）

2. 執行過程當中若是遇到微任務，就將它添加到微任務的任務隊列中

3. 宏任務執行完畢後，當即執行當前微任務隊列中的全部微任務（依次執行）

4. 當前宏任務執行完畢，開始檢查渲染，而後GUI線程接管渲染

5. 渲染完畢後，JS引擎線程繼續，開始下一個宏任務（從宏任務隊列中獲取）

總結

• JavaScript 是單線程語言，決定於它的設計最初是用來處理瀏覽器網頁的交互。瀏覽器負責解釋和執行 JavaScript 的線程只有一個（全部說是單線程），即JS引擎線程，可是瀏覽器一樣提供其餘線程，如：事件觸發線程、定時器觸發線程等。

• 異步通常是指：

  • 網絡請求
  • 計時器
  • DOM事件監聽

• 事件循環機制：

  • JS引擎線程會維護一個執行棧，同步代碼會依次加入到執行棧中依次執行並出棧。
  • JS引擎線程遇到異步函數，會將異步函數交給相應的Webapi，而繼續執行後面的任務。
  • Webapi會在條件知足的時候，將異步對應的回調加入到消息隊列中，等待執行。
  • 執行棧爲空時，JS引擎線程會去取消息隊列中的回調函數（若是有的話），並加入到執行棧中執行。
  • 完成後出棧，執行棧再次爲空，重複上面的操做，這就是事件循環(event loop)機制。

---

原文連接

參考：

• Tasks, microtasks, queues and schedules

• great talk at JSConf on the event loop

• 併發模型與事件循環 - JavaScript | MDN

• 從瀏覽器多進程到JS單線程，JS運行... - 掘金

• 瀏覽器篇-Event-Loop.md - PDKSophia/blog.io