關於JavaScript非同步、事件迴圈與消息隊、微任務與巨集任務的總結 ...
本人正在努力學習前端，內容僅供參考。由於各種原因（不喜歡博客園的UI），大家可以移步我的github閱讀體驗更佳：傳送門，喜歡就點個star咯，或者我的博客：https://blog.tangzhengwei.me
前言
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執行過程：
- 主代碼塊（script）依次加入執行棧，依次執行，主代碼塊為：
- console.log('script start')
- setTimeout()
- console.log('click page')
- console.log('script end')
console.log() 為同步代碼，JS引擎線程處理，列印 "script start"，出棧；
遇到非同步函數
setTimeout，交給定時器觸發線程（非同步觸發函數為：setTimeout，回調函數為：() => { ... }），JS引擎線程繼續，出棧；console.log() 為同步代碼，JS引擎線程處理，列印 "click page"，出棧；
console.log() 為同步代碼，JS引擎線程處理，列印 "script end"，出棧；
執行棧為空，也就是JS引擎線程空閑，這時從消息隊列中取出（如果有的話）一條任務（callback）加入執行棧，並執行；
重覆第6步。
（此步的位置不確定）某個時刻（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 overWTF?? "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。
執行機制：
執行一個巨集任務（棧中沒有就從事件隊列中獲取）
執行過程中如果遇到微任務，就將它添加到微任務的任務隊列中
巨集任務執行完畢後，立即執行當前微任務隊列中的所有微任務（依次執行）
當前巨集任務執行完畢，開始檢查渲染，然後GUI線程接管渲染
渲染完畢後，JS引擎線程繼續，開始下一個巨集任務（從巨集任務隊列中獲取）
總結
JavaScript 是單線程語言，決定於它的設計最初是用來處理瀏覽器網頁的交互。瀏覽器負責解釋和執行 JavaScript 的線程只有一個（所有說是單線程），即JS引擎線程，但是瀏覽器同樣提供其他線程，如：事件觸發線程、定時器觸發線程等。
- 非同步一般是指：
- 網路請求
- 計時器
- DOM事件監聽
- 事件迴圈機制：
- JS引擎線程會維護一個執行棧，同步代碼會依次加入到執行棧中依次執行並出棧。
- JS引擎線程遇到非同步函數，會將非同步函數交給相應的Webapi，而繼續執行後面的任務。
- Webapi會在條件滿足的時候，將非同步對應的回調加入到消息隊列中，等待執行。
- 執行棧為空時，JS引擎線程會去取消息隊列中的回調函數（如果有的話），並加入到執行棧中執行。
- 完成後出棧，執行棧再次為空，重覆上面的操作，這就是事件迴圈(event loop)機制。
參考：
