異步

簡單地說，JavaScript 是單線程執行的語言，但在使用中有很多異步執行的情況。異步的本質是用其他方式（相對同步）控制程序的執行順序，這與其他語言中的多線程模型不同，所以常常有人對非順序 JavaScript 代碼的運行結果感到困惑不解。

一段簡單的小程序

任何使用過 JavaScript 的程序員都能說出下面這段代碼的輸出：

console.log("A");

setTimeout(() => {
  console.log("B");
}, 100);

console.log("C");

先後順序是 A、C、B，因為第二個參數的作用是指定延遲的毫秒數，這段代碼只有一個 setTimeout，所以不會讓人迷惑。

對類似程序的解釋通常是由 setTimeout 設置一個定時器，在指定毫秒數後調用回調函數。然而，它的執行機制並不是這麼簡單。實際上，setTimeout 的作用是在指定的毫秒數之後，在得到機會時，將 callback 放入 Event Loop Queue。

Event Loop

首先要拋出一些概念，通常所說的 JavaScript Engine 是指負責執行一個一個 chunk 的程序，它依賴宿主環境的調度，也需要通過宿主環境與操作系統產生關聯並得到支持。JavaScript Engine 是 JavaScript Runtime(Hosting Environment) 的一部分。

每個 chunk 通常是以 function 為單位，一個 chunk 執行完成後，才會執行下一個 chunk。下一個 chunk 是什麼呢？取決於當前 Event Loop Queue 中的隊首。Event Loop Queue 中存放的都是消息，每個消息關聯着一個函數，JavaScript Engine 就按照隊列中的消息順序執行它們，也就是執行 chunk。

所以上面的 setTimeout 實際執行起來更接近這樣：

chunk1執行：由 setTimeout 啟動定時器（100毫秒）
chunk2執行：得到機會，將 callback 放入 Event Loop Queue
chunk3執行：此 callback 執行

不難發現，得到機會很重要！這也就可以解釋用 setTimeout 延遲 1000 不一定是準確的，而是會至少延遲一秒。因為如果還有其他的任務在前面，它要等待那些任務對應的消息都出隊，也就是程序都執行完成，它才能將 callback 放入隊列。也就是實際延遲會大於或等於一秒。

通常所說的觸發了一個事件，就是指這個 event listener 得到了執行。與 setTimeout 這個例子中的概念一樣，這也是一次 chunk 的執行。像這樣一個一個執行 chunk 的過程就叫 Event Loop。

還有一個經常提到的概念叫「無阻塞」，JavaScript 中的無阻塞就是指這種 Event Loop 模型。除去 alert 或同步 Ajax 請求等歷史原因造成的問題，程序總是不會出現阻塞；也就是說 JavaScript Engine 總是可以處理下一個任務，如處理用戶對瀏覽器的操作。

一些簡單的小例子

將 setTimeout 加入 try 語句之中，結果會如何？

try {
  setTimeout(() => {
    throw new Error("Error - from try statement");
  }, 0);
} catch (e) {
  console.error(e);
}

try catch 與 setTimeout 不在同一個 chunk，所以……你懂的。

再看下一個。

下面的堆棧信息會輸出 C – B – A 嗎？

setTimeout(function A() {
  setTimeout(function B() {
    setTimeout(function C() {
      throw new Error("Error - from function C");
    }, 0);
  }, 0);
}, 0);

它們並不對應同一條 Event Loop Queue 中的消息，分別有各自的調用棧，所以錯誤棧裏面只有 C。

Job Queue

Job 是 ES6 中新增的概念，它與 Promise 的執行有關，可以理解為等待執行的任務；Job Queue 就是這種類型的任務的隊列。JavaScript Runtime 對於 Job Queue 與 Event Loop Queue 的處理有所不同。

相同點：

都用作先進先出隊列

相異點：

每個 JavaScript Runtime 可以有多個 Job Queue，但只有一個 Event Loop Queue
當 JavaScript Engine 處理完當前 chunk 後，優先執行所有的 Job Queue，然後再處理 Event Loop Queue

ES6 中，一個 Promise 就是一個 PromiseJob，一種 Job。

再來觀察一段小程序：

console.log("A");

setTimeout(() => {
  console.log("A - setTimeout");
}, 0);

new Promise((resolve) => {
  resolve();
})
.then(() => {
  return console.log("A - Promise 1");
})
.then(() => {
  return console.log("B - Promise 1");
});

new Promise((resolve) => {
  resolve();
})
.then(() => {
  return console.log("A - Promise 2");
})
.then(() => {
  return console.log("B - Promise 2");
})
.t**粗體文字**hen(() => {
  return console.log("C - Promise 2");
});

console.log("AA");

在原生支持 Promise 的環境，輸出是這樣：

A – Promise 1

A – Promise 2

B – Promise 1

B – Promise 2

C – Promise 2

A – setTimeout

理解這個輸出：

A 與 AA 最先輸出，因為它們不是異步任務，屬於第一個 chunk。
Promise 1 與 Promise 2 先於 setTimeout 執行，因為 Job Queue 的執行優先於 Event Loop Queue。
Promise 1 與 Promise 2 各自的輸出都是順序的，因為 Job Queue 是先進先出隊列，同一 Job Queue 中的任務順序執行。
Promise 1 與 Promise 2 的後續任務是交錯的，因為 Promise 1 與 Promise 2 都是獨立的 PromiseJob（job 的其中一種），屬於不同的 Job Queue，它們之間的順序規範中沒有規定。

並發

文章開頭，我說「簡單地說，JavaScript 是單線程執行的語言」，現在可以說得稍微複雜一點了：JavaScript Engine 對 JavaScript 程序的執行是單線程的，但是 JavaScript Runtime（整個宿主環境）並不是單線程的；而且，幾乎所有的異步任務都是並發的，例如多個 Job Queue、Ajax、Timer、I/O(Node)等等。

上面說的是 JavaScript Runtime 層面，JavaScript 執行本身，也有一些特殊情況，例如：一個 Web Worker 或者一個跨域的 iframe，也是獨立的線程，有各自的內存空間（棧、堆）以及 Event Loop Queue。要與這些不同的線程通信，只能通過 postMessage。一次 postMessage 就是在另一個線程的 Event Loop Queue 中加入一條消息。