Java内存模型（JMM）是规范线程读写共享变量的抽象规则体系，区分于JVM运行时数据区；其主内存对应堆与元空间，工作内存对应线程栈帧；核心解决可见性、有序性、原子性问题，并通过volatile、synchronized、final及happens-before等机制落地。
Java 内存模型（JMM）不是一块物理内存，而是一套关于“线程如何读写共享变量”的规则体系。配教程时，关键不是堆砌概念，而是让学习者看清三件事：谁在操作、在哪操作、怎么保证正确性。
明确区分 JMM 和 JVM 运行时数据区
这是最容易混淆的起点。JMM 是抽象规范，关注线程与内存的交互行为；JVM 运行时数据区是物理划分，描述内存实际布局。
- JMM 的“主内存” ≈ JVM 的堆 + 方法区/元空间：所有共享变量（对象字段、静态变量）都存在这里。
- JMM 的“工作内存” ≈ 每个线程的栈帧 + 局部变量表：线程不能直接读写主内存，必须先把变量 load 到自己的工作内存中操作，再 write 回主内存。
- 字符串常量池虽在堆或元空间中，但 JMM 对它的访问仍需遵循 read/load/use/write/flush 等操作协议。
紧扣三大核心问题讲透机制
JMM 存在的意义，就是解决多线程下的三个根本问题：
- 可见性：一个线程改了变量，另一个线程何时、怎样看到？靠 volatile 写屏障 + happens-before 传递性，或 synchronized 解锁前的 flush。
- 有序性：代码顺序 ≠ 执行顺序。编译器重排序、CPU 指令重排都可能发生。volatile 读写、synchronized 块、final 字段初始化等，都会插入内存屏障禁止特定重排。
- 原子性：JMM 本身不保证 long/double 的 64 位读写原子性（除非加 volatile），普通变量的复合操作（i++）天然非原子——这点要和 synchronized/volatile 的实际作用对齐讲。
用关键字串联 JMM 规则落地
脱离 volatile、synchronized、final、锁、线程启动/终止等具体语法，JMM 就是空谈。配教程必须让每个关键字对应到 JMM 的某条原则：
立即学习“Java免费学习笔记（深入）”；
- volatile：保证可见性 + 禁止指令重排（读写前后加屏障），但不保证原子性（i++ 仍需同步）。
- synchronized：进入时 lock（清空工作内存）、退出时 unlock（刷新主内存），天然满足原子性、可见性、有序性。
- final 字段：构造器内完成赋值后，其他线程能看到“正确初始化”的 final 值——这是 JMM 对安全发布提供的特殊保障。
- Happens-Before：不是底层实现，而是程序员可依赖的“先行发生”关系清单（如程序次序、监视器锁、volatile 写-读、线程启动等），它是 JMM 向上提供的最实用契约。
搭配典型代码场景讲清“为什么需要 JMM”
避免纯理论灌输。例如：
- 写一个无同步的 flag 控制循环，演示 JIT 优化后线程可能永远看不到 true；加上 volatile 立刻生效。
- 展示 double-checked locking 中缺少 volatile 导致对象未完全构造就被引用的问题，引出“初始化安全性”和 happens-before。
- 对比 String s = "abc" 和 new String("abc") 在字符串常量池、堆、工作内存中的变量副本路径，说明引用变量的可见性边界。
