前言
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)機制。
參考：