内存可见性本质是解决线程修改共享变量后何时被其他线程看到的问题，由多核cpu缓存与jmm共同约束；mesi协议不保证即时可见，jmm通过happens-before规则（如volatile写读、synchronized锁释放获取）插入内存屏障实现可见性保障。
内存可见性在 Java 中，本质是解决“一个线程对共享变量的修改，何时、以何种方式被其他线程看到”的问题；它不是 Java 独有的概念，而是由底层硬件（多核 CPU + 缓存）与 JVM 内存模型（JMM）共同协作约束的结果。
多核 CPU 缓存如何引发可见性问题
现代 CPU 每个核心都有自己的 L1/L2 私有缓存，共享 L3 缓存或主存。当线程 A 在核心 1 上修改变量 x = 1，该写操作可能只更新到核心 1 的 L1 缓存中，尚未刷回 L3 或主存；此时线程 B 在核心 2 上读 x，可能仍从自己缓存中读到旧值（比如 0）——这就是典型的可见性失效。
虽然硬件层面有缓存一致性协议（如 Intel 的 MESI），但它只保证“写操作最终会传播并使其他缓存行失效”，并不保证“立即传播”或“按程序顺序传播”。也就是说：
- MESI 能确保同一变量不会同时在两个缓存中处于 Modified 状态；
- 但它不承诺写操作对其他核心“即时可见”，也不保证多个写操作之间的全局顺序；
- 编译器重排序和 CPU 指令重排序还会进一步模糊执行时序。
JMM 如何用 happens-before 定义可见性边界
Java 内存模型（JMM）不直接描述硬件行为，而是抽象出一套语义规则，其中 happens-before 是核心：如果操作 A happens-before 操作 B，那么 A 的结果（如变量写入）对 B 是可见的。
常见建立 happens-before 的方式包括：
- 同一个线程内，按代码顺序：前面的语句 happens-before 后面的语句（即使被重排序，JVM 也保证语义等价）；
- 对 volatile 变量的写 happens-before 后续对该变量的读；
- 解锁（synchronized 块结束） happens-before 后续对同一锁的加锁；
- 线程 start() happens-before 该线程中任意动作；线程中所有动作 happens-before 其 join() 返回。
这些规则不是“强制刷新缓存”，而是告诉 JVM：“在此处插入必要的内存屏障（memory barrier）”，从而限制编译器/CPU 的重排序，并触发对应缓存同步动作（如 StoreLoad 屏障 + flush store buffer / invalidate remote cache line）。
volatile 关键字背后的硬件协同机制
声明 volatile int flag = 0; 后：
- 写 volatile 变量时，JVM 插入 StoreStore + StoreLoad 屏障，强制将该写入刷出本地 store buffer，并向总线/互连发送“缓存行失效请求”（MESI 中的 Invalidate）；
- 读 volatile 变量时，插入 LoadLoad + LoadStore 屏障，确保后续读操作不会被提前，且必须从主存或最新缓存行中重新加载（即 bypass 旧缓存副本）；
- 注意：volatile 不保证复合操作原子性（如 i++），仅保障单次读/写的可见性与有序性。
synchronized 与 final 字段的可见性保障
synchronized 的可见性来自“锁释放-获取”的 happens-before 规则：退出 synchronized 块时，JVM 会强制将工作内存中所有共享变量刷新回主存；进入时，则清空本地缓存，强制从主存或一致缓存中重新加载——这本质上是一次批量的缓存同步。
final 字段 的特殊性在于：对象构造完成且引用未逸出的前提下，JMM 保证其他线程通过该引用读取 final 字段时，一定能看到构造器中写入的值。这是通过在构造器结尾插入 StoreStore 屏障实现的，防止 final 字段写入被重排序到对象引用发布之后。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
