当游戏引擎也有竞态条件：从 Minecraft 红石看时序设计

写业务代码时，「竞态条件」是个绕不开的词：两个操作谁先谁后不确定，结果就不确定，于是出现了偶发 Bug、难以复现、换个环境就好。

有意思的是，Minecraft 的红石系统里有一模一样的坑。而且因为它的时间尺度和空间边界都被明确暴露出来，反而是理解竞态的好教具。

游戏没有「实时」，只有游戏刻

Minecraft 世界不是连续演化的，而是以固定的时间片推进。所有逻辑都挂在这个节拍上：

单位	换算	角色
游戏刻 gt	1 秒 = 20 gt（每刻 50ms）	游戏主循环的最小时间片
红石刻 rt	1 rt = 2 gt = 0.1 秒	红石元件的延迟计量单位

这和任何事件循环是同一个模型：它不是「发生即处理」，而是「攒到一个 tick，按顺序处理一批」。中继器的 1–4 档延迟、活塞的伸缩、比较器的响应，全都在这个离散网格上排队。

      text
      
1
2
3

真实时间 →  0ms    50ms   100ms   150ms  ...
游戏刻   →   t0     t1      t2      t3
                └──── 每刻处理一批方块更新 ────┘

关键点：在同一个 tick 内，多个事件的处理顺序是由引擎内部实现决定的。只要你的设计依赖「A 一定先于 B」，而 A、B 又在同一 tick 内被触发，那你就踩进了未定义行为的领地。

中继器、比较器这类元件的响应，有一个容易忽略的前提——输入必须维持足够长的时间。如果产生的是一个只有一个 tick 宽的瞬时脉冲，比较器很可能根本来不及响应，事件就被漏掉了。

这几乎是前端里同一个 tick 内连续 setState 被批处理、或事件在下一帧才被消费的翻版：你以为发出去了，实际上接收方还没轮到执行。

对策也很直白：不要假设接收方随时待命。要么用中继器把窄脉冲拉宽到接收方来得及响应，要么在接收端加一个锁存器先「接住」信号，再异步处理。这就是电路里的缓冲 / 背压。

这是红石里最经典的竞态来源：当一次更新同时向水平和垂直方向传播时，两条路径的传播顺序并不保证一致。谁先到达、谁后到达，可能因上下文而变化。

如果你的电路恰好对到达顺序敏感（比如两条路径各控制一个活塞，而它们必须先左后右），那装置就会表现得时好时坏——典型的偶发 Bug。

它在软件里的对应物太多了：

对策：不要指望引擎保证顺序，而是用中继器把顺序显式写出来。给其中一条路径加 1 rt 延迟，先后关系就从「不确定」变成「确定」。在并发编程里，这对应的就是用队列 / 序列化 / 加锁把并发改成有序。

Minecraft 的世界按**区块（chunk）**划分，区块是加载、卸载、乃至并行处理的基本单位。当一个装置横跨两个区块时，问题来了：区块边界上的刻推进并不总是同步的，在加载/卸载的瞬间尤其容易「卡刻」——装置停住不动了。

把它类比成分片系统就很好懂：一个事务跨了两个分片，而两个分片的时钟/提交时机不一致。轻则延迟，重则状态不一致。

对策：把核心闭环放在同一个区块内。设计时先用 F3 + G 打开区块边界显示，确认机器最关键的反馈回路不跨越边界。这就是分布式系统里的数据局部性（data locality）——让强相关的东西待在一起，避免跨节点协调。

一条经验法则

红石装置的核心反馈回路，尽量收敛到同一个区块内。跨区块不是不能做，而是每一次跨越都在向引擎「借」顺序保证，而这些保证在区块加载/卸载的边界上并不可靠。

BUD（方块更新检测）依赖活塞的准连接性，零刻脉冲（0-tick）依赖单刻内完成一次完整动作——这些技巧效率极高，但它们全都建立在引擎某个具体实现细节之上，而不是被承诺的行为。

这就像在代码里依赖某个库的私有内部实现，或者依赖语言的未定义行为：能跑，而且跑得很爽，但升级一次就可能全线崩塌。

对策有两条：

这其实就是软件里的依赖风险管控 + 灰度发布。

把上面几点收拢成一张对照表，会发现两边几乎是同一套知识：

红石装置调试时那种「怎么又不动了」「换台电脑就好了」的挫败感，和后端排查竞态 Bug 时几乎一模一样。区别在于：Minecraft 把时间单位和空间边界都摊在你面前，竞态不再是看不见的幽灵，而是能拿中继器和区块边界直接观察、直接消除的东西。

所以反过来，用红石练手时序思维是划算的：

相关阅读：