JavaScript 中的异步：Event Loop 及其他

写作时间

2016-09-30

异步

简单地说，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");
})
.then(() => {return console.log("C - Promise 2");
});console.log("AA");

在原生支持 Promise 的环境，输出是这样：

A
AA
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，是一个独立的线程，有自己的内存空间（栈、堆）以及 Event Loop Queue。要与这样的不同的线程通信，只能通过 postMessage。一次 postMessage 就是在另一个线程的 Event Loop Queue 中加入一条消息。

而一个跨域的 iframe 中，JavaScript 也有单独的内存空间（栈、堆）以及 Event Loop Queue，也只能通过 postMessage 与它通信。至于它与主页面是否运行在同一线程内，取决于浏览器的实现（目前是在同一线程内）。

参考资料

Concurrency model and Event Loop
ECMAScript® 2015 Language Specification
You Don't Know JS: Async & Performance
JavaScript异步编程：设计快速响应的网络应用