更快的 async 函数和 promises
舒适提示： 这里有个 视频，你能够结合着文章看。node
异步编程的新方案
从 callbacks 到 promises，再到 async 函数编程
在 promises 正式成为 JavaScript 标准的一部分以前，回调被大量用在异步编程中，下面是个例子：bootstrap
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 语言的一部分，如下实现了跟上面一样的功能：promise
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 函数并不会开新的线程。）bash
从事件监听回调到 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 迭代器 能够简化上面的代码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)，咱们致力于异步代码的性能优化，目前的效果还不错，你能够放心地使用这些新特性。
性能提高取决于如下三个因素：
- 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 里的结果是：
任务（tasks）vs. 微任务（microtasks）
从某层面上来讲，JavaScript 里存在任务和微任务。任务处理 I/O 和计时器等事件，一次只处理一个。微任务是为了 async/await 和 promise 的延迟执行设计的，每次任务最后执行。在返回事件循环（event loop）前，微任务的队列会被清空。
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;
}
复制代码
神秘的 await
首先，V8 会把这个函数标记为可恢复的，意味着执行能够被暂停并恢复（从 await 角度看是这样的）。而后，会建立一个所谓的 implicit_promise（用于把 async 函数里产生的值转为 promise）。
简单说，await v 初始化步骤有如下组成：
1.把 v 转成一个 promise（跟在 await 后面的）。
2.绑定处理函数用于后期恢复。
3.暂停 async 函数并返回 implicit_promise 给掉用者。
咱们一步步来看，假设 await 后是一个 promise，且最终已完成状态的值是 42。而后，引擎会建立一个新的 promise 而且把 await 后的值做为 resolve 的值。借助标准里的 PromiseResolveThenableJob 这些 promise 会被放到下个周期执行。
总结下，对于每个 await 引擎都会建立两个额外的 promise（即便右值已是一个 promise），而且须要至少三个微任务。谁会想到一个简单的 await 居然会有如此多冗余的运算？！
所以，这里可使用 promiseResolve 操做来处理，只有必要的时候才会进行 promise 的封装：
下面是简化后的 await 执行过程
开发体验优化
除了性能，JavaScript 开发者也很关心问题定位和修复，这在异步代码里一直不是件容易的事。Chrome DevTools 如今支持了异步栈追踪：
最近咱们搞的 零成本异步栈追踪 使得 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 而不是本身去实现。
- 1. 「译」更快的 async 函数和 promises
- 2. V8 中更快的异步函数和 promises
- 3. Async-Await ≈ Generators + Promises
- 4. Promises与 async/await
- 5. 【译】Async-Await≈Generators+Promises
- 6. Callbacks, Promises and Async/Await
- 7. 图解JavaScript Promises 和 Async/Await
- 8. Async/await 和 Promises 区别
- 9. Handle Non-Cypress Async Promises
- 10. async函数和await函数
- 更多相关文章...
- • Hibernate的快照技术 - Hibernate教程
- • XML DOM async 属性 - XML DOM 教程
- • TiDB 在摩拜单车在线数据业务的应用和实践
- • IntelliJ IDEA 代码格式化配置和快捷键
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 「译」更快的 async 函数和 promises
- 2. V8 中更快的异步函数和 promises
- 3. Async-Await ≈ Generators + Promises
- 4. Promises与 async/await
- 5. 【译】Async-Await≈Generators+Promises
- 6. Callbacks, Promises and Async/Await
- 7. 图解JavaScript Promises 和 Async/Await
- 8. Async/await 和 Promises 区别
- 9. Handle Non-Cypress Async Promises
- 10. async函数和await函数