JVM内存模型是规范定义的抽象运行时结构，含堆（存对象、受-Xmx控制）、元空间（存类元数据、用本地内存）、栈（线程私有、存引用）、PC寄存器（唯永不OOM区域）等五部分。
JVM内存模型不是一套固定不变的物理内存布局，而是由Java虚拟机规范定义的一套抽象运行时结构——它决定了程序如何分配、访问和回收内存，直接决定你写的代码在多线程下是否安全、堆溢出时该调哪个参数、甚至OutOfMemoryError抛在哪一块。
堆 vs 方法区：对象和类元数据到底存在哪？
很多人以为“new出来的对象都在堆里”就完事了，其实漏掉了关键边界：从JDK 8起，方法区的实现已从永久代（PermGen）彻底替换为元空间（Metaspace），而元空间默认使用本地内存（即操作系统直接管理的内存），不再受-Xmx限制。
- 堆（Heap）：所有线程共享，存放实例对象、数组；受
-Xms/-Xmx控制；GC主要战场 - 元空间（Metaspace）：存放类的元信息（类名、字段、方法字节码、常量池等），但
字符串常量池和静态变量引用的对象仍在堆中（JDK 7+已移出方法区） - 误配风险：若频繁动态生成类（如Spring Boot + CGLIB代理、热部署场景），只调大堆却忽略
-XX:MaxMetaspaceSize，会触发java.lang.OutOfMemoryError: Metaspace
栈帧怎么压、怎么弹？局部变量表真能存对象吗？
Java虚拟机栈是线程私有的，每个方法调用对应一个栈帧（Stack Frame）。栈帧里最常被误解的是局部变量表——它存的从来不是对象本身，而是对象引用（reference），真正的对象一定在堆中。
- 栈帧生命周期 = 方法调用周期：入栈 → 执行 → 出栈；方法递归过深直接触发
StackOverflowError - 局部变量表大小在编译期就确定（
javap -v可查LocalVariableTable），不随运行时变化 - 常见错觉：“String s = "abc";” 中的"abc"存在栈里？错。字面量"abc"在字符串常量池（堆中），
s只是栈上一个4/8字节的引用
程序计数器为什么永不OOM？它到底记什么？
程序计数器（PC Register）是JVM内存区域中唯一一个规范明确禁止抛出OutOfMemoryError的区域，原因很简单：它只存一个地址值，且每个线程独占一份，内存开销恒定在几个字节。
- 记的是当前线程正在执行的
字节码指令地址（比如0x00000001），不是Java源码行号（那是调试信息，存在LineNumberTable中） - 如果线程正在执行native方法，PC值为
undefined，此时不参与任何字节码调度 - 真实作用：支撑线程切换后的“断点续执行”——没有它，多线程根本无法正确恢复上下文
真正难的从来不是记住五块区域叫什么，而是当Full GC频繁时，你能立刻判断是老年代碎片化、元空间泄漏，还是字符串常量池堆积；当StackOverflowError出现，你要分清是递归失控，还是Lambda闭包意外捕获了大对象导致栈帧膨胀。这些都藏在内存模型的分工细节里，而不是示意图的方框位置中。
