volatile实现有序性靠内存屏障而非锁,通过storestore、storeload、loadload和loadstore屏障约束volatile读写周边指令重排,并建立happens-before关系保障可见性。

volatile 实现有序性,核心是靠内存屏障(Memory Barrier)禁止指令重排序,而不是靠锁或阻塞。
内存屏障阻止编译器和处理器乱序
当 JVM 遇到 volatile 变量的读或写操作时,会在其前后插入特定类型的内存屏障:
- volatile 写操作前:插入 StoreStore 屏障,确保该写之前的所有普通写操作已刷新到主内存,不会被重排到 volatile 写之后
- volatile 写操作后:插入 StoreLoad 屏障,防止后续的普通读/写操作被重排到该 volatile 写之前
- volatile 读操作后:插入 LoadLoad 和 LoadStore 屏障,保证该读之后的读/写操作不会被提前执行
有序性不是“全局时间顺序”,而是 happens-before 关系
volatile 的有序性体现为一种语义约束:一个线程对 volatile 变量的写,happens-before 另一个线程对该变量的读。这意味着:
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 写线程在 volatile 写之前对其他变量的所有修改,对读线程可见
- 读线程在读取 volatile 变量之后,才能看到这些修改结果
- 这种顺序保障不依赖 CPU 时钟同步,而是由内存屏障强制执行的执行流约束
它不阻止所有重排序,只约束与 volatile 相关的操作
比如以下代码中,volatile 仅约束 flag 周围的指令:
private int a = 0;private volatile boolean flag = false;
void init() {
a = 1; // 普通写
flag = true; // volatile 写 → 编译器/JVM 确保 a=1 不会排到这句之后
}
但 a = 1 和它前面的无关语句(如日志打印、局部变量赋值)仍可能被重排——volatile 只管它自己“附近”的内存访问顺序。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










