volatile能解决布尔开关可见性问题，因其禁止指令重排序，并强制每次读取从主内存加载、每次写入立即刷新到主内存，确保多线程间状态变更即时可见。
在 Java 多线程中，volatile 是保证布尔开关（如 running = true/false）状态变更**即时可见性**最轻量、最常用的方式——它不提供原子性，但恰好满足“读写单个布尔变量”这一场景的核心需求。
为什么 volatile 能解决布尔开关的可见性问题
volatile 关键字会禁止 JVM 对该变量进行指令重排序，并强制每次读取都从主内存加载最新值，每次写入都立即刷新到主内存。普通变量可能被线程缓存在本地 CPU 寄存器或高速缓存中，导致一个线程修改了值，另一个线程长期看不到变化。
例如：主线程设置 flag = false 后，工作线程仍在循环执行 while (flag) {...}，若 flag 非 volatile，该线程可能永远不退出——因为它的本地副本从未更新。
正确声明和使用 volatile 布尔变量
只需在字段声明时加上 volatile 修饰符，无需同步块或锁：
- 声明必须是 实例变量或静态变量，不能是局部变量（局部变量本就不共享，无可见性问题）
- 推荐用 private + volatile，避免外部直接赋值破坏语义
- 读写操作本身是原子的（boolean 类型读写天然原子），所以无需额外同步
示例：
private volatile boolean running = true;
// 线程中
while (running) {
doWork();
}
volatile 的边界：什么它不能做
volatile 仅保障**单次读/写的可见性与有序性**，不适用于需要复合操作的场景：
-
不保证原子性：比如
counter++（读+改+写三步）即使counter是 volatile，仍可能丢失更新 -
不解决竞态条件：如 “先检查再设置”（check-then-act）逻辑：
if (!done) done = true;这仍是非线程安全的 -
不控制执行顺序的全部范围：它只禁止与该变量相关的重排序，不能替代
synchronized或Lock来保护临界区代码块
对比其他方案：什么时候该选 volatile
对纯布尔开关类标志位（启动/停止/暂停/完成等），volatile 是最优解：
- 比
synchronized开销小得多，无阻塞、无上下文切换 - 比
AtomicBoolean更简洁（后者适合需要 CAS 操作或 getAndSet 等原子方法的场景） - 比轮询加 sleep 更高效且响应及时（volatile 写入后，其他线程下一次读就能看到，无需等待）
只有当开关逻辑涉及多个变量协同、或需与其他操作构成原子块时，才考虑升级为 synchronized 或显式锁。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
