volatile仅保障可见性与有序性，不保证原子性；适用于单写多读、无依赖的纯状态标识场景，如线程开关、dcl单例、配置更新标志等，而读-改-写复合操作必须用锁或原子类。
volatile 关键字的实际业务应用边界，核心在于它只解决“可见性”和“有序性”，但不解决“原子性”。只要业务逻辑中涉及多线程对同一变量的读-改-写复合操作（比如 i++、list.add()、状态切换依赖当前值判断），volatile 就不再适用——这不是性能问题，而是语义错误。
适合用 volatile 的典型场景
这些场景共同特点是：单写多读、无依赖、纯状态标识或简单赋值：
-
线程运行开关控制：如
private volatile boolean running = true;，配合while(running)循环，一个线程设为false，其他线程能立即感知退出； -
配置热更新标志：例如配置中心推送新配置后，设置
volatile boolean configUpdated = true;，多个监听线程轮询该标志触发 reload； -
DCL 单例中的 instance 引用：
private volatile static Singleton instance;，防止 new 对象过程中的指令重排（如分配内存→初始化→赋值）导致其他线程拿到未初始化完成的对象； -
轻量级状态通知：如任务执行完成标记
volatile boolean finished = false;，仅由一个线程置为true，其他线程只读不修改；
明确不能用 volatile 的情况
一旦出现以下任意一种行为，就必须换用 synchronized、ReentrantLock 或原子类（如 AtomicInteger）：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 变量参与自增/自减（
counter++）、复合赋值（status |= FLAG_A）； - 读取变量值后做条件判断再修改（如 “如果 status == INIT，则改为 RUNNING”）；
- 多个 volatile 变量之间存在逻辑依赖（如先写
a=1再写b=2，另一端需按顺序看到 a 和 b 的变化）； - 需要保证整个代码块的原子性（哪怕只有一行，但依赖外部状态或需锁保护临界资源）。
容易被忽略的关键细节
volatile 的效果不是靠“强制刷主存”这种直觉实现的，而是通过底层内存屏障（Memory Barrier）约束 CPU 缓存行为和编译器优化。这意味着：
- 它对 long/double 类型 的 64 位读写是原子的（JVM 规范保证），但对引用类型或普通 int 并不提供额外原子保障；
- 它不能阻止其他非 volatile 变量的重排序“穿插”进来——只有对 volatile 变量本身的读写操作前后有屏障约束；
- 它无法替代 happens-before 关系中的锁释放/获取、线程启动/终止等完整语义，仅构成其中一种建立方式。
实际选型时，先问自己：这个变量是否永远只有一个线程写？是否所有读操作都不依赖它的旧值？是否不需要和其他操作组成原子单元？三个答案都是“是”，volatile 才真正安全可用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
