【JS】930- 更快的 async 函数和 promises

r囧r小猫 2023-01-13 10:10 120阅读 0赞

![e77f08d0b9e31ece946d73f6515c1d8a.png][]

作者：语雀

链接：https://www.yuque.com/es2049/blog/yfqmu1

原文链接：https://v8.dev/blog/fast-async

JavaScript 的异步过程一直被认为是不够快的，更糟糕的是，在 NodeJS 等实时性要求高的场景下调试堪比噩梦。不过，这一切正在改变，这篇文章会详细解释我们是如何优化 V8 引擎（也会涉及一些其它引擎）里的 `async` 函数和 `promises` 的，以及伴随着的开发体验的优化。

**温馨提示：** 这里有个 视频：https://www.youtube.com/watch?v=DFP5DKDQfOc，你可以结合着文章看。

## 异步编程的新方案 ##

### 从 callbacks 到 promises，再到 async 函数 ###

在 promises 正式成为 JavaScript 标准的一部分之前，回调被大量用在异步编程中，下面是个例子：

function handler(done) {
      validateParams((error) => {
        if (error) return done(error);
        dbQuery((error, dbResults) => {
          if (error) return done(error);
          serviceCall(dbResults, (error, serviceResults) => {
            console.log(result);
            done(error, serviceResults);
          });
        });
      });
    }

类似以上深度嵌套的回调通常被称为「回调黑洞」，因为它让代码可读性变差且不易维护。

幸运地是，现在 promises 成为了 JavaScript 语言的一部分，以下实现了跟上面同样的功能：

function handler() {
      return validateParams()
        .then(dbQuery)
        .then(serviceCall)
        .then(result => {
          console.log(result);
          return result;
        });
    }

最近，JavaScript 支持了 async 函数，上面的异步代码可以写成像下面这样的同步的代码：

async function handler() {
      await validateParams();
      const dbResults = await dbQuery();
      const results = await serviceCall(dbResults);
      console.log(results);
      return results;
    }

借助 async 函数，代码变得更简洁，代码的逻辑和数据流都变得更可控，当然其实底层实现还是异步。（注意，JavaScript 还是单线程执行，async 函数并不会开新的线程。）

### 从事件监听回调到 async 迭代器 ###

NodeJS 里 ReadableStreams 作为另一种形式的异步也特别常见，下面是个例子：

const http = require('http');
    
    http.createServer((req, res) => {
      let body = '';
      req.setEncoding('utf8');
      req.on('data', (chunk) => {
        body += chunk;
      });
      req.on('end', () => {
        res.write(body);
        res.end();
      });
    }).listen(1337);

这段代码有一点难理解：只能通过回调去拿 chunks 里的数据流，而且数据流的结束也必须在回调里处理。如果你没能理解到函数是立即结束但实际处理必须在回调里进行，可能就会引入 bug。

同样很幸运，ES2018 特性里引入的一个很酷的 async 迭代器 可以简化上面的代码：

const http = require('http');
    
    http.createServer(async (req, res) => {
      try {
        let body = '';
        req.setEncoding('utf8');
        for await (const chunk of req) {
          body += chunk;
        }
        res.write(body);
        res.end();
      } catch {
        res.statusCode = 500;
        res.end();
      }
    }).listen(1337);

你可以把所有数据处理逻辑都放到一个 async 函数里使用 `for await…of` 去迭代 chunks，而不是分别在 `'data'` 和 `'end'` 回调里处理，而且我们还加了 `try-catch` 块来避免 `unhandledRejection` 问题。

以上这些特性你今天就可以在生成环境使用！async 函数**从 Node.js 8 (V8 v6.2 / Chrome 62) 开始就已全面支持**，async 迭代器**从 Node.js 10 (V8 v6.8 / Chrome 68) 开始支持**。

## async 性能优化 ##

从 V8 v5.5 (Chrome 55 & Node.js 7) 到 V8 v6.8 (Chrome 68 & Node.js 10)，我们致力于异步代码的性能优化，目前的效果还不错，你可以放心地使用这些新特性。

