JVM 运行时数据区全景：堆、栈、方法区、程序计数器

《Java 虚拟机规范》把 JVM 运行时内存切成几个区域：程序计数器、Java 虚拟机栈、本地方法栈、堆、方法区、运行时常量池；规范之外的直接内存（NIO 的堆外内存）也常被一并讨论。记这堆区域，先用两个维度切，比死背名字清晰得多。

维度一：线程私有 vs 线程共享。每个线程一出生，JVM 就给它配一套"私有"的空间（程序计数器 + JVM 栈 + 本地方法栈），随线程的生命周期创建和销毁；而堆和方法区是全进程共享的，所有线程共用。

维度二：哪块内存溢出抛什么错。这个维度是"面试题 + 事故现场"的双料考试点：堆溢出是 Java heap space，栈要么"太深"抛 StackOverflowError、要么"太宽"（线程太多建不起栈）抛 OutOfMemoryError: unable to create new native thread，方法区是 Metaspace，直接内存是 Direct buffer memory，而程序计数器——规范明说它是唯一不会 OOM 的区域。

还有个常被追问的"数数题"：规范里的运行时数据区，严格说是五个（程序计数器、JVM 栈、本地方法栈、堆、方法区），运行时常量池在规范上挂在方法区之下；不同教材把"本地方法栈"或"运行时常量池"单列与否，口径各不一样。考官的意图不是考你数数，是看你能不能说清每块干嘛——把上面的表吃透，口径问题自然免疫。

程序计数器（PC Register）是六区里最小的一个，职责一句话：记录当前线程正在执行的字节码指令的编号（行号指示器）。它的存在意义在于线程切换——CPU 分时调度下，一个线程随时会被挂起、稍后又恢复执行，恢复时就得靠 PC 知道"我上次执行到哪了"。所以 PC 是线程私有的：每个线程一份，互不干扰，否则切换回来就串味了。

PC 还有两个身份：① 字节码解释器的工作依据——解释执行时，PC 指向哪条指令，解释器就取下一条来执行；② 唯一不会 OOM 的区域——它只是一小块内存（存一个指令地址/字长），而且生命周期严格跟着线程走，规范明确定义它不抛任何 OutOfMemoryError。

JVM 栈也是线程私有，生命周期和线程相同。它存的不是"变量"，而是一摞栈帧：每调用一个方法压入一个栈帧，方法返回时弹出。一个栈帧内部又分成四块，这是本篇第一处核心：

// 源码：int add(int a, int b) { return a + b; }
// javap -c 反编译出的字节码（关键指令）：
   0: iload_1        // 把局部变量表 slot1 的 a 压入操作数栈
   1: iload_2        // 把局部变量表 slot2 的 b 压入操作数栈
   2: iadd           // 从操作数栈弹出两个 int，相加，结果压回栈顶
   3: ireturn        // 把栈顶结果作为返回值返回
// 注释：iload_* 读局部变量表，iadd 在操作数栈上运算——两块结构一目了然。

1. 局部变量表：以 slot 为单位存方法参数和局部变量。int、float、reference、returnAddress 各占 1 个 slot，long、double 占 2 个 slot；表的大小在编译期就确定了。
2. 操作数栈：字节码的"工作台"，大小（max_stack）编译期确定。比如 iadd 就从栈顶弹两个、压一个；JVM 的运算几乎都发生在这块栈上。
3. 动态链接：指向运行时常量池里"本栈帧所属方法的引用"，多态调用（虚方法分派）靠它解析到实际的方法。
4. 方法返回地址 + 异常表：返回地址记录调用后回到哪条指令；异常表记录 start_pc ~ end_pc + handler——try-catch 的真相。

把栈帧放大到字节码层面，能看到编译产物里的两个"预算"数字：方法 Code 属性里的 max_stack（操作数栈最大深度）和 max_locals（局部变量表最大 slot 数）——javac 阶段就算好，JVM 运行时据此给每个栈帧分配固定大小的空间，而不是动态伸缩。所以"方法里局部变量越多、运算越复杂，栈帧越占地方"是编译期定死的事。

顺带把"本地方法栈"补一句：它就是"JVM 栈的 native 版"，专门服务 native 方法调用。HotSpot 里它和 JVM 栈合二为一（共用一套栈），规范上分列两区、实现上常常一体——面试知道这层关系即可，不必纠结它"独立"与否。

栈上两种错误要分清楚：StackOverflowError 是"太深"——递归无终止、或每个栈帧压了大数组局部变量，栈深度超过 -Xss 允许的深度；OOM 是"太宽"——线程创建太多，每个线程建栈都要吃 native 内存，系统内存耗尽就抛 unable to create new native thread。一个在"垂直方向"爆掉，一个在"水平方向"爆掉。

堆是 JVM 里最大的一块内存，线程共享，所有线程的 new 都往这放——对象实例、数组，几乎全在这。也正因为它最大、最热闹，才成为 GC 的主战场（引用关系、分代回收全发生在这里）。

堆内部的分代结构（Eden / Survivor 0 / Survivor 1 / 老年代）、对象如何在里面出生和晋升，这些细节在「JVM 堆内存」和「对象创建全过程」里有完整展开，本篇只把它定位到全景图里：记住堆的三个核心参数 -Xms（初始大小）、-Xmx（最大大小）、-Xmn（年轻代大小），完整参数见「JVM 调优参数手册」。

