JVM内存模型和内存结构_JVM内存模型组成与各结构功能_技术教程

JVM内存模型（JMM）是多线程下可见性、有序性、原子性的抽象规范，而JVM内存结构是运行时数据区的物理划分（如堆、栈、方法区等）；二者混淆易致调试错误或OOM。

JVM内存模型（JMM）和JVM内存结构是两个常被混淆但完全不同的概念：前者是关于多线程下变量可见性、有序性、原子性的抽象规范，后者是运行时数据区的物理划分（如堆、栈、方法区等）。搞混这两者，轻则调试多线程问题绕弯路，重则误配参数导致 OOM 或 GC 频繁。

JMM 不是内存布局图，而是一组规则，定义了线程如何读写共享变量，以及什么情况下一个线程的修改对另一个线程“可见”。它不关心 heap 有多大，只约束 volatile、synchronized、final 字段和锁释放/获取的语义。

volatile 写操作会刷新到主内存，读操作强制从主内存加载——但不保证复合操作（如 i++）原子性
synchronized 块的解锁（monitorexit）会将工作内存中变量值同步回主内存；加锁（monitorenter）会清空本地工作内存，重新从主内存读取
所有线程都遵守“先行发生”（happens-before）规则，例如程序次序规则、监视器锁规则、volatile 变量规则等，违反这些规则就可能看到过期值或乱序执行结果

这是 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