volatile通过强制每次读取从主内存加载、每次写入立即刷回并使其他缓存失效，解决“修改不可见”问题；但它不保证复合操作原子性，也不能替代synchronized处理多步逻辑或状态协同。
volatile 能让一个线程对变量的修改，被其他线程“立刻看到”，但仅限于单次读或写操作本身；它不解决复合逻辑竞争，也不保证原子性。
volatile 为什么能解决“改了但看不到”的问题
Java 线程默认把变量缓存在自己的工作内存（如 CPU 寄存器、L1/L2 缓存）里，而不是每次都去主内存读写。这就导致：线程 A 把 flag = true 写回主内存前，线程 B 还在用自己缓存里的 false 值死循环。
volatile 强制两点：
- 每次读
flag，都从主内存加载最新值，不走本地缓存 - 每次写
flag，都立即刷回主内存，并触发其他 CPU 缓存行失效（靠 lock 指令 + 缓存一致性协议）
所以只要变量是 volatile 修饰的，就不会出现“主线程永远卡在 while (flag == false)”这种现象。
volatile 修饰 boolean 作为开关时的典型写法
这是最安全、最常见、也最容易出错的用法场景。关键在于：只用于“设值 + 检查”，不掺杂其他操作。
正确示例：
public class Worker {
private volatile boolean running = true;
public void run() {
while (running) { // 每次都从主内存读
doWork();
}
}
public void shutdown() {
running = false; // 立即写回主内存
}
}
常见错误：
- 在
while (running)循环体里又调用setRunning(false)—— 这不是 volatile 能保的，是逻辑耦合问题 - 把
running和别的非 volatile 字段混在一起做状态判断，比如if (running && count > 0)，后者不可见 - 用
volatile Boolean（包装类）代替volatile boolean：自动拆箱可能触发空指针，且对象引用虽可见，但null状态本身不带同步语义
volatile 修饰引用类型时的可见性边界
volatile List<string> list</string> 只保证 list 这个引用地址的变更对其他线程可见，比如 list = new ArrayList()；但它完全不管 list.add("x") 之后内容是否可见。
换句话说：
- ✅ 其他线程能看到
list指向了一个新对象 - ❌ 其他线程不一定能看到这个新对象内部的元素（除非该 List 实现本身线程安全，如
CopyOnWriteArrayList） - ⚠️ 如果你用
volatile修饰单例引用（如volatile Singleton instance），是为了防止“对象构造未完成就被其他线程拿到引用”，这和字段可见性是两个层面的问题，依赖的是禁止重排序语义，不是单纯的可见性
volatile 不能替代 synchronized 的地方
以下操作即使变量是 volatile，依然线程不安全：
-
counter++：本质是读-改-写三步，volatile 只保证每一步的读/写可见，不保证三步整体原子 -
if (flag) { doSomething(); }：flag 读取和doSomething()执行之间有时间窗口，其他线程可能在这期间把 flag 改回去 - 多个 volatile 变量组合成业务状态，比如
volatile int x, y;，然后期望x == 1 && y == 2表示某个一致状态 —— 它们各自可见，但不构成“状态快照”
真正容易被忽略的是：volatile 解决的是“值更新传播延迟”，不是“执行时机协调”。一旦涉及多步、条件、或与其他资源联动，就必须升级到 synchronized、Lock 或 AtomicXxx 类。
