JVM内存模型（JMM）是多线程下可见性、有序性、原子性的抽象规范，而JVM内存结构是运行时数据区的物理划分（如堆、栈、方法区等）；二者混淆易致调试错误或OOM。
JVM内存模型（JMM）和JVM内存结构是两个常被混淆但完全不同的概念：前者是关于多线程下变量可见性、有序性、原子性的抽象规范，后者是运行时数据区的物理划分（如堆、栈、方法区等）。搞混这两者，轻则调试多线程问题绕弯路，重则误配参数导致 OOM 或 GC 频繁。
Java Memory Model（JMM）解决的是可见性与重排序问题
JMM 不是内存布局图，而是一组规则，定义了线程如何读写共享变量，以及什么情况下一个线程的修改对另一个线程“可见”。它不关心 heap 有多大，只约束 volatile、synchronized、final 字段和锁释放/获取的语义。
-
volatile写操作会刷新到主内存，读操作强制从主内存加载——但不保证复合操作（如i++）原子性 -
synchronized块的解锁（monitorexit）会将工作内存中变量值同步回主内存；加锁（monitorenter）会清空本地工作内存，重新从主内存读取 - 所有线程都遵守“先行发生”（happens-before）规则，例如程序次序规则、监视器锁规则、volatile 变量规则等，违反这些规则就可能看到过期值或乱序执行结果
Runtime Data Areas（内存结构）是真实分配内存的区域
这是 java -Xmx2g 真正影响的部分，由 JVM 启动时划分，对应操作系统实际申请的内存页。不同版本 JDK 的实现有差异（比如 JDK 8 的永久代 vs JDK 17 的元空间），但核心区域稳定：
-
PC Register：每个线程私有，记录当前执行字节码指令地址；唯一不会抛OutOfMemoryError的区域 -
Java Virtual Machine Stacks：线程私有，存储局部变量、操作数栈、动态链接、方法出口等；栈深度超限抛StackOverflowError，总内存不足抛OutOfMemoryError -
Heap：所有线程共享，对象实例和数组分配在此；受-Xms/-Xmx控制；GC 主要作用区域 -
Method Area（JDK 8+ 为Metaspace）：存储类信息、常量、静态变量、JIT 编译代码；JDK 8 起使用本地内存，不再受-XX:PermSize限制，改用-XX:MaxMetaspaceSize -
Runtime Constant Pool：是Method Area的一部分，存放编译期生成的字面量（如字符串字面量）和符号引用
容易踩坑的典型场景
很多线上问题源于把 JMM 和内存结构混为一谈，进而错误归因：
- 看到
java.lang.OutOfMemoryError: Metaspace，却去调大-Xmx——没用，得调-XX:MaxMetaspaceSize - 用
volatile修饰ArrayList字段，以为能保证线程安全——其实只保证引用本身可见，add()操作仍非原子，需用Collections.synchronizedList或CopyOnWriteArrayList - 在
finalize()方法里复活对象（如this = new Object()），试图绕过 GC——JDK 9+ 已废弃finalize()，且现代 GC（如 ZGC、Shenandoah）根本不保证其执行时机 - 认为 “堆外内存不受 JVM 管理”，就随意用
ByteBuffer.allocateDirect()或Unsafe.allocateMemory()——这些内存仍受-XX:MaxDirectMemorySize限制，超限抛OutOfMemoryError: Direct buffer memory
验证内存结构配置是否生效的最简方式
别只看启动参数，用 jstat 实时观察实际使用情况：
jstat -gc <pid> 1000 5
输出中重点关注：
-
OGC/OC：老年代当前容量 / 最大容量，确认-Xmx是否生效 -
MU/MC：元空间已使用 / 最大容量，验证-XX:MaxMetaspaceSize -
CCSU/CCSC：压缩类空间使用量（JDK 10+），反映类加载压力
真正难的不是记住每个区域叫什么，而是当 Full GC 频繁或 Metaspace OOM 出现时，能立刻判断该查类加载器泄漏，还是该调参，而不是打开 GC 日志从头扫起。
