volatile不能保证原子性，因其仅确保单次读写可见性，无法原子执行“读-改-写”复合操作（如i++），多线程下结果可能小于预期；需用AtomicInteger、synchronized或Lock保障原子性。
volatile 为什么不能保证原子性
声明为 volatile 的变量只保证每次读取都从主内存加载、每次写入都立即刷回主内存，但不保证复合操作（如 i++）的原子性。这个操作实际包含“读-改-写”三步，中间可能被其他线程打断。
-
i++在字节码中对应getstatic→iadd→putstatic，volatile只能确保每一步的读/写可见，无法锁住整个序列 - 多个线程同时执行
counter++（counter是volatile int），最终结果大概率小于预期值 - 需要原子性时，应改用
AtomicInteger、synchronized或Lock
volatile 能禁止哪些指令重排序
volatile 写操作具有“释放语义”（release semantics），读操作具有“获取语义”（acquire semantics），JVM 和 CPU 都会遵守其重排序约束：
- 在
volatile写之前的所有普通读写，不能被重排序到该写之后 - 在
volatile读之后的所有普通读写，不能被重排序到该读之前 - 但
volatile读与volatile写之间，仍可能发生重排序（除非用volatile读+写构成 happens-before 链）
典型用途是实现双重检查锁定（DCL）单例中的实例字段：防止 instance = new Singleton() 中对象构造未完成就被其他线程看到。
volatile 与 synchronized 的内存语义差异
两者都保证可见性，但机制和开销不同：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
-
synchronized进入时清空本地内存、从主内存读最新值；退出时将本地修改全部刷回主内存，并对临界区内的所有操作建立 happens-before 关系 -
volatile每次读写都直连主内存，无锁开销，但仅作用于单个变量，不提供互斥或代码块级别的同步保障 - 在低竞争、仅需状态通知（如
shutdownRequested标志位）场景下，volatile更轻量；涉及多变量协同或复合逻辑时，必须用synchronized或更高级同步工具
哪些场景下 volatile 会失效
看似符合“一个写、多个读”的简单模型，却因隐含依赖导致失效：
- 写线程更新
volatile boolean ready = true前，未确保它所依赖的数据（如配置对象config）已初始化完毕并对其可见 —— 必须把config初始化放在ready = true之前，且config本身也需是volatile或用锁保护 - 使用
volatile long或volatile double时，若 JVM 不支持原子的 64 位读写（如某些 32 位 JVM），可能出现“半个值”问题（虽现代 JDK 通常已修复） - 反射绕过
volatile语义（如Unsafe.putOrderedInt）、或 JNI 直接操作内存，都会破坏其保证
真正安全的 volatile 使用，永远要结合具体数据流和 happens-before 链来验证，不能只看变量声明本身。
