volatile通过内存屏障禁止重排序、借助缓存一致性协议保障可见性，实现轻量级同步；但不保证复合操作原子性，适用于状态开关、双重检查单例等一写多读场景。
volatile 实现轻量级同步，靠的是对 Java 内存模型（JMM）的精准干预，不加锁、不阻塞线程，只聚焦两个关键点：让变量修改对所有线程立即可见，同时禁止特定方向的指令重排序。
靠内存屏障禁止重排序
编译器和 CPU 为提升性能会重排指令，但 volatile 写操作前后会插入内存屏障：
- 写屏障（Store Barrier）：确保该 volatile 变量写入前的所有操作，都已完成并刷新到主内存，不能被移到写之后；
- 读屏障（Load Barrier）：确保该 volatile 变量读取后的所有操作，都必须等读完成后再执行，不能被提前到读之前。
这种屏障不是软件“等待”，而是向 CPU 发出的硬件级指令约束，开销远低于锁的上下文切换。
靠缓存一致性协议保障可见性
volatile 变量每次写，都会触发底层 MESI 等缓存一致性协议：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 当前线程把新值写入主内存；
- 同时使其他 CPU 核心中该变量的缓存行失效；
- 下次其他线程读这个变量时，强制从主内存重新加载，而不是用过期的本地缓存副本。
整个过程无需锁参与，也没有线程挂起或唤醒，所以响应快、吞吐高。
只管单变量读写，不保复合操作原子性
volatile 不提供原子性，这是它“轻量”的代价，也是使用边界：
- 像 flag = true、status = STOPPED 这种单纯赋值，是安全且高效的；
- 但 counter++（读-改-写三步）即使变量被 volatile 修饰，依然可能因中间态竞争而丢失更新；
- 需要原子性时，得换用 AtomicInteger 或 synchronized。
典型落地场景就是状态开关和双重检查单例
它最适合“一写多读”、无依赖的布尔或引用型标记：
- 线程控制开关：volatile boolean running = true；配合 while(running) 实现优雅停止；
- 单例初始化：private static volatile Singleton instance；在双重检查锁中防止未完全构造的对象被其他线程看到；
- 配置热更新：volatile String configVersion；避免每次读配置都加锁，又保证新值及时生效。
不复杂但容易忽略细节。
