内存屏障是JVM插入的CPU指令，用于约束重排序、强制刷缓存、保障可见性与有序性；它解决多线程下因store buffer和指令乱序导致的读旧值或依赖变量不同步问题。
内存屏障是Java并发中保障多线程正确性的底层机制，不是Java语法，而是由JVM在编译时插入的CPU指令，用于约束重排序、强制刷缓存、确保可见性与有序性。
内存屏障解决什么问题
现代CPU为了性能，会做两件事：一是把写操作暂存在store buffer里异步刷主存，二是对读写指令乱序执行（比如先执行后面的读，再执行前面的写）。这在线程单干时没问题，但多线程共享变量时就容易出错——线程A改了值还没刷出去，线程B就读到了旧值；或者B看到变量更新了，却没看到它依赖的其他变量也更新了。
内存屏障就是告诉CPU：“这一行前后，不准乱动顺序，该刷的刷，该等的等”。
四种核心内存屏障类型
Java内存模型（JMM）抽象出四类屏障，对应不同读写组合的约束：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- StoreStore：确保前面所有普通写（store）完成之后，才执行后面的volatile写。防止普通变量写被“拖后”到volatile写之后。
- StoreLoad：最重的一道屏障。确保前面所有写（含volatile写）都刷入主内存后，才允许执行后面任何读操作。volatile写操作末尾一定会插这个屏障。
- LoadLoad：保证前面所有读（load）完成之后，才执行后面读操作。常出现在volatile读开头，确保先读到volatile变量，再读其他依赖变量。
- LoadStore：保证前面读操作全部完成，才执行后面写操作。用在volatile读之后立即要写其他变量的场景，避免写提前发生。
内存屏障怎么和volatile配合工作
volatile不是魔法，它的语义靠屏障落地：
- 对volatile变量写：JVM自动在写操作前加StoreStore，在写操作后加StoreLoad。
- 对volatile变量读：JVM自动在读操作前加LoadLoad，在读操作后加LoadStore。
- 所以volatile能保证“写后读”的可见性，也能防止相关指令被重排序，但它不保证原子性（比如i++仍是三步，需额外同步）。
它和synchronized、happens-before的关系
内存屏障是硬件/编译器层面的实现手段，happens-before是JMM定义的逻辑规则。比如：
- volatile写 happens-before 后续volatile读 → JVM通过StoreLoad + LoadLoad等屏障来兑现这条规则。
- synchronized解锁 happens-before 下一次加锁 → 解锁操作末尾也会插入StoreLoad屏障，确保临界区内的修改对下一个获取锁的线程可见。
换句话说，你写的代码符合happens-before规则，JVM就自动给你安排好对应的内存屏障。
基本上就这些。理解屏障不用死记指令名，关键是抓住目的：控制顺序、刷缓存、保可见。用好volatile和锁，就是在间接调度这些屏障。
