volatile通过强制读写直通主内存、建立happens-before关系及插入内存屏障来保障可见性与有序性，但不保证复合操作原子性或引用对象内部状态同步。
Java 内存模型（JMM）不靠“时间先后”保证变量修改对其他线程可见，而是靠 happens-before 关系建立逻辑顺序约束。volatile 是其中最轻量、最常用的可见性保障手段之一。
volatile 怎么强制读写直通主内存
每个线程有自己的工作内存（如 CPU 缓存或寄存器），普通变量可能长期停留在其中，不及时同步到主内存。volatile 改变这一行为：
- 每次读 volatile 变量：必须从主内存重新加载，禁止使用本地缓存副本
- 每次写 volatile 变量：必须立即刷新回主内存，不延迟、不合并
- 写操作还会触发缓存一致性协议（如 MESI），使其他 CPU 中该变量所在缓存行失效
volatile 写-读构成 happens-before 链
对一个 volatile 变量的写操作，happens-before 于后续任意线程对该变量的读操作。这意味着：
- 只要线程 B 读到了线程 A 写入的 volatile 值，那么线程 A 在该写操作之前做的所有内存操作（包括对其他普通变量的写），对线程 B 都是可见的
- 这个“之前”指同一个线程内程序顺序上的前置操作，不是代码行号顺序
- 例如：x = 42; flag = true;（flag 是 volatile），线程 B 看到 flag == true 时，x 的值一定是 42，不会是未初始化状态
volatile 同时禁止指令重排序
JVM 和 CPU 会对无依赖指令做重排序优化，这在多线程下可能导致逻辑错误。volatile 通过插入内存屏障（Memory Barrier）阻止这类乱序：
立即学习“Java免费学习笔记（深入）”；
- 写 volatile 插入 StoreStore + StoreLoad 屏障
- 读 volatile 插入 LoadLoad + LoadStore 屏障
- 效果等价于 synchronized 的 unlock-lock：volatile 写 ≈ 锁释放，volatile 读 ≈ 锁获取
volatile 的边界与常见误用
它解决的是“改了但对方看不到”的问题，但有明确限制：
- 只保障单次读/写本身的可见性，不延伸到复合操作：✅ flag = true 或 if (flag) 安全；❌ count++（含读+改+写）或 if (flag && data != null) 不安全（data 不受保护）
- volatile 引用类型（如 volatile List<String>）只保证引用地址变更可见，不保证内部元素状态同步
- 它不提供互斥，不阻塞线程，也不保证原子性——不能替代 synchronized 或 AtomicInteger 处理计数、状态转换等场景