![format_png][]

上面的是 doxbee 基准测试，用于反应重度使用 promise 的性能，图中纵坐标表示执行时间，所以越小越好。

另一方面，parallel 基准测试 反应的是重度使用 Promise.all() 的性能情况，结果如下：

![format_png 1][]

`Promise.all` 的性能提高了**八倍**！

然后，上面的测试仅仅是小的 DEMO 级别的测试，V8 团队更关心的是 实际用户代码的优化效果。

![format_png 2][]

上面是基于市场上流行的 HTTP 框架做的测试，这些框架大量使用了 promises 和 `async` 函数，这个表展示的是每秒请求数，所以跟之前的表不一样，这个是数值越大越好。从表可以看出，从 Node.js 7 (V8 v5.5) 到 Node.js 10 (V8 v6.8) 性能提升了不少。

性能提升取决于以下三个因素：

*  TurboFan，新的优化编译器 ????
 *  Orinoco，新的垃圾回收器 ????
 *  一个 Node.js 8 的 bug 导致 await 跳过了一些微 tick（microticks） ????

当我们在 Node.js 8 里 启用 TurboFan 的后，性能得到了巨大的提升。

同时我们引入了一个新的垃圾回收器，叫作 Orinoco，它把垃圾回收从主线程中移走，因此对请求响应速度提升有很大帮助。

最后，Node.js 8 中引入了一个 bug 在某些时候会让 `await` 跳过一些微 tick，这反而让性能变好了。这个 bug 是因为无意中违反了规范导致的，但是却给了我们优化的一些思路。这里我们稍微解释下：

const p = Promise.resolve();
    
    (async () => {
      await p; console.log('after:await');
    })();
    
    p.then(() => console.log('tick:a'))
     .then(() => console.log('tick:b'));

上面代码一开始创建了一个已经完成状态的 promise `p`，然后 `await` 出其结果，又同时链了两个 `then`，那最终的 `console.log` 打印的结果会是什么呢？

因为 `p` 是已完成的，你可能认为其会先打印 `'after:await'`，然后是剩下两个 `tick`, 事实上 Node.js 8 里的结果是：

![format_png 3][]

虽然以上结果符合预期，但是却不符合规范。Node.js 10 纠正了这个行为，会先执行 `then` 链里的，然后才是 async 函数。

![format_png 4][]

这个「正确的行为」看起来并不正常，甚至会让很多 JavaScript 开发者感到吃惊，还是有必要再详细解释下。在解释之前，我们先从一些基础开始。

### 任务（tasks）vs. 微任务（microtasks） ###

从某层面上来说，JavaScript 里存在任务和微任务。任务处理 I/O 和计时器等事件，一次只处理一个。微任务是为了 `async`/`await` 和 promise 的延迟执行设计的，每次任务最后执行。在返回事件循环（event loop）前，微任务的队列会被清空。

![format_png 5][]

可以通过 Jake Archibald 的 tasks, microtasks, queues, and schedules in the browser 了解更多。Node.js 里任务模型与此非常类似。

### async 函数 ###

根据 MDN，async 函数是一个通过异步执行并隐式返回 promise 作为结果的函数。从开发者角度看，async 函数让异步代码看起来像同步代码。

一个最简单的 async 函数：

async function computeAnswer() {
      return 42;
    }

函数执行后会返回一个 promise，你可以像使用其它 promise 一样用其返回的值。

const p = computeAnswer();
    // → Promise
    
    p.then(console.log);
    // prints 42 on the next turn

你只能在下一个微任务执行后才能得到 promise `p` 返回的值，换句话说，上面的代码语义上等价于使用 `Promise.resolve` 得到的结果：

function computeAnswer() {
      return Promise.resolve(42);
    }

async 函数真正强大的地方来源于 `await` 表达式，它可以让一个函数执行暂停直到一个 promise 已接受（resolved），然后等到已完成（fulfilled）后恢复执行。已完成的 promise 会作为 `await` 的值。这里的例子会解释这个行为：

