协程 的 主要作用 是 让 单核 GC 变成 单线程 GC， 这样， 在 单核 范围 内， GC 要 工作 时， 不需要 挂起 线程， 只需要 挂起 协程，
因为 协程 的 代码 实际上 是 一个 线程 里 执行的代码， GC 也是一个 协程， 也 运行在 这个 线程 里， 因此 GC 要 工作 时，挂起协程， 不用 把 寄存器 里 的 对象引用 写回 内存（这个 写回 内存 和 保存 线程 上下文 是 两回事， 线程 切换 时 要 把 寄存器 里 的 数据 保存到内存，这是 保存 上下文， 而 这里 是 把 寄存器 里 的 对象引用 写回 内存 里 对应 的 变量，相当于 一个 内存屏障， 但 理论上 只 写回 引用数据 就行，其它 数据 不关心， 因为 在 线程 架构下， GC 要 扫描 引用， 若 引用 在 寄存器 里 被改写 又 没有 写回 内存， 则 GC 扫描 内存 里 的 引用 就 不对 了）， 这样 GC 的 架构 就简单 。 但 协程 架构下的 GC 仍然要 扫描 栈 里 的 局部变量 持有 的 对象引用 。 而 状态机 更进一步， 状态机 可以 在 Step 函数 执行完成 后 执行 GC， 这样 GC 不用 扫描 栈 里 的 局部变量 （持有 的 对象引用） 。 状态机 见 下文 。
等等， 纠正一下， （GC 工作前）， 协程 也要 把 寄存器 里的 引用数据 写回 内存， 除非 编译器 预知 切换后 下一个 要 执行 的 协程 是 哪一个， 并 将 下一个 协程 的 代码 内联进来 做 寄存器 优化 （寄存器 布局）。
在 一些 场合， 编译器 可以知道 接下来 要 执行 的 协程 ， 比如 一些 异步操作， 故 可以 把 接下来的 协程 （异步操作） 的 代码 内联 进来， 统一 做 寄存器 优化 （寄存器 布局）。
这样的话， 这些 已经 不是 协程 架构了， 这些 是 状态机 的 内容， 也可以说， 这是 协程 向 状态机 进化 的 苗头 。
但 其实 意义不大， 比如 GC 的 代码 不太可能 和 用户代码 内联 在一起， 通常 用户代码 和 GC 是 两个 独立 的 Step 函数， 既然 是 两个 独立 的 函数， 每个 函数 就是 一个 自然 的 内存屏障 。 既然 是 内存屏障， 当然 函数结束 时 要 把 寄存器 里 的 数据 都 写回 内存 。
这样搞 很晕， 很乱 的 。
协程 还是 和 线程 类似 的 “上下文 + 切换” 架构， 当 挂起 协程 时， 要 保存上下文，如果 是 GC 即将工作 要求 挂起的， 还要 把 寄存器 里 的 引用数据 写回 内存， 这和 保存上下文 一定程度 上 是 重复工作 。
状态机 是 彻底 的 函数化， 以 函数 为 执行单位， 不存在 协程 那样 的 “上下文”， 只要 考虑 内存屏障 即可， 同时 编译器 可以 对 函数 统一 做 尽可能深化 的 内联 和 寄存器优化 （寄存器布局） 。
说到 这里 想起一个 问题， .Net / C# async 方法 里 似乎 不能用 lock， 只能用 AsyncLock， 而 Task 里 似乎 是 能 用 lock 的， Task 里 用 lock 会 怎么样 ？ lock 时 要 挂起 Task 等待 的 话， 是否 采用 协程技术 ？ 还是 状态机 ？ 而 如果 Task 里 使用 AsyncLock 又会怎么样 ？ 感觉 很多 重复技术 嵌套 在 一起， 很乱的， 很费力 。
在 完全 的 Task 化 的 情况下， （Task 化 也 包括 状态机 和 Step 函数） ， 单核 的 GC 架构 可以 变成 最简单 的 单线程 GC， 即 Task 工作结束 后 GC 才工作， GC 工作时 没有 Task 在 工作， 这样 不用 挂起线程， 也不用 挂起协程， 也不用 扫描 栈 里的 局部变量 （持有 的 对象引用） ， 这样 的 GC 是 最简单 的 形态， 1000 行 代码可以写好， 且 架构 简单清晰， 因为 架构简单清晰， 就 容易做到 安全 稳定 。
所以， 小朋友们， 要 让 通用 处理器 和 操作系统 再次 回到 状态机 吗 ？
也许 这个时候， 编译器 就 跳出来 说话了， 这些 不用 改变 通用 处理器 和 操作系统， 所谓 的 “状态机” 可以由 编译器 在 代码 层面 “模拟” 出来 。
哈哈， 慢慢 玩 吧 。
挂起 n 个 协程 比 挂起 n 个 线程 的 开销 低 很多， 最起码， 挂起 线程 需要跟 操作系统 通信， 而 挂起 协程 纯粹 是 一个 线程 内 的 一些 代码 执行 。
另外， 因为 n 个 协程 都 只是 一个 线程 内 的 代码 执行， 因此， 可以 对 这些 代码 进行 各种 优化， 就像 优化 普通 的 代码， 一些 函数调用， 包括 内联 和 寄存器优化， 且 可以 减少内存屏障 的 使用次数 。
但 想了一下， 协程 不能 减少 内存屏障 的 使用次数，
要 深化 内联 和 寄存器优化 的 程度， 减少 内存屏障 使用次数， 应该是 由 一个 状态机 来执行 n 个 任务（协程）， 这样 可以 进一步 把 任务（协程） 的 代码 内联 在 状态机 里， 进行 寄存器优化， 比如 .Net / C# async await， 但 其实 这个技术 很勉强 。
我在 《从 内存 到 CPU Cache 之间 的 数据读写 的 时间消耗 是 线程切换 性能消耗 的 主要原因 之一 是 不正确 的》 https://www.cnblogs.com/KSongKing/p/14152765.html 里 说
“所以， 协程 也 不能 搞 太多 。”
“但 现在 看来， 协程 也不能 玩 10 万 个 。”
是说， 协程 不能 解决 线程切换 导致 线程 的 栈 载入载出 Cache 的 性能消耗 的 问题， 协程 的 栈 也有这个问题 。
由此 看来， 编译 为 一个 状态机， 代替 n 个 任务（协程）， 可以 彻底 取消 n 个 栈， 只要 状态机 一个 栈， 并且 控制 每一个 Step 函数 的 函数调用层级 不要太多， 这样 可以 使 栈 总是 保持 较小 。 当然， 单个 函数 也 不宜 过长， 单个 函数代码 过长，变量过多， 当然 也会 导致 需要 的 栈空间 较大 。
所以， 编译器 要 做一个 权衡， 使得， Step 函数 不要太大， 也不要 太小， 太大 会 占用 较大 的 栈空间， 太小 又 可能 函数调用层级 比较多， 也会 占用 较大 栈空间 。
前几天 和 之前 讨论 D++ 时候 就 冒出了 本文 的 部分想法， 现在 随想记录一下 。
以上 内容 写于 2022-04-23 、2022-04-24 。