JVM内存模型和内存结构_JVM内存模型组成与各结构功能

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 和内存结构混为一谈，进而错误归因：

网奇.NET网络商城系统

系统优势： 1、 使用全新ASP.Net＋c#和三层结构开发. 2、 可生成各类静态页面（html,htm,shtm,shtml和.aspx) 3、 管理后台风格模板自由选择，界面精美 4、 风格模板每月更新多套，还可按需定制 5、 独具的缓存技术加快网页浏览速度 6、 智能销售统计，图表分析 7、 集成国内各大统计系统 8、 多国语言支持，内置简体繁体和英语 9、 UTF-8编码，可使用于全球

下载

• 看到 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  1000 5

输出中重点关注：

• OGC / OC：老年代当前容量 / 最大容量，确认 -Xmx 是否生效
• MU / MC：元空间已使用 / 最大容量，验证 -XX:MaxMetaspaceSize
• CCSU / CCSC：压缩类空间使用量（JDK 10+），反映类加载压力

真正难的不是记住每个区域叫什么，而是当 Full GC 频繁或 Metaspace OOM 出现时，能立刻判断该查类加载器泄漏，还是该调参，而不是打开 GC 日志从头扫起。