volatile不能保证复合操作原子性，因其仅保证单次读写可见性与禁止变量自身重排序，无法使i++等读-改-写三步变为不可分割动作，故不适用于计数器、多变量协同等场景。
为什么 volatile 不能保证复合操作的原子性
因为 volatile 只禁止变量本身的读写重排序，并不阻止 JVM 或 CPU 对相邻普通指令的重排，更不提供锁语义。它只保证“这个变量的每次读都从主内存取，每次写都立即刷回主内存”，但像 i++ 这种操作包含读-改-写三步，volatile int i 无法让这三步变成一个不可分割的动作。
常见错误现象：
多个线程对 volatile int counter 执行 counter++，最终结果远小于预期；用 volatile boolean flag 控制循环，却在 flag 改变后仍读到旧的共享对象状态（比如未初始化完成的对象引用）。
- 使用场景：适合做状态标志（如
running）、单次写入后多线程读取的配置项、与锁/原子类配合做轻量级可见性保障 - 不要用于计数器、累加器、依赖顺序的多变量协同逻辑（例如先设
data = x再设ready = true，虽有volatile ready，但data仍可能没及时对其他线程可见） - 性能影响极小，比
synchronized或AtomicInteger开销低得多，但功能边界清晰——它不是“轻量级 synchronized”
volatile 写操作插入的是哪种内存屏障
JVM 规范规定：volatile 写会在其后插入一个 **StoreStore 屏障**（防止上面的普通写被重排到 volatile 写之后），并在其前插入一个 **StoreLoad 屏障**（最重的屏障，防止上面的写和下面的读/写跨过它重排）。这是为了确保 volatile 写之前的所有内存操作对其他线程可见。
关键点在于：StoreLoad 屏障会显著影响性能（尤其在 x86 上需用 lock addl $0,0(%rsp) 模拟），但它不可省略——否则就无法实现“写 volatile 后，之前所有写都对读该 volatile 的线程可见”这一语义。
立即学习“Java免费学习笔记（深入）”；
- x86 架构下，volatile 读天然具有 LoadLoad + LoadStore 语义，不需要额外指令；volatile 写则必须用
lock前缀指令来实现 StoreLoad - ARM/AArch64 没有直接对应指令，JVM 必须插入
dmb ish等完整内存栅栏，开销更大 - 不要试图用
Unsafe.storeFence()替代 volatile 写——它只提供 StoreStore+StoreLoad，缺少对之前读操作的约束，语义不等价
为什么 double-checked locking 需要 volatile 修饰单例引用
因为对象构造过程可能被重排序：JVM 可能将“分配内存 → 初始化对象 → 将引用赋值给静态变量”优化为“分配内存 → 将引用赋值给静态变量 → 初始化对象”。若此时另一个线程读到非 null 的引用，就会拿到一个未初始化完成的对象，触发 NPE 或诡异行为。
volatile 强制在引用赋值这一步插入 StoreStore + StoreLoad 屏障，确保“初始化完成”一定发生在“引用赋值”之前，从而堵住这个重排序漏洞。
- 错误写法：
private static Singleton instance;—— 即使加了 synchronized，new 出来的对象引用赋值仍可能重排 - 正确写法：
private static volatile Singleton instance;，且仅对 instance == null 分支加锁 - 注意：volatile 解决的是“引用可见性 + 构造过程不重排”，不解决类加载阶段的线程安全问题（所以仍需 static holder 或枚举等更彻底方案）
如何验证 volatile 是否真的阻止了重排序
不能靠肉眼读字节码或想当然，得用 JMM 模型工具或实际观测。OpenJDK 自带的 JCStress 是最可靠的手段——它会生成大量并发执行的测试用例，穷举各种指令交错可能，统计是否出现违反 volatile 语义的结果（如看到新写的 volatile 值，却读不到它之前写入的普通变量）。
- 简单模拟失败场景：两个线程分别执行
write()（设flag = true和data = 42）和read()（轮询flag，然后读data），不加 volatile 时，read()可能观察到flag == true && data == 0 - 用
@JCStressTest注解跑起来，结果里若出现1,0（flag=1, data=0）即证明重排序发生；加上 volatile 后该结果应消失 - 注意：HotSpot 在某些优化级别（如 -XX:+OptimizeFill）下可能干扰测试，需固定 JVM 参数并预热
真正难的不是记住“volatile 加了屏障”，而是理解哪些重排序它拦得住、哪些拦不住，以及在具体硬件上代价几何。写错一次，可能几年都看不出问题，出问题时又极难复现。
