v8是怎么实现更快的 await ？

点击上方“IT平头哥联盟”，选择“置顶或者星标”

一起进步～

作者：Edvard

最近 v8团队发表一篇博客Faster async functions and promises， 预计在 v7.2版本实现更快的异步函数和 promise。

文章内容看起来不是很容易理解，背后的原理比较隐蔽，不过博客提到的一些ECMAScript 标准文档中的操作、任务，实际上都有已经实现的 built-inapi， 因此我们可以借助我们比较熟悉的语法、api 来理解其中的原理，

也许本文有些说法不够准确，欢迎纠正

Example

首先看下博客开篇提到的代码：

1. const p = Promise.resolve();

2. (async () => {

3. await p;

4. console.log("after:await");

5. })();

6. p.then(() => {

7. console.log("tick:a");

8. }).then(() => {

9. console.log("tick:b");

10. });

以 node v10 的执行结果为准， node v8 的实现是不符合ECMAScript 标准

优秀的程序员总是能以简单的例子解释复杂的原理。代码很简单，但是执行结果可能出乎很多人意料:

1. tick:a

2. tick:b

3. after:await

如果你已经猜对了，本文的关键内容你已经掌握，不用往下看了:)。

为什么 after:await会出现在 tick:a之后，甚至是 tick:b之后？ 要理解其中的原理，我们可以做一个小实验。

将 await 翻译成 promise

v8博客中是以伪代码的方式解释 await的执行逻辑:

我们可以用 promise语法写成：

1. function foo2(v) {

2. const implicit_promise = new Promise(resolve => {

3. const promise = new Promise(res => res(v));

4. promise.then(w => resolve(w));

5. });

6. return implicit_promise;

7. }

按照同样的方式，可以将文章开头的代码转换成:

1. const p = Promise.resolve();

2. (() => {

3. const implicit_promise = new Promise(resolve => {

4. const promise = new Promise(res => res(p));

5. promise.then(() => {

6. console.log("after:await");

7. resolve();

8. });

9. });

10. return implicit_promise;

11. })();

12. p.then(() => {

13. console.log("tick:a");

14. }).then(() => {

15. console.log("tick:b");

16. });

经过一些琐碎的调试，发现问题真正的关键代码是这一句： constpromise=newPromise(res=>res(p));

Resolved with another promise

了解 Node.js 或浏览器的事件循环的童鞋都知道，resolved promise 的回调函数（reaction）是放在一个单独的队列 MicroTaskQueue中。 这个队列会在事件循环的阶段结束的时候被执行，只有当这个队列被清空后，才能进入事件循环的下一个阶段。

我们知道一个 promise 的 .then 回调的返回值可以是一个任意值，也可以是另外一个 promise。 但是后者的处理逻辑可能有点反直觉。

在深入之前，我们简单说一下 promise 的几种状态:

• 我们说一个 promise 是 resolved 的，表示它不能被再次 fulfill 或 reject， 要么是被 fulfill，要么被 reject（这两种情况，promise 均有一个确定的 non-promise result）， 要么遵循另外一个 promise（随之 fulfill 或 reject）

• 我们说一个 promise 是 unresolved 的，表示它尚未被 resolve

当一个 promise（假设叫 promiseA。方便引用） 被 resolve，并且去遵循另外一个 promise（叫 p） 时，执行逻辑和前面两种 resolve 情况非常不同，用伪代码表示则是：

1. addToMicroTaskQueue(() => { // 任务A

2. // 使用 .then 方法，将 promiseA 的状态 和 p 绑定

3. p.then(

4. resolvePromiseA, // 任务B

5. rejectPromiseA

6. );

7. });

我们一步一步来分析：

1. 首先，我们在 MicroTaskQueue添加任务A，该任务在 ECMAScript 标准 中被定义为 PromiseResolveThenableJob

2. 任务A，主要目的是使 promiseA 遵循 p 的状态，将两者的状态关联起来。

3. 由于我们例子中 p 已经是 resolved(状态为fulfilled)的，所以立即将 resolvePromiseA任务B 添加到 MicroTaskQueue中

4. 在 resolvePromiseA 执行后，promiseA 才是 resolved (状态为 fulfilled，值为 p 的 fulfilled value)

我们可以看到，从 newPromise(res=>res(p)) 到该调用返回的 promise 真正被 resolve 至少需要两次 microtick——在我们的例子中，是遍历了两次 MicroTaskQueue

这个时候，我们终于可以理清楚开头代码的执行顺序：

01月28日更新，之前微任务队列里面的任务没有考虑顺序，这里做一下修改，以下队列里的任务是顺序有关，从左往右，左边的先执行

1、当代码执行完后

• MicroTaskQueue有两个任务： PromiseResolveThenableJob， tick:a

2、开始执行 runMicrotasks()

• MicroTaskQueue变成： resolvePromiseA， tick:b

• console: tick:a

3、 MicroTaskQueue没有清空，继续执行队列中的任务

• MicroTaskQueue变成： after:await

• console: tick:a, tick:b

4、继续执行，清空 MicroTaakQueue

• console: tick:a, tick:b, after:await

未来更快的 v8

借助我们更熟悉的 promise，我们基本知道了现阶段的 await的执行机制，这样我们就能很好理解为什么 v8 博客中提到的改进可以使 await 执行更快：

将 newPromise(res=>res(p))替换成 Promise.resolve(p)

根据MDN文档， 当 p 是一个 promise 时， Promise.resolve(p)直接返回 p，而这是大概率事件。

因此，我们减少了 promise 之间状态同步需要的两次 microtick，那样，上述代码的输出结果就是：

1. after:await

2. tick:a

3. tick:b

2019.02.12 更新

之前提到 Node.js 8 的实现不符合标准，其实是 V8 6.2 引入的一个bug

1. const promise = new Promise(res => res(p))

某些情况下（如 p 已经 resolved）V8 没有严格按照 promise-resolve-functions 的第13步执行。

文章开头的例子代码，虽然优化后的执行结果和 V8 6.2 一样，但是背后的逻辑是不一样的，附上对比图：

- end -

用心分享 一起成长 做有温度的攻城狮

每天记得对自己说：你是最棒的！

好文阅读

各种资源免费共享：简历模板、面试题等

都看到这里了，给个“好看”再走呗～