volatile变量规则规定：对一个volatile变量的写操作happens-before后续对该变量的读操作；只要线程B读到线程A写入的volatile值，A在此前对普通变量的修改（如data=42）对B也必然可见，该语义由内存屏障和happens-before传递性共同保证。
volatile 变量规则通过建立明确的 happens-before 关系，让写操作的结果对后续读操作可见，而不是靠“立刻同步”或“时间先后”。关键在于：只要线程 B 读到了线程 A 写入的 volatile 值，那么 A 在该写之前做的所有内存操作（包括对普通变量的修改），B 就一定能看见。
volatile 写-读天然构成 happens-before 链
Java 内存模型（JMM）规定：对一个 volatile 变量的写操作，happens-before 后续对该变量的读操作。这个“后续”不要求代码紧邻，也不依赖时钟时间，只看逻辑执行顺序——即读操作确实发生在写操作之后（哪怕中间隔了其他语句）。
- 线程 A 执行 data = 42; flag = true;（flag 是 volatile）
- 线程 B 执行 if (flag) { System.out.println(data); }
- 只要 B 看到 flag == true，JMM 就保证它看到的 data 一定是 42，不会是初始值 0 或未定义状态
靠内存屏障实现语义约束
volatile 的效果不是凭空而来，JVM 在编译和运行时会插入特定内存屏障，阻止重排序并强制主内存交互：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 写 volatile 时插入 StoreStore + StoreLoad 屏障：确保前面的普通写（如 data=42）已刷入主内存，且不被重排到 volatile 写之后
- 读 volatile 时插入 LoadLoad + LoadStore 屏障：确保从主内存加载最新值，且后面的读写不能被重排到该读之前
- 这些屏障配合 CPU 缓存一致性协议（如 MESI），使其他线程能及时感知变更
依赖程序顺序与传递性扩展可见范围
volatile 本身只保障“写 → 读”这一对操作的 happens-before，但结合程序顺序规则和传递性，就能把可见性延伸到其他变量：
- A 中 data = 42 → 程序顺序 → flag = true（volatile 写）
- flag = true → volatile 规则 → B 中 if(flag)（volatile 读）
- B 中 if(flag) → 程序顺序 → System.out.println(data)
- 经传递性，A 写 data 就 happens-before B 读 data，从而保证可见
注意它不做什么
volatile 是轻量级同步工具，有明确边界：
- 不保证复合操作原子性：比如 count++ 即使 count 是 volatile，仍可能丢失更新
- 不强制“立即读到”：如果 B 还没读到 flag 的新值，JMM 不承诺何时可见；但一旦读到，就一定看到全部前置操作
- 不替代锁的互斥能力：它解决可见性和有序性，不解决竞态条件下的执行互斥
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