async function fetchStatus(url) {
      const response = await fetch(url);
      return response.status;
    }

`fetchStatus` 在遇到 `await` 时会暂停，当 `fetch` 这个 promise 已完成后会恢复执行，这跟直接链式处理 `fetch` 返回的 promise 某种程度上等价。

function fetchStatus(url) {
      return fetch(url).then(response => response.status);
    }

链式处理函数里包含了之前跟在 `await` 后面的代码。

正常来说你应该在 `await` 后面放一个 `Promise`，不过其实后面可以跟任意 JavaScript 的值，如果跟的不是 promise，会被制转为 promise，所以 `await 42` 效果如下：

async function foo() {
      const v = await 42;
      return v;
    }
    
    const p = foo();
    // → Promise
    
    p.then(console.log);
    // prints `42` eventually

更有趣的是，`await` 后可以跟任何 “thenable”，例如任何含有 `then` 方法的对象，就算不是 promise 都可以。因此你可以实现一个有意思的 类来记录执行时间的消耗：

class Sleep {
      constructor(timeout) {
        this.timeout = timeout;
      }
      then(resolve, reject) {
        const startTime = Date.now();
        setTimeout(() => resolve(Date.now() - startTime),
                   this.timeout);
      }
    }
    
    (async () => {
      const actualTime = await new Sleep(1000);
      console.log(actualTime);
    })();

一起来看看 V8 规范 里是如何处理 `await` 的。下面是很简单的 async 函数 `foo`：

async function foo(v) {
      const w = await v;
      return w;
    }

执行时，它把参数 `v` 封装成一个 `promise` ，然后会暂停直到 `promise` 完成，然后 `w` 赋值为已完成的 `promise` ，最后 `async` 返回了这个值。

### 神秘的 `await` ###

首先，V8 会把这个函数标记为可恢复的，意味着执行可以被暂停并恢复（从 `await` 角度看是这样的）。然后，会创建一个所谓的 `implicit_promise`（用于把 async 函数里产生的值转为 promise）。

![format_png 6][]

然后是有意思的东西来了：真正的 `await`。首先，跟在 `await` 后面的值被转为 promise。然后，处理函数会绑定这个 promise 用于在 promise 完成后恢复主函数，此时 async 函数被暂停了，返回 `implicit_promise` 给调用者。一旦 `promise` 完成了，函数会恢复并拿到从 `promise` 得到值 `w`，最后，`implicit_promise` 会用 `w` 标记为已接受。

简单说，`await v` 初始化步骤有以下组成：

1.  把 `v` 转成一个 promise（跟在 `await` 后面的）。
2.  绑定处理函数用于后期恢复。
3.  暂停 async 函数并返回 `implicit_promise` 给掉用者。

我们一步步来看，假设 `await` 后是一个 promise，且最终已完成状态的值是 `42`。然后，引擎会创建一个新的 `promise` 并且把 `await` 后的值作为 resolve 的值。借助标准里的 PromiseResolveThenableJob这些 promise 会被放到下个周期执行。

![format_png 7][]

然后，引擎创建了另一个叫做 `throwaway` 的 promise。之所以叫这个名字，因为没有其它东西链过它，仅仅是引擎内部用的。`throwaway` promise 会链到含有恢复处理函数的 `promise` 上。这里 `performPromiseThen` 操作其实内部就是 Promise.prototype.then()。最终，该 async 函数会暂停，并把控制权交给调用者。

![format_png 8][]

调用者会继续执行，最终调用栈会清空，然后引擎会开始执行微任务：运行之前已准备就绪的 PromiseResolveThenableJob，首先是一个 PromiseReactionJob，它的工作仅仅是在传递给 `await` 的值上封装一层 `promise`。然后，引擎回到微任务队列，因为在回到事件循环之前微任务队列必须要清空。

![format_png 9][]

