async await 的 实质 本质

async await  的 实质 就是 用 “状态机” 来 取代 函数层层调用 。

async await  的 本质 是 语法糖，  和 提高性能 什么的 没什么关系 。

为了避免理解歧义， 我把 “状态机” 称为 “控制机” 。

为了实现一个 语言级 的 ，  在 任意代码 中 通用的 异步回调 “变成 同步代码” 的 语法糖，  需要 解决 函数层层调用 的 问题，  即 异步调用 包含在 函数层层调用 中的问题 。

为了解决这个问题， async await 通过 编译器 对 代码 进行了 切割 和 重新整理，  再拼凑起来，  还原出 原本的 代码 执行的效果 。

还原，  就是用 “控制机” 来 对 切割成 “步骤” 的 代码 逐步调用，    所以，  原本代码中的   函数层层调用   被    控制机   取代了 。

而 async await 的 性能 相比 普通方法 并没有 提高，  相反还 降低 了 。

可以参考 《后线程时代 的 应用程序 架构》  https://www.cnblogs.com/KSongKing/p/10228842.html

里面有 async await 和 普通方法 的 性能测试 对比 。

不过经过后来的研究， 发现 async await 是良性的， 参考 《无阻塞 编程模型》  https://www.cnblogs.com/KSongKing/p/10287882.html  。

在 QQ 群的讨论中， 有 网友 给出了 一段 代码 ：

通过 这种 方式 可以 以 回调 的 方式  把 每层 方法里的 await 后面的代码  层层 打包 返回 到 最上层，

然后再  UnWrap() ，   即 层层 执行  await  后面的代码，  如下图 ：

通过 闭包 把  await 后面的代码 变成一个 函数，  再把 这个 函数 作为 回调 通过 上述 的 方式 层层打包， 等 异步方法 执行完后 又 层层执行 这些 回调， 这样可以实现 async await 的效果 。

也就是说， 编译器 按 上述方式 处理 代码 的话，  可以实现  async await 。

用这种方式的话， 可以不需要 控制机 。

这个 网友 认为 状态机 是用来 处理 多个 await 的 场景 的 ：

不过 后来 他又说了    “状态机只是一种优化， 不是必须的” 。

而 另外一位网友 说     “状态机 是为了减少闭包上下文传递” 。

So  ……

So  …… ？

So  ？