执行模型与运行时
Category
server / runtime 子树总览。覆盖：并发立场总览（00）、执行模型（01）、协程状态机队列（02）、Tick 驱动（03）、流控背压（04）、锁竞争（05）、Epoch 运行时（06）。
Definition
这一章关注的不是“会不会用多线程”这种表层问题，而是服务端和引擎内部到底如何推进逻辑、组织状态、切分调度单位、控制并发和消化高峰。线程、协程、Actor、任务队列、Tick 驱动、背压和锁竞争，最后都在回答同一个问题：怎样让系统在高负载下仍然保持可预测、可恢复、可调试。
很多线上故障看起来像业务 Bug，根因其实是运行时组织方式先错了：
- 状态跨线程乱飞，时序不可推理。
- 某些慢任务拖住主循环。
- 高峰来了以后队列无边界增长。
- 锁竞争把吞吐和抖动一起拖垮。
所以这一章真正要解决的，不是某种“更先进模型”的崇拜，而是让你能判断：不同问题模型下，应该用什么运行时组织方式承载核心状态，哪些工作应该顺序推进，哪些工作值得并行，哪些工作应该异步外包但不能反向污染主链路。
如果只讲“线程、协程、Actor”几个词，这一章的标准是不够的。更合理的顺序是：
- 先建立并发模型谱系，知道不同模型到底在解决什么问题。
- 再回到游戏项目里最常见的几类主运行时组织方式。
- 然后讨论协程、状态机、任务队列、Tick、背压和锁这些运行时细节怎样共同决定线上稳定性。
Related
关系链：立场（00）→ 执行模型（01）→ 三件套分工（02）→ Tick（03）→ 背压（04）→ 锁（05）→ 专用运行时（06）。上游：无（runtime 入口）；下游：sync 子树（时间与时序的消费方）、server/sync（战斗时序）、树根 server 总览。
Reference
节点清单见下节。
本章文章
- 并发模型总览：从七周七并发到游戏运行时：先把常见并发模型的谱系摆出来，再说明游戏项目通常会局部借用哪些思想。
- 单线程、多线程与 Actor：把游戏里最常被拿来做主运行时的三类执行组织方式拆开，比较它们的状态哲学和故障形态。
- 协程、状态机与任务队列：讨论异步流程、有限状态和排队治理分别该由什么机制负责。
- Tick 驱动与逻辑执行：把逻辑时间、主循环、帧预算和异步结果回收放回同一条运行时链路里看。
- 流控、背压与稳定性机制：说明高峰和慢消费者到来时，系统怎样限速、丢弃、降级和快速失败。
- 锁竞争与性能代价：讨论共享状态、锁粒度、争用和尾延迟为什么会把“理论并行”变成现实阻塞。
- Epoch-driven Actor / Channel Runtime：用更具体的运行时例子说明，为什么某些游戏核心逻辑会选择时间优先、顺序优先、单写优先的执行内核。