然后是另一个 PromiseReactionJob，等待我们正在 `await`（我们这里指的是 `42`）这个 `promise` 完成，然后把这个动作安排到 `throwaway` promise 里。引擎继续回到微任务队列，因为还有最后一个微任务。

![format_png 10][]

现在这第二个 PromiseReactionJob 把决定传达给 `throwaway` promise，并恢复 async 函数的执行，最后返回从 `await` 得到的 `42`。

![format_png 11][]

总结下，对于每一个 `await` 引擎都会创建**两个额外**的 promise（即使右值已经是一个 promise），并且需要**至少三个**微任务。谁会想到一个简单的 `await` 竟然会有如此多冗余的运算？！

![format_png 12][]

我们来看看到底是什么引起冗余。第一行的作用是封装一个 promise，第二行为了 resolve 封装后的 promose `await` 之后的值 `v`。这两行产生个冗余的 promise 和两个冗余的微任务。如果 `v` 已经是 promise 的话就很不划算了（大多时候确实也是如此）。在某些特殊场景 `await` 了 `42` 的话，那确实还是需要封装成 promise 的。

因此，这里可以使用 promiseResolve 操作来处理，只有必要的时候才会进行 promise 的封装：

![format_png 13][]

如果入参是 promise，则原封不动地返回，只封装必要的 promise。这个操作在值已经是 promose 的情况下可以省去一个额外的 promise 和两个微任务。此特性可以通过 `--harmony-await-optimization`参数在 V8（从 v7.1 开始）中开启，同时我们 向 ECMAScript 发起了一个提案，目测很快会合并。

下面是简化后的 `await` 执行过程：

![format_png 14][]

感谢神奇的 promiseResolve，现在我们只需要传 `v` 即可而不用关心它是什么。之后跟之前一样，引擎会创建一个 `throwaway` promise 并放到 PromiseReactionJob 里为了在下一个 tick 时恢复该 async 函数，它会先暂停函数，把自身返回给掉用者。

![format_png 15][]

当最后所有执行完毕，引擎会跑微任务队列，会执行 PromiseReactionJob。这个任务会传递 `promise`结果给 `throwaway`，并且恢复 async 函数，从 `await` 拿到 `42`。

![format_png 16][]

尽管是内部使用，引擎创建 `throwaway` promise 可能还是会让人觉得哪里不对。事实证明，`throwaway`promise 仅仅是为了满足规范里 `performPromiseThen` 的需要。

![format_png 17][]

这是最近提议给 ECMAScript 的 变更，引擎大多数时候不再需要创建 `throwaway` 了。

![format_png 18][]

对比 `await` 在 Node.js 10 和优化后（应该会放到 Node.js 12 上）的表现：

![format_png 19][]

**async/await 性能超过了手写的 promise 代码**。关键就是我们减少了 async 函数里一些不必要的开销，不仅仅是 V8 引擎，其它 JavaScript 引擎都通过这个 补丁 实现了优化。

## 开发体验优化 ##

除了性能，JavaScript 开发者也很关心问题定位和修复，这在异步代码里一直不是件容易的事。Chrome DevTools 现在支持了异步栈追踪：

![d624f05652beef2278e75f04afb7a00a.png][]

在本地开发时这是个很有用的特性，不过一旦应用部署了就没啥用了。调试时，你只能看到日志文件里的 `Error#stack` 信息，这些并不会包含任何异步信息。

最近我们搞的 零成本异步栈追踪 使得 `Error#stack` 包含了 async 函数的调用信息。「零成本」听起来很让人兴奋，对吧？当 Chrome DevTools 功能带来重大开销时，它如何才能实现零成本？举个例子，`foo` 里调用 `bar`，`bar` 在 await 一个 promise 后抛一个异常：

async function foo() {
      await bar();
      return 42;
    }
    
    async function bar() {
      await Promise.resolve();
      throw new Error('BEEP BEEP');
    }
    
    foo().catch(error => console.log(error.stack));

这段代码在 Node.js 8 或 Node.js 10 运行结果如下：

