volatile通过内存屏障保障有序性：写操作后插入写屏障，确保之前所有读写不重排到其后并刷回主存；读操作前插入读屏障，确保之后所有读写不重排到其前并强制读最新值；二者共同构建happens-before关系。
volatile 通过在字节码层面插入内存屏障（Memory Barrier），约束 JVM 和 CPU 的指令重排序行为，从而保障多线程下程序执行的有序性。它不改变单线程语义，但为跨线程操作建立了明确的 happens-before 关系。
volatile 写操作触发写屏障（Store Barrier）
当对 volatile 变量执行写操作时，JVM 在其后插入一个写屏障，确保：
- 该写操作之前的**所有读写指令**，不会被重排到该写操作之后
- CPU 将对应缓存行强制刷回主内存（借助 lock 前缀指令或等效原子指令）
- 其他 CPU 核心通过 MESI 协议将本地缓存中该变量所在缓存行置为无效
例如：a = 1; flag = true;（flag 是 volatile）→ 编译器和 CPU 必须保证 a=1 先于 flag=true 执行并提交，否则屏障失效。
volatile 读操作触发读屏障（Load Barrier）
当读取 volatile 变量时，JVM 在其前插入一个读屏障，确保：
- 该读操作之后的**所有读写指令**，不会被重排到该读操作之前
- CPU 强制从主内存（或最新同步的缓存行）加载该变量值，跳过本地旧缓存
例如：if (flag) { System.out.println(a); }（flag 是 volatile）→ 一旦读到 flag==true，就能安全看到 a=1 的结果，因为读屏障阻止了 println(a) 提前执行，也保证了 a 的写入已对当前线程可见。
屏障如何协同构建 happens-before 链
volatile 的读写屏障共同构成一条同步链：
- 线程 A 对 volatile 变量 V 的写，happens-before 线程 B 对 V 的读
- 而该写之前的所有操作，都 happens-before 该读之后的所有操作
- 这正是 DCL 单例中“防止对象半初始化”问题被解决的根本机制
本质上，volatile 不是“禁止所有重排”，而是精准限制读写周围的指令流动范围，用最小代价换取关键顺序保证。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
