volatile不能保证原子性，因其仅确保可见性和禁止重排序，而i++等操作需“读-改-写”三步，多线程下仍可能交叉执行；适合纯状态标志位，复合操作须用AtomicInteger或锁。
volatile 为什么不能保证原子性
很多人以为加了 volatile 就能安全地做自增操作，结果还是出现数据错乱。根本原因是：可见性 ≠ 原子性。volatile 只保证每次读都从主内存取、每次写都立即刷回主内存，但 i++ 这种操作本身是“读-改-写”三步，在多线程下仍可能被交叉执行。
常见错误现象：counter 被多个线程反复 i++ 一万次，最终值却远小于预期；用 volatile 修饰 Boolean 标志位做开关，逻辑看似正确，但配合非原子操作（比如先判断再修改某个集合）时仍出问题。
- 只适合纯状态标志位：如
running、initialized，且后续操作不依赖该变量的旧值 - 涉及复合操作（
+=、++、条件更新等），必须换AtomicInteger或加锁 -
volatile对引用类型只保证引用本身的可见性，不保证其内部字段的可见性
volatile 如何禁止指令重排序
JVM 和 CPU 都可能对指令重排以提升性能，但 volatile 写操作会插入一个「StoreStore」屏障，读操作插入「LoadLoad」和「LoadStore」屏障，从而约束编译器和处理器的行为。
典型使用场景：双重检查锁（DCL）单例中，如果不加 volatile，可能导致对象被部分构造后就被其他线程看到——因为构造函数内的字段赋值可能被重排到对象引用赋值之后。
立即学习“Java免费学习笔记（深入）”；
- 没有
volatile的 DCL 中，instance = new Singleton()可能被拆成：分配内存 → 设置引用 → 执行构造器；后两步顺序可能调换 - 加上
volatile后，JMM 强制要求：所有对该变量的写操作必须在引用发布前完成，且读线程能看到完整的初始化结果 - 注意：这种重排序禁止仅对
volatile变量本身及其前后的读写有约束，不是全局内存栅栏
volatile 在哪些场景下比 synchronized 更合适
当只需要“一个线程写、多个线程读”的简单通知语义，且无竞态逻辑时，volatile 开销远低于 synchronized —— 它不涉及锁获取/释放、线程挂起/唤醒，也不产生上下文切换。
常见误用：试图用 volatile 替代锁来保护一段临界区代码，或在循环中频繁读写 volatile 变量导致缓存行频繁失效（false sharing）。
- 推荐场景：状态开关（
shutdownRequested）、初始化完成标志（isReady）、轻量级信号量（配合Thread.yield()等轮询） - 慎用场景：高频率读写（如计数器）、需要与其他变量保持一致性的组合状态（如
volatile int count和ArrayList items配合使用） - 性能影响：现代 JVM 对
volatile读做了优化（基本等同普通读），但写操作仍需内存屏障，比普通写慢约 10–20%；在多核密集写场景下，还会加剧缓存一致性协议开销
volatile 与 happens-before 关系的实操理解
volatile 是 Java 内存模型（JMM）中定义的 happens-before 规则之一：对一个 volatile 变量的写操作，happens-before 于任意后续对该变量的读操作。这是它实现可见性和有序性的理论基础。
容易忽略的关键点：这个规则只对“同一个 volatile 变量”成立；如果线程 A 写了 volatile flag = true，然后修改了普通变量 data = 42，线程 B 读到 flag == true，并不能保证看到 data == 42 —— 除非 data 也声明为 volatile，或用锁同步。
- 要让非 volatile 变量的修改对读线程可见，必须把它们放在同一个同步措施下：要么全用
volatile，要么进同一把锁，要么用AtomicReferenceFieldUpdater等工具类 - 编译器不会对
volatile操作做重排序优化，但会对它周围的普通变量重排——所以别指望靠它“顺便”保护邻近字段 - 调试时看不到重排序效果，因为它是运行时现象，且依赖具体硬件和 JVM 实现；验证必须靠并发压力测试 + 字节码/汇编分析
