volatile解决多线程内存可见性问题，保证写操作立即刷回主存、读操作强制从主存获取，但不保证原子性与互斥，适用于独立布尔标志或状态开关等场景。
volatile 解决的是多线程下的内存可见性问题
当多个线程同时读写同一个实例变量时，volatile 保证一个线程对变量的修改能立即被其他线程看到。它不解决原子性（比如 i++ 仍会出错），也不提供互斥，只确保“写完立刻刷回主存，读时一定从主存取”。没有 volatile，JVM 可能将变量缓存在线程本地的 CPU 寄存器或高速缓存中，导致其他线程长期看不到更新。
volatile 不能替代 synchronized 的典型场景
以下操作即使加了 volatile 依然线程不安全：
-
volatile int count = 0;，然后多个线程执行count++—— 因为count++是“读-改-写”三步，非原子 - 依赖前值的条件更新，如
if (flag) { doSomething(); flag = false; }，即使flag是volatile，doSomething()和赋值之间无锁保护，可能重入或漏执行 - 对象引用虽
volatile，但对象内部字段未加保护：例如volatile List<string> list = new ArrayList();</string>，后续调用list.add(...)不受volatile保障
volatile 的内存语义和编译器优化限制
volatile 写操作具有“释放”（release）语义，读操作具有“获取”（acquire）语义，这会禁止某些重排序：
- 编译器不会把
volatile写之前的普通写操作重排到其后 - 不会把
volatile读之后的普通读操作重排到其前 - 但它不阻止非 volatile 操作之间的重排序，也不构成 happens-before 关系链的完整闭环（比如两个 volatile 写之间不自动建立顺序）
这意味着：仅靠 volatile 无法实现安全的双重检查锁单例（DCL），必须配合 final 字段或显式同步。
立即学习“Java免费学习笔记（深入）”；
什么时候该用 volatile 而不是 synchronized
适用场景非常明确，满足全部以下条件才考虑：
- 变量是布尔标志、状态开关、简单数值等基本类型或不可变对象引用
- 写操作不依赖当前值（即不出现
x = x + 1或if (x == 1) x = 2这类读-写耦合） - 变量独立，不参与复合逻辑（比如不和其他变量组成不变式）
- 需要低开销的可见性通知，且能接受无锁带来的弱一致性边界
典型例子：
public class TaskRunner {
private volatile boolean running = false;
public void start() {
running = true;
new Thread(() -> {
while (running) {
// do work
}
}).start();
}
public void stop() {
running = false; // 其他线程立即可见
}
}这里 running 仅用于控制循环，每次读写都独立，volatile 刚好够用。
最容易被忽略的一点：volatile 对 long 和 double 的读写是原子的（JVM 规范保证），但不意味着它们的复合操作（如 l++）安全；另外，32 位 JVM 上非 volatile 的 long/double 读写可能被拆成两次 32 位操作，产生“半个值”现象——而 volatile 能杜绝这点。
