摘要：單線程異步非阻塞然后，這又牽扯到了事件循環消息隊列，還有微任務宏任務這些。此步的位置不確定某個時刻后，定時器觸發線程通知事件觸發線程，事件觸發線程將回調函數加入消息隊列隊尾，等待引擎線程執行。

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 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。

執行機制：

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

執行過程中如果遇到微任務，就將它添加到微任務的任務隊列中

宏任務執行完畢后，立即執行當前微任務隊列中的所有微任務（依次執行）

當前宏任務執行完畢，開始檢查渲染，然后GUI線程接管渲染

渲染完畢后，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