$ node index.js
    Error: BEEP BEEP
        at bar (index.js:8:9)
        at process._tickCallback (internal/process/next_tick.js:68:7)
        at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
        at startup (internal/bootstrap/node.js:266:19)
        at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)

注意到，尽管是 `foo()` 里的调用抛的错，`foo` 本身却不在栈追踪信息里。如果应用是部署在云容器里，这会让开发者很难去定位问题。

有意思的是，引擎是知道 `bar` 结束后应该继续执行什么的：即 `foo` 函数里 `await` 后。恰好，这里也正是 `foo` 暂停的地方。引擎可以利用这些信息重建异步的栈追踪信息。有了以上优化，输出就会变成这样：

$ node --async-stack-traces index.js
    Error: BEEP BEEP
        at bar (index.js:8:9)
        at process._tickCallback (internal/process/next_tick.js:68:7)
        at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
        at startup (internal/bootstrap/node.js:266:19)
        at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)
        at async foo (index.js:2:3)

在栈追踪信息里，最上层的函数出现在第一个，之后是一些异步调用栈，再后面是 `foo` 里面 `bar` 上下文的栈信息。这个特性的启用可以通过 V8 的 `--async-stack-traces` 参数启用。

然而，如果你跟上面 Chrome DevTools 里的栈信息对比，你会发现栈追踪里异步部分缺失了 `foo` 的调用点信息。这里利用了 `await` 恢复和暂停位置是一样的特性，但 Promise\#then() 或 Promise\#catch()就不是这样的。可以看 Mathias Bynens 的文章 await beats Promise\#then() 了解更多。

## 结论 ##

async 函数变快少不了以下两个优化：

*  移除了额外的两个微任务
 *  移除了 `throwaway` promise

除此之外，我们通过 零成本异步栈追踪 提升了 `await` 和 `Promise.all()` 开发调试体验。

我们还有些对 JavaScript 开发者友好的性能建议：

多使用 `async` 和 `await` 而不是手写 `promise` 代码，多使用 JavaScript 引擎提供的 `promise` 而不是自己去实现。

![b3a315a4bf491b41b3a6353884da7841.gif][]

[1. JavaScript 重温系列（22篇全）][1. JavaScript _22]

[2. ECMAScript 重温系列（10篇全）][2. ECMAScript _10]

[3. JavaScript设计模式 重温系列（9篇全）][3. JavaScript_ _9]

4. [正则 / 框架 / 算法等 重温系列（16篇全）][_ _ _ _ _16]

5. [Webpack4 入门（上）][Webpack4]|| [Webpack4 入门（下）][Webpack4 1]

6. [MobX 入门（上）][MobX] || [MobX 入门（下）][MobX 1]

7. 120[\+篇原创系列汇总][Link 1]

![fae08c915c256be94edf94b3ae401dd9.gif][]

回复“**加群**”与大佬们一起交流学习~

点击“**阅读原文**”查看 120+ 篇原创文章

