传递性规则是happens-before关系的逻辑纽带：若A happens-before B且B happens-before C，则A的结果对C可见；它不依赖物理时间顺序，但要求每段链（A→B、B→C）均由某条具体规则（如程序顺序、锁、volatile等）保障，任一环节缺失即导致可见性失效。
传递性规则是 happens-before 关系的“逻辑 glue”——它本身不直接建立同步，但能把多个独立的 happens-before 链条串起来，形成跨线程、跨操作的可见性保障。
传递性不是时间顺序，而是可见性链条
如果 A happens-before B，且 B happens-before C，那么 JMM 保证 A 的结果对 C 可见。这个结论不依赖物理执行先后：A 可能比 C 晚执行，只要两条关系链成立，C 就一定能看到 A 写入的值。
- 它不关心 A 和 C 是否在同一线程，也不要求 B 是某个特定操作（比如锁或 volatile）
- 关键在于每一对（A→B、B→C）都必须由某条 happens-before 规则明确支持（如程序顺序、锁规则、volatile 规则等）
- 一旦链条断裂（比如 B→C 缺少同步依据），整个传递就失效，C 可能看不到 A 的修改
典型链条示例：锁 + 程序顺序
线程 A 执行：
synchronized(lock) { x = 1; } // 解锁前写 x线程 B 执行：
立即学习“Java免费学习笔记（深入）”；
synchronized(lock) { y = x + 1; } // 加锁后读 x- A 的解锁 happens-before B 的加锁（监视器锁规则）
- B 的加锁 happens-before y = x + 1（程序顺序规则）
- 由传递性，A 的解锁 happens-before y = x + 1
- 又因 A 的 x = 1 happens-before 解锁（程序顺序），最终 A 的 x = 1 对 y = x + 1 可见
常见断链陷阱
传递性容易被表面代码迷惑，实际失效往往藏在同步缺失处：
- 只给写操作加 synchronized，读操作不加锁 → 写释放锁与读之间无 happens-before，无法传递
- 用普通变量做信号（如 flag = true），另一线程 while(flag) 读取 → 没有 volatile 或锁支撑，flag 读写之间无规则，传递链不存在
- 两个 volatile 写之间没有明确顺序约束，中间插入非 volatile 操作，可能破坏预期链路
它让分散同步变得可推理
真实并发代码很少靠单个同步点解决所有问题。传递性允许你把 volatile 写、锁进出、线程启动等不同机制组合使用。只要每段连接合法，整条路径就可信。它不增加新同步动作，却极大提升了 JMM 的表达力和推理性。
