内存屏障是解决多线程可见性与重排序问题的核心机制：它通过在volatile读写时插入loadload/loadstore/storestore/storeload等屏障，强制缓存同步和禁止指令重排，从而保障happens-before语义的底层实现。
内存屏障和可见性不是两个独立概念，而是同一机制的两面：内存屏障是硬件与JVM实现可见性的具体手段，可见性是它要解决的核心问题。
为什么需要内存屏障？
现代CPU有多级缓存（L1/L2私有、L3共享），线程A修改变量后，可能只写入自己核心的缓存，还没刷到主内存；线程B去读时，仍从自己的缓存或主内存拿到旧值——这就导致“改了但别人看不见”。同时，编译器和CPU为优化性能会重排指令，比如把“赋值”和“后续读操作”调换顺序，破坏逻辑预期。内存屏障就是用来约束这种行为的指令级“路标”。
内存屏障怎么保证可见性？
对 volatile 变量的读写，JVM 会插入对应屏障：
- 写 volatile 变量时：插入 StoreStore + StoreLoad 屏障。前者确保前面所有写操作完成后再执行该 volatile 写；后者强制该写立即刷新到主内存，并让其他 CPU 缓存中对应数据失效。
- 读 volatile 变量时：插入 LoadLoad + LoadStore 屏障。前者确保该读之前所有读已完成；后者强制从主内存（而非本地缓存）加载最新值，并禁止后续读/写越过它提前执行。
它和 happens-before 是什么关系？
happens-before 是 JMM 给程序员的高级抽象承诺，而内存屏障是 JVM 在底层兑现这个承诺的技术方式。例如，“volatile 写 happens-before 后续 volatile 读”这条规则，背后就是靠写端的 StoreLoad 和读端的 LoadLoad 共同保障的——前者把修改落盘，后者把新值拉进来，中间不被绕过。
不用 volatile 就一定不可见吗？
不一定，但不可控。synchronized 进入和退出时也隐式插入屏障（进入：LoadLoad+LoadStore；退出：StoreStore+StoreLoad），同样能保证临界区内外的可见性。普通变量则完全无屏障保护，是否可见取决于硬件缓存同步时机，结果不确定。所以，状态标志、单例初始化等轻量场景优先用 volatile；涉及复合操作（如 count++）必须用 synchronized 或原子类。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
