volatile 保证 running 标志的可见性和禁止重排序，避免分发线程因缓存不一致或 jit 优化而无法及时退出；普通 boolean 无此保障，可能导致无限循环。
volatile 在轻量级事件总线中不直接“控制”分发线程的运行状态，而是**安全地发布和读取线程的运行标志（如 running）**，确保状态变更对所有线程可见，避免因指令重排序或 CPU 缓存不一致导致分发线程无法及时停止。
为什么需要 volatile 而不是普通 boolean？
事件总线通常有一个后台线程（如 EventDispatcher）持续从队列拉取事件并分发。它靠一个布尔标志（如 private boolean running = true;）控制循环：
while (running) {
Event event = queue.poll();
if (event != null) dispatch(event);
else Thread.sleep(1);
}
若 running 不是 volatile，其他线程调用 shutdown() 设置 running = false 后，分发线程可能因以下原因永远不退出：
- CPU 缓存未刷新，分发线程一直读到旧值
true - JIT 编译器将
running优化为寄存器中的常量（循环内不重新读内存） - 写操作被重排序，导致
running = false的效果延迟对其他线程可见
正确声明和使用 volatile 标志
只需将标志字段声明为 volatile，无需加锁：
private volatile boolean running = true;
public void start() {
new Thread(() -> {
while (running) { // 每次都从主内存读取最新值
Event e = queue.poll();
if (e != null) dispatch(e);
}
}).start();
}
public void shutdown() {
running = false; // 立即对分发线程可见
}
注意：volatile 保证可见性和禁止重排序，但不保证原子性。如果需复合操作（如“检查再设置”），仍需 synchronized 或 AtomicBoolean。
和 AtomicBoolean 的区别与选择
对于单纯启停控制，volatile boolean 已足够，更轻量；若需 CAS 操作（如 compareAndSet）、或与其他原子操作组合，选 AtomicBoolean：
-
volatile boolean：语义清晰、开销最小，适合“单写多读”的启停场景 -
AtomicBoolean：提供原子方法，但内部仍基于 volatile + Unsafe，无必要时不引入额外对象
不能依赖 volatile 做线程同步的误区
volatile 无法替代锁来保护共享资源访问。例如：
- ❌ 错误：仅用 volatile 保证
queue的可见性 ——BlockingQueue本身已线程安全，无需额外 volatile - ❌ 错误：用 volatile 实现“双重检查锁定”式启动 —— 若分发线程初始化涉及多个步骤，仍需同步块保证构造完成后再发布
- ✅ 正确：volatile 仅用于简单状态标志，配合已线程安全的队列（如
LinkedBlockingQueue）和明确的 shutdown 协议
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
