volatile通过强制读写主内存和插入内存屏障，确保变量修改对其他线程立即可见，并建立happens-before关系以传递跨变量可见性，但不保证原子性或复合操作一致性。
volatile 在无锁设计中不“保证”可见性，而是强制实现可见性——它通过 JVM 和硬件协同机制，让线程绕过本地缓存，直接与主内存交互，从而消除因缓存不一致导致的读旧值问题。
volatile 如何让变量对其他线程“立刻可见”
Java 内存模型（JMM）规定：线程操作共享变量需先从主内存加载到工作内存，修改后再写回。普通变量可能长期停留在 CPU 缓存或寄存器中；而 volatile 变量每次读写都触发以下动作：
- 写 volatile 变量时：JVM 插入 Store 屏障，强制将当前线程工作内存中的最新值刷新到主内存，并通过 lock 前缀指令触发缓存一致性协议（如 MESI），使其他 CPU 缓存中对应缓存行失效；
- 读 volatile 变量时：JVM 插入 Load 屏障，禁止使用工作内存中的缓存副本，必须从主内存重新加载最新值。
这相当于在多核系统中建立了一条“直通主内存”的读写通道，无需加锁即可同步状态。
典型无锁场景：状态标志位控制线程生命周期
这是 volatile 最常用、最直观的无锁应用。例如后台任务启停控制：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 用
private static volatile boolean running = true;作为开关； - 工作线程循环检查
while (running) { ... }； - 主线程调用
running = false;后，工作线程下一次读取就能看到新值并退出。
没有 volatile，JIT 编译器可能将 running 优化为常量（如死循环 while(true)），或线程一直读缓存旧值，导致无法响应停止指令。
配合 happens-before 规则构建安全的无锁逻辑
volatile 不仅解决单个变量可见性，还提供跨变量的可见性传递。JMM 规定：对 volatile 变量的写操作 happens-before 于后续对该变量的读操作。这意味着：
- 写 volatile 变量前的所有内存操作（包括对非 volatile 变量的写），对后续读该 volatile 变量的线程也可见；
- 例如：先设置
data = 42;，再写ready = true;（volatile），那么另一线程看到ready == true时，一定能看到data == 42。
这个特性支撑了无锁编程中“发布-订阅”式协作，比如生产者写数据 + 置标志，消费者读标志 + 读数据，无需锁也能保证数据正确性。
注意边界：它不解决原子性，也不替代锁的复合语义
volatile 是轻量级同步原语，但有明确局限：
- 不能用于
count++这类读-改-写操作（涉及三个步骤，非原子）； - 不能保护多个变量的“整体一致性”，比如两个 volatile 变量之间无顺序约束；
- 若需等待、条件判断或阻塞行为，仍需配合
LockSupport、AtomicInteger或显式锁。
它不是万能锁替代品，而是精准作用于“单一状态通知”和“安全发布”的关键工具。
