交缠模式的形成
两个子系统最初作为独立模块存在。随着时间推移，每个子系统都在共享的上帝对象上累加字段：全局配置结构体、单例管理器或静态类。每次添加在孤立情况下都是正确的，但耦合在小规模测试中是不可见的。
这种固化发生的三个基底：
VLC 媒体播放器。 音频、视频与播放列表共享一把锁，守护全局播放器状态。跳至时间戳请求获取锁、修改播放位置并刷新音频缓冲区。视频子系统等待同一把锁而停滞，播放列表子系统同样等待，无法预取。结果：三个独立子系统通过单一状态对象串行化。性能代价：O(N) 锁争用，其中 N = 子系统数量，均与操作延迟成正比。
Redis 事件循环。 AOF fsync（磁盘写入）、复制（网络写入）和命令执行（CPU）共用同一个单线程事件循环。每个操作单独来看都是正确的。一次缓慢的 fsync 会阻塞命令执行。在写入负载下，复制延迟会进一步累积。耦合点在于：不同延迟特征的操作共享同一个执行上下文。
LevelDB VersionSet。 写入路径（memtable 刷盘）与后台 compaction 共享 VersionSet 锁。一次 compaction 任务会持有该锁数十毫秒，导致写入路径阻塞。两个操作都是必要的。耦合是结构性的，而非时序问题。
关键区别
Intertangle 存在的是结构耦合，而非时序问题。竞态条件是指两个线程在没有同步的情况下访问共享状态，解决方法是添加互斥锁。
Intertangle 是两个子系统按设计共享状态。添加互斥锁无法消除耦合，只会将访问串行化。子系统仍然共享状态，瓶颈反而会更严重。
在 VLC 的 Intertangle 中添加互斥锁只会让情况更糟：音频、视频和播放列表都将等待同一把锁。结构化修复方法是：为每个子系统提供独立的状态。阶段快照：在阶段边界冻结共享状态的快照，让每个子系统独立读取快照，并在结束时合并写回。
结构耦合 vs 时序问题
诊断 Intertangle 的关键问题：添加互斥锁能否修复它，还是会让它变得更糟？
竞态条件：添加互斥锁即可修复。正确的访问顺序消除了数据损坏。
交织（Intertangle）：添加互斥锁会序列化访问，但保留了结构耦合。子系统仍共享状态。在负载下，它们仍会互相阻塞。瓶颈变得更窄。
如何发现交织（Intertangle）
三个检测信号：
1. 子系统之间共享的可变字段。 一个上帝对象，其字段被多个子系统读写。如果移除某个子系统对字段的访问会导致另一个子系统崩溃，则说明它们共享状态。
2. 单一互斥锁保护不相关的操作。 同一个锁同时保护音频刷新、视频解码和播放列表获取：三个具有不同延迟特征的子系统却互相等待。坏味道：不相关的操作却使用同一个锁名。
3. 增加负载时出现性能回退。 操作 A 的延迟在操作 B 并发运行时上升，尽管 A 与 B 表面上相互独立。实际上它们并不独立：它们共享状态。
阶段快照修复方案
阶段快照模式：
# 之前：子系统直接读写共享状态
class GameWorld:
position = {} # 共享的可变对象
velocity = {} # 共享的可变对象
def physics_tick(world):
for entity in world.entities:
world.position[entity] += world.velocity[entity] # 在循环中写入共享状态# 之后：快照在阶段前冻结；写入将进入 next_state 缓冲区
def physics_tick(world):
snapshot = world.freeze() # 不可变视图
next_state = {}
for entity in snapshot.entities:
next_state[entity] = snapshot.position[entity] + snapshot.velocity[entity]
world.merge(next_state) # 在阶段边界进行原子合并每个子系统都读取快照。没有任何子系统写入快照。写入操作会累积到缓冲区，并在阶段边界处原子合并。现在子系统可以独立执行：无锁争用、无顺序依赖、无隐藏耦合。
应用修复
某团队报告了一个缺陷：他们的游戏引擎中，动画系统与碰撞系统都会写入同一个共享实体变换对象。当两者在同一 tick 内运行时，碰撞结果取决于动画是否先执行。添加互斥锁解决了顺序问题，但现在动画系统会在碰撞系统执行广阶段扫描时发生停滞。