volatile通过强制主内存读写和内存屏障保障可见性与有序性，适用于单写多读的开关场景，但不保证原子性，阻塞状态需配合interrupt()唤醒。
因为普通变量在多线程下可能被缓存、不刷新、被重排序，导致其他线程永远看不到修改；而 volatile 强制每次读都从主内存加载、每次写都立即刷回主内存，并插入内存屏障防止重排，让“设标志→被感知→退出”这个链条可靠成立。
可见性保障：避免本地缓存导致的“看不见”
CPU 和 JVM 会给每个线程分配工作内存（如寄存器、L1 缓存），普通变量修改后可能只更新在线程自己的缓存里。另一个线程持续读自己缓存中的旧值，就会无限循环等待——比如 while (!flag) 永远不退出。
volatile 破坏这种隔离：
- 写操作：
flag = true会强制把新值同步到主内存 - 读操作：
while (!flag)每次都绕过缓存，直接从主内存取最新值 - 所有监听该标志的线程，下一次读就能 100% 看到变更
有序性保障：防止指令重排破坏逻辑顺序
编译器或 CPU 可能优化代码顺序。例如设置标志和释放资源这两步，若被重排，可能导致标志已设但清理未完成，线程提前退出引发资源泄漏。
volatile 通过内存屏障约束执行顺序：
- 写 volatile 变量前的所有操作，不会被重排到它之后
- 读 volatile 变量后的所有操作，不会被重排到它之前
- 确保“先做完事，再改标志”或“先查标志，再执行业务”的语义不被破坏
适用边界清晰：专为“纯开关”设计，不越界就不出错
volatile 不提供原子性，所以它只安全用于：
- 单一赋值操作，如
running = false、shutdownRequested = true - 不依赖其他变量状态，比如不要求
started == true必须先于ready == true - 多线程只读、至多一个线程写——典型的启停控制、生命周期管理场景
只要满足这两个前提，volatile 就是轻量、高效、无锁的线程通信方式；一旦涉及 count++ 或状态组合判断，就必须换用 synchronized 或原子类。
配合阻塞调用时仍需 interrupt() 支撑
如果线程在 BlockingQueue.take()、Thread.sleep() 等阻塞方法中挂起，光靠 volatile 标志无法唤醒它。
正确做法是：
- 主线程设
shutdownRequested = true同时调用workerThread.interrupt() - 工作线程捕获
InterruptedException，并检查标志决定是否彻底退出 - 或改用带超时的轮询，如
queue.poll(100, MILLISECONDS)，每次循环都检查 volatile 标志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
