Java内存模型（JMM）是一套抽象规范，旨在通过happens-before规则、volatile、synchronized等机制解决多核CPU下缓存不一致导致的可见性、原子性和有序性问题。
Java 内存模型（JMM）不是硬件，而是一套抽象规范，它的核心任务之一，就是为程序员提供一套可预测的语义，来应对底层硬件——尤其是 CPU 寄存器、各级高速缓存（L1/L2/L3）、主内存之间天然存在的数据不一致难题。
这个难题不是 Java 独有，而是多核 CPU 架构下绕不开的物理现实：每个 CPU 核心都有自己的寄存器和私有缓存，数据在写入主内存前可能长期滞留在本地缓存里；不同线程若操作同一变量，就可能各自读到旧值、各自修改、再各自写回——结果丢失更新。
JMM 的应对方式，不是去改变硬件，而是在硬件之上建一层语义契约，通过定义“可见性”“原子性”“有序性”的边界，让开发者能用有限的同步手段（如 volatile、synchronized、final、锁、原子类），控制哪些操作必须刷新到主存、哪些变更必须对其他线程立即可见。
寄存器与缓存是“快但私有”的，主内存是“慢但共享”的
CPU 执行指令时，优先从寄存器取数；寄存器不够就查 L1 缓存；L1 没命中再查 L2、L3，最后才访问主内存。这个过程对单线程透明高效，但对多线程意味着：
- 一个线程把 i=1 改成 i=2，只写到了自己核心的 L1 缓存，还没刷到主内存；
- 另一个线程在同一时刻从自己核心的 L1 缓存读 i，拿到的仍是 1；
- 两者都执行 i++ 后写回，最终主内存只留下 i=2，而不是预期的 i=3。
JMM 用 happens-before 规则约束重排序与可见性
它不强制硬件实时同步，而是规定：只要两个操作之间存在 happens-before 关系，那么前一个操作的结果对后一个操作就是可见的，且执行顺序不能被重排序打乱。例如：
- 对 volatile 变量的写，happens-before 后续对该变量的读；
- 进入 synchronized 块前的写，happens-before 退出该块后的读；
- 主线程启动子线程前的写，happens-before 子线程的任何操作。
这些规则背后，JVM 会根据目标平台（x86/ARM）插入适当的内存屏障（Memory Barrier），告诉 CPU：“此处之后的读写不能越过此处重排”，并触发缓存同步动作（如使其他核心的对应缓存行失效）。
立即学习“Java免费学习笔记（深入）”；
volatile 是 JMM 与硬件协作最典型的桥梁
声明一个变量为 volatile，并不只是禁止编译器优化。它要求：
- 每次读都从主内存或最新缓存（经 MESI 协议保证）加载，不使用寄存器或旧缓存副本；
- 每次写都立即刷新到主内存，并向其他核心发送失效通知（MESI 中的 Invalidate）；
- 编译器和 CPU 都不得对该变量的读写进行重排序（借助内存屏障）。
这相当于在 Java 层面“申请了一条直通主内存的快速通道”，绕过普通变量可能卡在本地缓存的风险。
同步机制本质是协调硬件缓存状态
synchronized 不仅互斥执行，更关键的是：
- 进入时，清空当前线程本地缓存中与锁对象相关的一切变量副本（强制后续读从主存或最新缓存加载）；
- 退出时，将所有修改强制刷回主内存，并确保其他线程能看到最新状态（MESI 的 Write-Back + Broadcast）。
锁的获取与释放，就是一次显式的缓存同步事件。
不复杂但容易忽略
