volatile通过强制内存同步和约束执行顺序实现多线程通信，确保写操作对读线程可见且建立happens-before关系，适用于状态标志、安全发布等无锁场景，但不保证原子性、无阻塞能力。
volatile 实现多线程通信，本质不是“主动发送消息”，而是通过**强制内存同步 + 约束执行顺序**，让一个线程的写操作对另一个线程“可感知、可依赖”。它不提供锁或等待机制，但构建了一条轻量、确定的通信通道。
可见性：每次读都拉取最新值，每次写都立即落盘
Java 内存模型（JMM）规定：线程不能长期依赖自己工作内存里的副本。volatile 变量的读写绕过缓存优化：
- 写 volatile 变量时，JVM 插入 StoreStore + StoreLoad 内存屏障，确保之前所有普通写操作已刷新到主内存，且该 volatile 写本身也立即写入主内存
- 读 volatile 变量时，JVM 插入 LoadLoad + LoadStore 屏障，强制从主内存重新加载，跳过线程本地缓存
- 效果是：线程 A 写 flag = true（volatile），线程 B 后续读 flag，一定能读到 true —— 不是“立刻”，而是“一旦读发生，就一定看到最新”
有序性：用 happens-before 建立跨线程因果链
volatile 的真正威力在于它参与构建 happens-before 关系：
- volatile 写操作 happens-before 后续任意线程对该变量的读操作
- 结合程序次序规则（同一线程中前操作 happens-before 后操作），可推导出：写 volatile 前的所有操作，对读 volatile 后的操作“可见”
- 例如：a = 1; ready = true;（ready 是 volatile），线程 B 看到 ready == true 时，a = 1 一定已完成且对其可见 —— 这就是通信的语义基础
无锁通信的典型模式
volatile 适合传递状态信号，而非共享数据计算：
- 状态标志：如 stop = true 控制循环退出，一个线程改，多个线程读，无需互斥
- 对象安全发布：单例 instance 被 volatile 修饰后，构造完成的写与后续读之间形成屏障，避免其他线程看到半初始化对象
- 配合其他同步工具：如作为轮询条件与 wait/notify 或 LockSupport.park 结合，实现协作式等待
它不做什么：明确边界防误用
volatile 不是万能通信机制，以下情况它无法胜任：
- 不保证复合操作原子性：count++（读-改-写三步）即使 count 是 volatile，仍会丢失更新
- 不提供阻塞或唤醒能力：无法替代 synchronized 或 Condition 实现线程等待/通知
- 不解决竞态条件本身：只确保“看到什么”，不控制“谁先做”——需要锁或 CAS 来协调执行时机
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
