Java内存模型（JMM）是定义多线程下变量可见性、有序性及重排序规则的抽象规范，非物理内存布局；其核心为“主内存-工作内存”模型，通过volatile、synchronized和final提供不同强度的内存语义保障。
Java内存模型（JMM）不是物理内存布局
很多人一看到“内存模型”就下意识联想到堆、栈、方法区这些运行时数据区——这是常见误解。JMM 不描述 JVM 实际怎么分配内存，而是定义了多线程环境下，变量读写操作 在不同线程间如何可见、何时有序、哪些重排序被允许。它的核心是抽象的“主内存-工作内存”模型，每个线程有自己的工作内存（可理解为寄存器或CPU缓存的抽象），所有共享变量都存在于主内存中。
关键点在于：线程对变量的所有操作（读、写、加锁、解锁）都必须通过工作内存与主内存交互，不能直接读写主内存。这就引出了可见性、原子性、有序性三大问题。
volatile 关键字到底禁止了什么重排序？
volatile 是 JMM 最轻量级的同步机制，但它只保证两点：变量对所有线程的可见性，以及禁止特定类型的指令重排序。它不保证复合操作的原子性（比如 i++）。
编译器和处理器对 volatile 变量的读写有明确约束：
立即学习“Java免费学习笔记（深入）”；
- 写 volatile 变量前，其工作内存中所有变量的值必须刷新回主内存（相当于插入一个
StoreStore+StoreLoad屏障） - 读 volatile 变量后，其工作内存中所有变量的值必须从主内存重新加载（相当于插入一个
LoadLoad+LoadStore屏障） - 禁止对 volatile 读/写与普通读/写做重排序（但 volatile 读与 volatile 读之间、volatile 写与 volatile 写之间仍可能重排）
例如：volatile boolean flag = false; 后续的 int x = 10; 不会被重排到 flag = true 之前——这正是 DCL（双重检查锁定）中 instance = new Singleton() 需要 volatile 的根本原因。
synchronized 和 happens-before 规则怎么对应？
synchronized 的语义远不止“加锁”。在 JMM 中，它通过 happens-before 规则建立线程间的偏序关系：一个线程对锁的 unlock 操作 happens-before 另一个线程对该锁的 lock 操作。
这意味着：
- 退出同步块前，该线程工作内存中所有变量的修改都会刷新到主内存
- 进入同步块时，该线程会清空工作内存，并从主内存重新读取所有共享变量（包括非 volatile 的）
- 所以 synchronized 天然解决可见性、原子性和有序性三类问题
注意：synchronized 块的锁对象必须是同一个实例才有意义；锁的粒度影响性能，但不影响 JMM 语义本身。另外，wait()/notify() 也参与 happens-before 链——notify() happens-before 被唤醒线程的 wait() 返回。
final 字段的内存语义常被忽略
final 字段不只是“不可变”，它在构造完成那一刻就向其他线程提供了安全发布保障。JMM 规定：如果一个对象被正确构造（即构造过程中 this 引用未逸出），那么其他线程看到该对象的 final 字段时，一定能看到构造器中为其设置的值，且不会看到默认值（如 0、null）。
这个保障依赖于两个动作的禁止重排序：
- 禁止把 final 字段的写入重排序到构造器结束之后
- 禁止把初次读取 final 字段重排序到构造器开始之前
换句话说，只要没发生 this 逃逸，final int x = 42; 的写入对其他线程就是立即可见的——不需要 volatile 或 synchronized。这是实现无锁不可变对象（如 String、LocalDateTime）的底层基础。
