核心答案
主要包括程序计数器、虚拟机栈、本地方法栈、堆和方法区。
线程私有区域
程序计数器、虚拟机栈和本地方法栈随线程创建和销毁。虚拟机栈以栈帧为单位保存局部变量表、操作数栈和返回地址等信息。
线程共享区域
堆与方法区由多个线程共享。堆是对象分配和垃圾回收的主要区域，方法区保存类元数据、运行时常量池等信息。
常见异常
递归过深可能产生 StackOverflowError；对象无法分配可能产生 Java heap space；类元数据过多可能导致 Metaspace OOM。
核心考点清单
- 程序计数器、虚拟机栈、本地方法栈是线程私有；堆和方法区线程共享。
- 栈帧包含局部变量表、操作数栈、动态链接和方法返回信息。
- 方法区是规范概念，永久代和元空间是 HotSpot 不同版本的实现。
- 字符串常量池自 JDK 7 起位于堆中，类元数据在 JDK 8 后主要位于元空间。
- 对象通常由堆管理，但 JIT 可能通过逃逸分析和标量替换消除真实分配。
一次方法调用如何执行
调用方法时创建栈帧，参数和局部变量进入局部变量表，字节码借助操作数栈完成计算。方法正常返回或抛出未捕获异常时栈帧弹出。局部变量可能保存堆对象的引用，但引用变量和对象实体不是同一回事。
高频追问与参考回答
追问 1：堆和栈最本质的区别是什么？
栈服务线程的方法调用，生命周期与栈帧一致；堆服务对象存储，由线程共享并受 GC 管理。“栈快堆慢”不是本质定义。
追问 2：元空间会 OOM 吗？
会。大量动态生成类、类加载器泄漏或上限过小都可能导致 Metaspace OOM，应分析类数量与 ClassLoader 生命周期。
追问 3：对象一定在堆上吗？
语义上对象通常由堆管理，但 JIT 可对未逃逸对象做标量替换，甚至消除分配，不能机械回答“一定”。
机制全景图
下面把「JVM 运行时数据区有哪些？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["类加载建立元数据"]
A --> B["线程创建私有栈"]
B --> C["对象分配进入堆"]
C --> D["方法执行创建栈帧"]
D --> E["GC 与卸载回收区域"]
完整链路：从输入到结果
沿着「类加载建立元数据 → 线程创建私有栈 → 对象分配进入堆 → 方法执行创建栈帧 → GC 与卸载回收区域」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 类加载建立元数据
类元数据、运行时常量池和方法信息主要进入方法区的具体实现 Metaspace，Class 对象仍位于堆。
2. 线程创建私有栈
每个线程拥有程序计数器和 Java 虚拟机栈，线程数直接影响本地内存与栈容量。
3. 对象分配进入堆
绝大多数对象在堆中分配，逃逸分析可能标量替换，但不能简单理解为“对象都在栈上”。
4. 方法执行创建栈帧
每次方法调用创建栈帧，包含局部变量表、操作数栈、动态链接和返回信息。
5. GC 与卸载回收区域
堆由 GC 管理，线程栈随线程结束释放，类元数据只有在类加载器可回收等条件满足时才能卸载。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| jcmd VM.native_memory summary | 堆外分类总账 |
| jcmd GC.heap_info / VM.classloader_stats | 堆与类加载器证据 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
java -Xms2g -Xmx2g -Xss512k -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=512m -XX:NativeMemoryTracking=summary -jar app.jar
在同一容器限制下逐步增加线程、DirectByteBuffer 和动态类，记录 Heap、Metaspace、Thread、Code 与 RSS 的差值。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「Xmx/容器」为主基线，记录值应满足「示例不超过 60%」；同时保存 Heap committed/used、线程数与栈预算，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「jcmd VM.native_memory summary」确认请求确实进入「堆外分类总账」对应的实现，再沿「jcmd GC.heap_info / VM.classloader_stats」观察「堆与类加载器证据」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「只看堆忽略进程总 RSS」，并把单一变量逐级放大，直到「Xmx/容器」越过「>75%」。随后再分别验证「盲目增大 Xss 降低可创建线程数」和「类加载器泄漏导致 Metaspace 持续增长」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「建立进程内存预算表」，确认它能控制影响范围；第二轮应用「限制线程与直接内存」，验证核心链路恢复；最后落实「开启 NMT 基线对比」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「Xmx/容器」回到「示例不超过 60%」、「线程×Xss」回到「纳入总账」、「RSS-堆」回到「可由 NMT 解释」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| Xmx/容器 | 示例不超过 60% | >75% | 堆外无余量 |
| 线程×Xss | 纳入总账 | 超过内存 15% | 控制线程/Xss |
| RSS-堆 | 可由 NMT 解释 | 持续未知增长 | native 泄漏 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：增加线程后进程被操作系统杀死
团队只关注 -Xmx，忽略每个线程的 -Xss、直接内存、Metaspace 和 native 库。线程数上升后 RSS 超过容器限制，尚未发生 Java 堆 OOM 就被 OOM Killer 终止。容量设计应从进程总内存反推各区域预算。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 只看堆忽略进程总 RSS | Heap committed/used | 建立进程内存预算表 |
| 盲目增大 Xss 降低可创建线程数 | 线程数与栈预算 | 限制线程与直接内存 |
| 类加载器泄漏导致 Metaspace 持续增长 | Metaspace 使用 | 开启 NMT 基线对比 |
发布与回滚检查点
- 发布前：确认「jcmd VM.native_memory summary」对应实现和上述配置在目标版本仍然有效，并保存「Xmx/容器」基线。
- 灰度中：同时观察 Heap committed/used、线程数与栈预算、Metaspace 使用；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「建立进程内存预算表」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「只看堆忽略进程总 RSS」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| Java 堆 | 普通对象与数组 | GC 自动管理、容量可观测 | 过大增加停顿与 RSS |
| 线程栈 | 每线程调用帧与局部状态 | 线程隔离、随线程释放 | 线程多时总量显著，过小易栈溢出 |
| 直接/本地内存 | NIO、JIT、类元数据与 native 组件 | 减少部分复制或承载 JVM 自身 | 不完全受 Xmx 约束 |
选型至少带上 堆与非堆容量、对象分配速率、存活率和停顿目标，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
运行时数据区是规范模型，HotSpot 具体实现和不同 JDK 会变化；排障必须同时看 JVM 指标与操作系统进程内存。
工程落地遵循：以可观测证据驱动参数调整，避免脱离业务负载套用参数模板。回答时直接引用「jcmd VM.native_memory summary」、配置实验和事故数据，比复述固定模板更有说服力。