有关 协程 原理， 见 《协程 和 async await》 https://www.cnblogs.com/KSongKing/p/10799875.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 语法糖 上 纠缠下去 像是一个 泥塘 ， 新一代 的 架构 是 重新 整理 线程 这个 东西 ， 在 语言 级别 实现 语言级 的 “线程”（协程） 是一个 最好 的 平衡点 。