有关 协程 原理， 见 《协程 和 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 的 挂起 的 协程 唤醒（放入 就绪队列），这样 接下来 很快就会 执行到 这个 协程 了 。
再见 异步回调， 再见 Async Await， 10 万 个 协程 的 时代 来 了
原文：https://www.cnblogs.com/KSongKing/p/10802278.html