[e77f08d0b9e31ece946d73f6515c1d8a.png]: /images/20221022/9b28dd0d61a54dc696e6e11f1220128b.png
[format_png]: /images/20221022/f28233e8723b4ba493f97ac3ab111c29.png
[format_png 1]: /images/20221022/7314a5c86d014905b0ba23e0658ef76d.png
[format_png 2]: /images/20221022/c03cd766fd3a4657a2c6636082c45f1b.png
[format_png 3]: /images/20221022/31cddf8017ae42d2affb9a91199792a3.png
[format_png 4]: /images/20221022/7b8892e738e848f08bff2c38adeb0c99.png
[format_png 5]: /images/20221022/e6c99defa4084ff4a2deac55df8acc86.png
[format_png 6]: /images/20221022/b210a0d3e9f84fd9a944441f860ffb68.png
[format_png 7]: /images/20221022/f053fde6fc7448dbb402d69ecad96b22.png
[format_png 8]: /images/20221022/dfe399426f294be39e6e205335163d41.png
[format_png 9]: /images/20221022/9d6e3ab3e7b744ee89145c48c1c37fc6.png
[format_png 10]: /images/20221022/eaf06e0656564a4fb4a1c55b4073b78d.png
[format_png 11]: /images/20221022/4b00ecf46f924a5caa41ee2767ab73f8.png
[format_png 12]: /images/20221022/48abc18339c240f3a7b8c477413910ee.png
[format_png 13]: /images/20221022/7e223730899449d79df2f5a0464be5aa.png
[format_png 14]: /images/20221022/f37c839bbc484492936a0dbe6880a66b.png
[format_png 15]: /images/20221022/314a4a91ddf34e2591f8aa341699be69.png
[format_png 16]: /images/20221022/381208ae86724a24a8d62450cdd17f71.png
[format_png 17]: /images/20221022/f06860957cec4b718a0826dbdb330b4b.png
[format_png 18]: /images/20221022/7d9e6ef40eae4118b5fe91d62a1e6546.png
[format_png 19]: /images/20221022/b2a03c61a6e94659a1f9e651ab812780.png
[d624f05652beef2278e75f04afb7a00a.png]: /images/20221022/b5fffecf8fed4d71a2dcc1026528cd4a.png
[b3a315a4bf491b41b3a6353884da7841.gif]: /images/20221022/bc416526a9be4b91b0108636dfb611d5.png
[1. JavaScript _22]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224ea86b5adfc10c3aa1841be3879b9360d671e98cc73391c2490246f1348857b9821d32c&idx=1&mid=2458453187&scene=21&sn=a69b4d7d991867a07a933f86e66b9f55#wechat_redirect
[2. ECMAScript _10]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e086b5adf6dad41a0d36b77a9bfb4bc9f0d29a816266b3e28c892e54274967dbce380b&idx=1&mid=2458453193&scene=21&sn=e5392cb77bc17c9e94b6c826b5f52a83#wechat_redirect
[3. JavaScript_ _9]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e386b5adf554ab928cdeaf7ee16dbb2d895be17f2a12a59054a75b913470ca7649bbc7&idx=1&mid=2458453194&scene=21&sn=e7f0734b04484bee5e10a85a7cbb85c1#wechat_redirect
[_ _ _ _ _16]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224e286b5adf432850f82db18cc8647d639836798cf16b478d9a6f7c81df87c6da5257684&idx=1&mid=2458453195&scene=21&sn=1e0c8b7ea8ddc207b523ec0a636a5254#wechat_redirect
[Webpack4]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251f86b5ac09dbbbb7c8e1d80c6cbd793a523cdfa690f8734def57812e616b9906aeec79&idx=1&mid=2458453302&scene=21&sn=904e40a421024ea0d394e9850b674012#wechat_redirect
[Webpack4 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2251e86b5ac08464872cd880811423e0d1bbcebbe11dcac9d99fa38c5332c089c06d65d95&idx=1&mid=2458453303&scene=21&sn=422f2b5e22c3b0e91a8353ee7e53fed9#wechat_redirect
[MobX]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264c86b5af5aa7300a04d55efead6223e310d68e10222cd3577a25c783d3429f00767960&idx=1&mid=2458453605&scene=21&sn=0a506769d5eeb7953f676e93fb4d18eb#wechat_redirect
[MobX 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c2264086b5af5611524eedb0d409afe86d859dce6ceff1c17ddab49d353c385e45611a73fa&idx=1&mid=2458453609&scene=21&sn=f0c22e82f2537204d9b173161bae6b82#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MjM5MDc4MzgxNA%3D%3D&chksm=b1c224dd86b5adcbd98189315e60de6a0106993690b69927cc1c1f19fd8f591fefce4e3db51f&idx=2&mid=2458453236&scene=21&sn=daf00392f960c115463c5aaf980620b4#wechat_redirect
[fae08c915c256be94edf94b3ae401dd9.gif]: /images/20221022/dc29b854e7264a57a145e4844773bf31.png