volatile写通过内存屏障触发MESI协议使其他核心缓存行失效，并非直接写主存；volatile读通过读屏障禁止重排序并强制重新加载，确保看到的值是最新提交的。
volatile写操作如何触发缓存行刷新
Java中volatile变量的写操作，会在字节码层面插入putstatic或putfield指令，并在JVM生成的汇编中插入内存屏障（如x86下的lock addl $0x0,(%rsp)）。这个lock前缀强制将当前核心的写缓冲区刷入L3缓存，并使其他CPU核心的对应缓存行失效。不是“立即同步到主存”，而是通过MESI协议触发其他核心的缓存一致性动作。
常见误解是认为volatile写会直接写主存——实际上现代CPU从不直接写主存，所有写都经缓存；真正起作用的是缓存一致性协议+内存屏障的组合。
volatile读为何能读到最新值
volatile读操作会插入读屏障（如x86下虽无显式指令，但JVM会禁止相关重排序），确保该读不会被重排到屏障前的任何读/写之后，同时强制从缓存（而非寄存器或重排序缓冲区）重新加载值。关键点在于：它不保证“读完立刻看到别人刚写的值”，而是保证“一旦看到，就是最新提交的值”——前提是对方写的是volatile变量且已通过缓存一致性传播完成。
- 若线程A写
volatile int flag = 1，线程B读flag，B可能短暂看到0（因缓存未及时失效），但一旦看到1，就代表A的整个写前操作（包括非volatile字段）对B可见（happens-before语义） - 没有
volatile读，JIT可能把变量提升为寄存器局部副本，导致永远读不到更新
volatile不能保证原子性的典型场景
volatile只对单个读或单个写提供可见性与有序性保障，不保证复合操作的原子性。最常踩坑的是自增：i++本质是读-改-写三步，即使i是volatile，中间仍可能被其他线程打断。
立即学习“Java免费学习笔记（深入）”；
以下代码依然存在竞态：
public class Counter {
private volatile int count = 0;
public void increment() {
count++; // 非原子！
}
}
正确做法：用AtomicInteger、synchronized，或明确用Unsafe.compareAndSwapInt。
volatile与synchronized的内存语义差异
synchronized块的进入和退出分别对应monitorenter/monitorexit，隐含全屏障（Full Barrier），不仅保证临界区内变量的可见性，还保证锁释放前的所有写对后续获取该锁的线程可见（更严格的happens-before链）。而volatile只在读/写单个变量时生效，不构成代码块边界。
性能上，volatile开销远低于锁（无上下文切换、无阻塞），但适用面窄——它解决不了竞态条件，只解决“一个线程改了，另一个线程能不能及时知道”的问题。
容易被忽略的是：volatile写 + volatile读 构成的happens-before关系，仅在**同一变量**上成立；跨变量的顺序无法靠多个volatile变量推导（例如volatile int a; volatile int b;，不能假设a写后b读就一定看到a的最新值）。
