volatile写入的happens-before效果在写操作完成时即生效，依靠内存屏障和禁止重排序实现，而非运行时通知；其可见性保证依赖同一volatile变量构成的同步链，且需结合程序顺序与同步顺序。
volatile 写入的 happens-before 效果，不是靠“等读取发生时才生效”，而是靠内存屏障 + 禁止重排序，在写操作完成那一刻就对后续读操作（在 happens-before 顺序中）建立可见性保证。
它不依赖运行时“检测”或“通知”
很多人误以为 volatile 写后，JVM 会“主动通知”其他线程去刷新缓存。其实不是。volatile 的语义是编译器和 CPU 层面的约束：
- 写 volatile 变量时，插入一个 StoreStore + StoreLoad 内存屏障（具体因平台而异，但效果等价）；
- 读 volatile 变量时，插入一个 LoadLoad + LoadStore 内存屏障；
- 编译器禁止将普通读写重排序到 volatile 读写之前/之后（如：不能把 volatile 写之后的普通写提到它前面）。
happens-before 是偏序关系，不是时间先后
“volatile 写 happens-before 后续读” 指的是：如果代码中存在这样的执行顺序（且无其他干扰），那么该读一定能看到该写的结果。关键点在于“后续”是 程序顺序（program order）+ 同步顺序（synchronization order） 定义的：
- 线程 A 执行 x = 1; flag = true;（flag 是 volatile）；
- 线程 B 执行 if (flag) { v = x; }；
- 由于 flag = true 和 if (flag) 构成同步关系（volatile 写 → volatile 读），且都在各自线程内满足程序顺序，因此 x = 1 happens-before v = x；
- 所以 B 中读到的 x 不会是 0（未初始化值）——前提是 B 确实读到了这个 true。
真正起作用的是“刷新”和“禁止重排”的组合
volatile 写的那一刻，不仅把值刷到主内存，还确保它之前的写（包括非 volatile 字段）也已对其他线程可见（StoreLoad 屏障阻止了这些写被拖到 volatile 写之后）。同样，volatile 读的那一刻，不仅从主内存加载最新值，还确保它之后的读不会被提前（避免读到过期缓存）。
- 没有 volatile，x = 1 可能还在寄存器或 CPU 缓存里，B 永远看不到；
- 有 volatile flag，写 flag 会把 x=1 “带出去”，读 flag 会把 x=1 “带进来”；
- 这不是魔法，是硬件屏障 + JVM 规范共同落实的内存模型契约。
注意前提：必须是同一个 volatile 变量构成的同步链
volatile 的 happens-before 不能跨变量传递。例如：
- A 写 flag1 = true（volatile），再写 flag2 = true（volatile）；
- B 读 flag2 为 true，不能推出它一定看到 A 对 flag1 的写（除非 B 也读了 flag1）；
- 只有通过同一个 volatile 变量的读写配对，才能建立明确的同步点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
