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