JVM运行时数据区是HotSpot等JVM实现中真实划分、可监控调优的内存区域集合，包括堆（线程共享）、Java虚拟机栈（线程私有）、程序计数器（线程私有且唯一不抛OOM的区域）、方法区（JDK 8+为元空间）及栈帧结构。
Java中没有叫“虚拟机模型”的独立概念——你实际想了解的，是 JVM运行时数据区（Runtime Data Areas），也就是常说的 JVM内存模型。它不是抽象理论模型，而是HotSpot等JVM实现中真实划分、可监控、可调优的内存区域集合。
为什么堆和栈总被混淆？关键看线程归属
很多人以为“堆存对象、栈存变量”就够了，但真正踩坑的是线程视角：
-
堆（Heap）是所有线程共享的，对象一旦创建就在这里分配，GC主要动它； -
Java虚拟机栈（Java Virtual Machine Stack）是每个线程私有的，方法调用即压栈，方法返回即弹栈； -
程序计数器（Program Counter Register）也是线程私有，且是JVM中唯一不会抛出OutOfMemoryError的区域——它只存下一条字节码指令地址，极小、无GC、不可配置。
常见错误现
- 在高并发场景下，盲目增大
-Xss（单线程栈大小），导致线程数锐减甚至创建失败； - 把静态变量误认为“在栈里”，其实它存在
方法区（JDK 8+为元空间 Metaspace），属于线程共享区域。
方法区去哪儿了？永久代→元空间的迁移不是升级，是解耦
JDK 8起，PermGen（永久代） 被彻底移除，取而代之的是使用本地内存（Native Memory）的 Metaspace：
- 方法区不再受
-XX:MaxPermSize限制，改由-XX:MaxMetaspaceSize控制（默认无上限，可能耗尽系统内存）； - 类型信息、常量池、静态变量、JIT编译后的代码都进元空间，但字符串常量池（
StringTable）从JDK 7起已移到堆中； - 如果应用动态生成大量类（如Spring Boot + CGLIB代理多、OSGi、热部署框架），
Metaspace OOM比旧版PermGen OOM更隐蔽——因为堆没满，GC日志也不报错，只看到java.lang.OutOfMemoryError: Metaspace。
实操建议：
- 生产环境务必设置
-XX:MaxMetaspaceSize=256m（按需调整）； - 配合
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps观察元空间增长趋势； - 使用
jstat -gc查看MU（Metaspace Used）和MC（Metaspace Capacity）。
栈帧里到底装了啥？局部变量表不是“变量本身”
一个方法执行时，JVM为其创建一个 栈帧（Stack Frame），里面包含：
-
局部变量表：存储方法参数、方法内定义的局部变量——但注意，它只存引用（如Object obj存的是堆中对象地址），或基本类型值（如int i = 42存的就是42）； -
操作数栈：字节码指令运算的临时工作区，比如iadd指令会从栈顶弹出两个int相加再压回； -
动态链接：指向运行时常量池中该方法符号引用的位置； -
方法返回地址：记录调用者方法下一条指令地址，用于方法退出后恢复执行。
容易被忽略的点：
- 局部变量表大小在编译期就确定（
javap -v可见LocalVariableTable和max_stack / max_locals）； -
final修饰的局部变量不一定会被优化进常量池，是否内联取决于JIT，不能靠它做性能假设； - Lambda表达式捕获的外部变量，会被编译器自动封装进合成构造方法参数，本质仍是栈帧传参。
JVM运行时架构不是纸面模型，它是你每次 java -jar app.jar 启动后真正在内存里展开的结构。堆是否够大、元空间会不会爆、线程栈会不会溢出——这些都不是“理论上可能”，而是上线后凌晨三点告警的真实源头。调优前先用 jps、jstat、jmap 看清它长什么样，比背原理管用十倍。
