volatile写操作happens-before后续对该变量的读操作，该规则通过禁止重排序、强制主内存读写及内存屏障实现，并借助传递性使前置普通变量写对读线程可见。
Java 内存模型（JMM）通过 volatile 写-读规则，在 volatile 变量的写操作和后续读操作之间建立明确的 happens-before 关联。这种关联不是靠“时间先后”保证的，而是 JMM 定义的一套逻辑先行关系，用于确保多线程下的内存可见性与有序性。
volatile 写-读规则是核心约束
对同一个 volatile 变量：
• 一次写操作（如 v = true）happens-before 后续任意线程对该变量的读操作（如 if (v)）；
• 这个“后续”指代码顺序或执行逻辑上的后续，不要求物理时间紧邻；
• 规则仅作用于该 volatile 变量本身，但借助传递性可延伸影响其他普通变量。
它如何让普通变量也变得可见？
volatile 的威力不只限于自身值的同步，关键在于它能“带出”前面的普通写操作：
• 在同一线程中，普通变量写（如 x = 42）在 volatile 写（v = true）之前发生 → 满足程序顺序规则；
• volatile 写 happens-before 其他线程的 volatile 读 → 满足 volatile 规则；
• 由传递性可推出：普通变量写 happens-before 其他线程的 volatile 读；
• 因此，当另一线程看到 v == true，它就一定能观察到 x == 42（前提是没被重排序破坏，而 volatile 本身禁止重排序）。
底层是怎么落实这个关联的？
JMM 要求 JVM 在编译和运行时做两件事来支撑这一规则：
• 禁止重排序：编译器不得将 volatile 写之前的普通写移到其后，也不得将 volatile 读之后的普通读移到其前；
• 强制刷新与加载：volatile 写必须立即将值刷入主内存；volatile 读必须从主内存重新加载最新值（绕过 CPU 缓存）；
• 这些行为在 x86 上常通过 lock 前缀指令实现，在 ARM 上则对应内存屏障（memory barrier）。
它不是锁，但有类似效果
volatile 不提供原子性（比如 i++ 仍需同步），但它提供的 happens-before 关联：
• 保证了写操作对读操作的可见性；
• 保证了写与读之间的有序性（防止指令重排破坏逻辑依赖）；
• 开销远低于 synchronized，适合状态标志、一次性初始化等轻量同步场景。
