再见 异步回调， 再见 Async Await， 10 万 个 协程 的 时代 来 了

有关 协程 原理，  见 《协程 和 async await》   http://www.javashuo.com/article/p-xmwneoss-ec.html  ，

 

协程 切换 的时间很快，   就是 保存 3 个 寄存器 的 值， 再 修改 3 个 寄存器 的 值，

这  3 个 寄存器 分别 保存的 是  协程 的 栈顶 栈底 指令计数器，

 

切换 协程 就是  保存 上一个 协程 的  栈顶 栈底 指令计数器 ，   再 把 寄存器 的 值 修改 为 下一个 协程 的 栈顶 栈底 指令计数器  。

 

因此，  协程 切换 至关于 是 调用一个 很短 的  方法，  时间复杂度 能够认为是  O(1)    。

 

我在  《协程 和 async await》   中 提到， 协程 避免 闭包 共享变量 带来的 二次寻址 的 性能消耗，

 

可是，实际上，    有了 协程  的 话，    已经不须要 异步回调 来   减小 线程数量 和 线程切换时间，  固然 也不须要  async await  。

 

咱们能够 正常 的 编写 同步调用 的 方法，好比，  读取文件， 能够调用 FileStream 的 Read()   方法，  而 不须要 调用 ReadAsync() 或者 BeginRead() 方法 。

 

固然，这个 Read()  方法 须要用  协程 从新实现，   Read()  方法 的 同步等待 要用 协程 的 同步等待 来实现，而不是 线程 的 同步等待 。

 

协程 的 同步等待 和 线程 同样，   在 Read() 方法 里，   当 调用 操做系统 的 异步 IO   API 时，   当前 协程 挂起，  当前 线程 转而 执行其它 协程 ，

当 异步 IO 完成时，会把  调用这个 IO 的 挂起 的 协程 唤醒（放入 就绪队列），这样 接下来 很快就会 执行到 这个 协程  了  。

 

这和 线程 是同样的  。    但 我就不知道 操做系统 到底 作了些什么，   以致于 线程 这个 “资源”  如此 “昂贵”，  搞得 这些年 流行 炒做 线程，   像  炒股 同样 炒 的 很热，

什么    异步回调 流， libuv， IOCP ， ePoll ，  async await ，  状态机，  编译器 黑魔法，   GoRoutine，  CoRoutine     ……

Go  语言 的  介绍    每次都 强调 “支持高并发”， “编写服务器端程序”  ，       我原来还奇怪，  高并发 这个不是 很日常 么，  C# 不也是 高并发 没毛病  ……

 

这几天 才 想起来，  原来  Go   强调 “支持 高并发”   大概 是  由于 有  GoRoutine  啊   ~~  ！

 

这些 基于 异步回调  和  语法糖   的 作法，   将 代码  切割 的 支离破碎，    语法糖  篡改了  原始代码 ，  让 编译器 变得 笨重复杂，  让  程序员 的 代码 和 编译器 的 代码 变得 难以理解 ，      让 编译器 技术    升维  为   大型 软件工程   。

 

我在 《协程 和 async await》  中 提到，  协程 须要 编译器 在 堆 里 模拟 线程 的  栈 和 上下文 保存区，   其实还须要 模拟同样，  就是 操做系统（CPU） 的   时间片 调度，        这可有点难，  弄很差 性能 就 一落千尺，  与 咱们 轻量 高性能 的 目标 背道而驰  。

 

可是，  实际上，  协程 基本上 不须要 时间片 调度，    只须要 不停执行 就能够，   只有 遇到 IO 的 时候 才 挂起， 执行下一个 协程，  就能够了   。

 

这样就 差很少 了  。

 

在 协程 架构下，  对于 每个 请求 ，  能够 建立一个 协程 来处理，处理完了 协程 就 销毁，  能够 存在 大量  协程  ，

这 体现 出 与 线程 的 区别 是，   不须要 考虑  建立开销，  不须要 考虑  切换开销，  不须要 考虑（协程） 数量  。

 

在 一台 服务器 上，    同时 运行  10 万 个 协程 也能够   。

 

这样就能够和        异步回调  ,   Async  Await        说 再见 了     。

 

这样 就能够  “回归最柔软的初心， 诗意的栖居在大地上”    ，     什么是   “柔软的初心”     ？

 

就是  80 年代 的 苹果电脑 、 中华学习机 、 286 、 Basic 、  90 年代  的  谭浩强 爷爷 的 C 语言   。

还有  70 年代 的 Unix  、  贝尔实验室  、   网络链路 和 网路协议   。

 

协程   是   ILBC / D#    的  一大 卖点    。

 

你们可能 担忧  对 协程 的 就绪队列 和 挂起队列 的 队列 读写 须要 Lock（同步互斥），  这个 Lock  的 性能 怎么样，

我以前在   ILBC / D#     中 提到过   ILBC  用 CAS 指令 实现  IL Lock ，  用于  堆 管理（读写 堆  表），

这个作法 和 C# Java 的 new 操做  读写堆表 时 用的 作法 应该是同样的（我推测）  。

CAS  实现 的 lock 是 很快 的，  能够认为 是 指令级 的 ，   能够认为 时间复杂度 是 O(1)  。

事实上，  测试  C#  的 new 操做 的 性能 大约 是  操做系统 lock （lock 关键字 / Monitor.Enter()） 的  10  倍  。

或者说，  C#  的 new 操做 的 时间花费 大约 是  操做系统 lock （lock 关键字 / Monitor.Enter()） 的  1/10    。

 

在  “异步回调”  和  async await 语法糖  上  纠缠下去 像是一个 泥塘 ，   新一代 的 架构 是 从新 整理 线程 这个 东西 ，     在 语言 级别 实现 语言级 的 “线程”（协程） 是一个 最好 的 平衡点    。