需要点破的一点：堆 OOM 不代表堆本身设小了。九成场景里是"该被回收的对象没被回收"——要么代码里留着不必要的强引用（泄漏），要么 GC 配置不合理。所以看到 Java heap space，第一反应不是盲目调大 -Xmx，而是先看是不是泄漏（「内存泄漏排查」的 MAT 分析流程）。

参数层有个小坑值得记：-Xms 与 -Xmx 不一致时，堆是"按需扩容"的——初始只分配 -Xms，不够了再向 -Xmx 涨，而扩容常伴随一次 GC 甚至向 OS 重新申请内存的开销。所以生产里常把两者设成相等，省去运行期扩容抖动；-Xmn 设年轻代大小，配小了年轻代对象晋升太快、Full GC 频繁，配大了单次 Minor GC 变久，是需要实测的平衡题。

方法区存的是类级别的元信息：已加载类的方法字节码、字段与方法签名、注解、以及运行时常量池。注意它和堆的区别——堆存"实例"，方法区存"关于类的模板与常量"。这一段是本篇第二处核心：它在 JDK 8 经历了一次大搬家。

// JDK 7 及以前：方法区的物理实现是"永久代"（PermGen），在堆里划一块
-XX:MaxPermSize=64m        # 默认 64MB（Client）/ 8x（Server），改小容易 OOM: PermGen space
// 痛点：大小难预测（类多就爆）、Full GC 时类元信息整理慢、OSGi 场景类共享难

// JDK 8（JEP 122）：永久代移除，方法区改用本地内存的"元空间"（Metaspace）
-XX:MetaspaceSize=21m      # ⚠️ 不是"初始大小"！是"首次触发 Full GC 的阈值"
-XX:MaxMetaspaceSize       # 默认无上限（unlimited）——只受物理内存/系统限制
// 查看：jstat -gcmetacapacity <pid> 或 jcmd <pid> VM.metaspace

这场搬家的收益：① 彻底消灭了 OOM: PermGen space（元空间用本地内存，上限默认是物理内存）；② 类元数据按需分配、动态增长，不再受一个固定小池子的约束；③ 类可以更干净地卸载，OSGi/热部署的类共享更好做。代价是：由于默认没有上限，动态生成大量类（反射代理、CGLIB）时会把本地内存吃光——所以生产里往往显式设 -XX:MaxMetaspaceSize 兜底。

更本质地说，换的是"分配介质的性质"：永久代在堆里，受堆 GC 管，类元信息的整理要和对象回收挤在同一条 Full GC 里跑，类一多 STW 就被拖长；元空间用本地内存独立管理，按块向 OS 申请，类的加载/卸载不再和堆 GC 强耦合——这正是 OSGi 反复装卸 bundle、JSP 反复重编译这类场景在 JDK 8 之后终于不再"永久代撑爆"的根因。报错名从 PermGen space 变成 Metaspace，但"类没卸载、元数据只涨不落"的本质没变。

这两个池名字太像，是常年失分点，拆开看就清楚：

运行时常量池（在方法区）：每个 .class 文件里都有一张"常量池表"（Constant Pool），存两类东西——字面量（字符串、数字常量）和符号引用（类名、方法名、字段名的文本描述）。类加载后，这张表进入方法区变成"运行时常量池"，且可以在运行期动态追加新常量（比如 String.intern()）。它的生命周期和它所属的 Class 一致，类卸载了它才消失。符号引用里的"符号"指的是文本形式（如 java/lang/Object），经过链接阶段的"解析"才会变成直接引用（真正的指针/偏移量）。

举个映射例子：字节码里的 invokevirtual #5，那个 #5 就是符号引用——一个编号，指向常量池表第 5 项，内容是一段"方法名 + 描述符"的文本；链接的解析阶段才把它换成指向实际方法入口的直接引用。同一个符号引用，解析前是"文本名字"，解析后是"内存地址"——这恰是"类文件常量池表"和"运行时常量池"的分界：文件里是静态表，加载后变成可解析、可动态追加的池。

字符串常量池（StringTable，在堆里）：JDK 7 起从永久代挪到了堆里，是一张全局的哈希表（-XX:StringTableSize 控制桶数）。所有 "abc" 字面量在编译后会进入这个池；运行期 intern() 也能入池——规则是"池里没有就复制/记录一份引用，有就返回池里的那个"。

直接内存不在 JVM 规范的运行时数据区之列，但 NIO 让它在实战里绕不开：DirectByteBuffer 在堆外分配 native 内存，读写时操作系统可以直接 DMA（绕过 JVM↔Native 的一次拷贝），所以高性能网络库（Netty）大量用它。

关键在它的释放机制：堆外的内存，JVM 的 GC 管不着，于是 DirectByteBuffer 这个堆对象身上挂了一个 Cleaner（基于虚引用，见「对象存活判定」的虚引用节）。当这个堆对象被 GC 时，Cleaner 线程触发，调用 DirectByteBuffer 的 cleaner.clean() 去 unmap 并释放那块堆外内存。一句话：堆对象的死，连带堆外内存的释放。

为什么网络层（Netty 等）偏爱它？NIO 读堆外内存时，数据可以直接 DMA 进内核缓存再进套接字，省掉"堆内缓冲 → 内核缓冲"那把数据从 JVM 堆拷到 native 的一次拷贝；而 HeapByteBuffer 则要多出这一次拷贝。这一省，在高吞吐网关上就是数量级的吞吐差距。

面试回答模板

高频追问表