JVM（一）：运行时数据区与对象内存布局

导语：JVM 是 Java 工程师的底层功力试金石。本篇先讲清运行时数据区的划分与各区域的 OOM 类型，再深入对象的创建流程、内存布局、访问定位与分配策略，并补齐「为什么用元空间替代永久代」「TLAB」「JIT 即时编译」等高频题，共 18 题。

一、运行时数据区

1. JVM 的运行时数据区（内存区域）是如何划分的？

答： 按线程私有/共享划分：

• 线程私有：程序计数器、Java 虚拟机栈、本地方法栈；
• 线程共享：堆、方法区（JDK 8 起为元空间 Metaspace）。

此外还有直接内存（堆外内存），它不属于 JVM 运行时数据区，但 NIO 等会使用，受本机内存限制。

2. 程序计数器（PC）的作用？为什么是线程私有的？

答： 程序计数器是一块很小的内存，记录当前线程正在执行的字节码指令地址（若执行 native 方法则为 undefined）。

因 CPU 时间片轮转会切换线程，每个线程需独立记录自己的执行位置，故必须线程私有；它也是唯一不会 OOM 的区域。

3. Java 虚拟机栈的结构与可能异常？

答： 虚拟机栈由栈帧（Stack Frame）组成，每调用一个方法压入一个栈帧，方法结束出栈。栈帧包含：

• 局部变量表：存放方法参数与局部变量（基本类型、对象引用）；
• 操作数栈：字节码执行的工作区；
• 动态链接：指向运行时常量池中该方法的符号引用；
• 方法返回地址、附加信息等。

异常：StackOverflowError（栈深度超出，如无限递归）、OutOfMemoryError（栈扩展失败，如线程过多）。

4. 本地方法栈与虚拟机栈的区别？

答： 本地方法栈为 native 方法（JNI）服务，虚拟机栈为 Java 方法服务；HotSpot 将二者合二为一。同样可能抛 StackOverflowError / OutOfMemoryError。

5. 堆（Heap）的作用与分代？

答： 堆是 JVM 中最大的内存区域，用于存放对象实例与数组，被所有线程共享，是 GC 的主要战场。

• 分代：新生代（Eden + 2 个 Survivor）、老年代；
• 通常 -Xms 设初始堆、-Xmx 设最大堆；新生代 : 老年代 ≈ 1 : 2（-XX:NewRatio=2），Eden : Survivor ≈ 8 : 1 : 1。

注意：分代是 HotSpot 的实现选择，不是 JVM 规范的强制要求（JVM 规范只定义了「堆」这一逻辑区域），这也为后来 G1/ZGC 的 Region 化、分代 ZGC 留出了空间。

6. 方法区与永久代、元空间的关系？（JDK 8 重要变化）

答： 方法区是 JVM 规范定义的逻辑区域，用于存储已被加载的类元信息、常量、静态变量、即时编译器编译后的代码等。

• JDK 7 及之前：方法区的实现是永久代（PermGen），位于堆内，受 -XX:PermSize/-XX:MaxPermSize 限制，易 OOM；
• JDK 8 起：永久代被移除，方法区改由元空间（Metaspace）实现，使用本地内存（Native Memory），受 -XX:MetaspaceSize/-XX:MaxMetaspaceSize 限制。

重要纠正：语料常把「永久代」当作方法区本身。准确说法是永久代/元空间都只是方法区的具体实现，JDK 8 后方法区不再由永久代实现。

各内容物的搬迁路径（容易答错）：

内容物	位置变化
类元信息（instanceKlass 等）	JDK 8 起 → 本机内存（元空间）
字符串常量池	JDK 7 就已从永久代移入堆（不是 JDK 8）
静态变量 / java.lang.Class 对象	随 Class 对象存放在堆中
运行时常量池	JDK 7 起随之进入堆；类元信息部分在 JDK 8 移入元空间

元空间默认无上限（受物理内存约束），但生产必须设 -XX:MaxMetaspaceSize，防止动态生成类过多时耗尽本机内存把机器拖垮。

7. 为什么用元空间替代永久代？

答： 主要有四点原因：

1. 永久代大小必须启动时固定，难以预估——类元信息大小强依赖运行期行为（CGLIB/动态代理、JSP 编译、Groovy 脚本会动态生成大量类），设小了频繁 OOM: PermGen space，设大了浪费；
2. 元空间使用本机内存，默认只受物理内存限制，天然缓解了「类元信息撑爆固定区域」的问题，也可用 -XX:MaxMetaspaceSize 精确兜底；
3. 减少 Full GC 压力：永久代是堆的一部分、参与 Full GC；元空间独立于堆，类元信息回收的触发频率显著降低；
4. 工程整合：HotSpot 与 JRockit 合并为统一 JVM 时，JRockit 本就没有永久代，用元空间可平滑统一两套实现。

代价：类加载泄漏（不断生成类却不卸载）时，元空间会持续膨胀直到耗尽本机内存，表现为 OutOfMemoryError: Metaspace。所以生产仍要设上限 + 监控 MC/MU（见《JVM（四）》）。

8. 直接内存（堆外内存）是什么？

答： 直接内存是 JVM 之外的操作系统本地内存，通过 ByteBuffer.allocateDirect() 分配，不受 Java 堆大小限制，但受本机总内存限制。NIO 用其做零拷贝 I/O，减少堆内外拷贝、提升性能。

-XX:MaxDirectMemorySize 可限制其大小，超限抛 OOM: Direct buffer memory。注意：DirectByteBuffer 对象本身在堆中，回收依赖虚引用 Cleaner，所以堆内存充裕时也可能出现直接内存 OOM（需显式 -XX:MaxDirectMemorySize + 及时释放）。

9. 各内存区域的 OOM 分别有哪些？

答：

• 堆：java.lang.OutOfMemoryError: Java heap space（对象过多/内存泄漏）；
• 元空间：OutOfMemoryError: Metaspace（类加载过多，如动态代理/热部署反复加载类）；
• 虚拟机栈/本地方法栈：StackOverflowError 或 OutOfMemoryError: unable to create new native thread；
• 直接内存：OutOfMemoryError: Direct buffer memory；
• GC 开销：OutOfMemoryError: GC overhead limit exceeded（98% 时间 GC 却回收 <2% 内存）。

10. 什么是 TLAB（线程本地分配缓冲）？

答： TLAB（Thread Local Allocation Buffer）是 HotSpot 在 Eden 区内为每个线程预先划分的一小块私有分配缓冲区。

• 解决的问题：堆是线程共享的，多线程用「指针碰撞」分配对象时需要同步（CAS + 失败重试），TLAB 让每个线程在自己的地盘上分配，无需加锁，大幅提升分配效率；
• 分配顺序：对象优先在 TLAB 中分配 → TLAB 用尽则申请新的 TLAB → 再失败则退化为共享 Eden 区分配（CAS + 失败重试） → 仍失败才触发 Minor GC；
• 相关参数：-XX:+UseTLAB（默认开启）、-XX:TLABSize（初始大小）、-XX:TLABWasteTargetPercent（浪费比例上限）、-XX:-ResizeTLAB；
• 注意：TLAB 空间小且是私有的，大对象无法在 TLAB 分配，会直接走 Eden 或老年代；TLAB 剩余空间不足时会「浪费」掉（内部碎片），由 refill_waste 机制控制是否放弃当前 TLAB。

二、对象创建与内存布局

11. 一个对象在 JVM 中是如何被创建的？

答： new 指令触发：

1. 类加载检查：检查类是否已加载、解析、初始化，否则先执行类加载；
2. 分配内存：从堆中划出空间，方式有两种——
   • 指针碰撞（Bump Pointer，堆规整时用，如 Serial/ParNew + 复制/整理算法）；
   • 空闲列表（Free List，堆不规整时用，如 CMS + 标记清除）；
3. 初始化零值：将分配的内存（不含对象头）置零，保证字段有默认零值；
4. 设置对象头：写入类元信息指针、GC 分代年龄、锁状态等；
5. 执行 <init>：调用构造方法，按代码初始化字段。

并发安全：分配时用 CAS + 失败重试 或 TLAB（Thread Local Allocation Buffer） 规避竞争，HotSpot 默认开启 TLAB（见第 10 题）。

12. 对象的内存布局（结构）是什么？

答： 对象在堆中由三部分组成：

1. 对象头（Header）：
   • Mark Word（64 位下 8 字节）：存储哈希码、GC 分代年龄、锁状态标志、偏向线程 ID 等；
   • 类型指针（Klass Pointer）：指向类元数据的指针（开启指针压缩后 4 字节）；
2. 实例数据（Instance Data）：各字段的实际值（含父类字段，HotSpot 会按宽度重排字段以提升对齐效率）；
3. 对齐填充（Padding）：保证对象大小为 8 字节整数倍（仅作占位，无实际含义）。

补充：若是数组对象，对象头中还会多一个 4 字节的数组长度字段。

13. 对象头中的 Mark Word 包含哪些信息？

答： Mark Word 是对象锁与 GC 的核心，64 位下结构随锁状态变化：

锁状态	锁标志位	存储内容
无锁	01	哈希码（31 位）+ 分代年龄（4 位）+ 偏向标志 0
偏向锁	01	偏向线程 ID（54 位）+ Epoch（2 位）+ 分代年龄 + 偏向标志 1
轻量级锁	00	指向线程栈中 Lock Record 的指针
重量级锁	10	指向 Monitor（ObjectMonitor） 的指针
GC 标记	11	空（不记录信息）

版本提醒：偏向锁自 JDK 15 起被默认禁用（JEP 374），并在后续版本中移除实现。因此现代 JDK 上实际只有「无锁 → 轻量级锁 → 重量级锁」三态（详见《Java并发（三）》锁升级一题）。

14. 什么是指针压缩（-XX:+UseCompressedOops）？

答： 在 64 位 JVM 上，开启指针压缩（堆 ≤ 32G 时默认开启）可将对象引用、类型指针从 8 字节压缩为 4 字节，节省约 30%~50% 内存、提升缓存命中率。

原理是对象按 8 字节对齐，地址低 3 位恒为 0，因此可用 32 位编码「地址 / 8」，从而表示 32G（2^32 × 8）的堆空间。

当堆超过约 32GB 时压缩失效（也可用 -XX:ObjectAlignmentInBytes 增大对齐到 16 字节，从而支持 64GB，但会加剧内部碎片），引用又变回 8 字节，得不偿失——这是「堆不要盲目超过 32G」这条调优经验的由来（见《JVM（四）》）。

15. 对象的访问定位方式有哪两种？

答： 栈上的引用访问堆中对象有两种方式：

• 句柄访问：引用指向句柄池，句柄再存对象实例地址与类型数据地址。优点：对象移动（GC）时只需改句柄，引用不变；缺点：多一次间接寻址；
• 直接指针（HotSpot 采用）：引用直接指向对象实例，对象头内再指向类型数据。优点：访问快（少一次跳转）；缺点：对象移动需更新所有引用。

16. 对象的内存分配策略与逃逸分析相关的优化？

答： 默认优先在 Eden 分配，其余策略如下：

• 大对象直接进老年代：-XX:PretenureSizeThreshold（仅 Serial/ParNew 生效，G1 另有 Humongous 机制，见《JVM（二）》），避免大对象在新生代频繁复制；
• 长期存活对象晋升老年代：年龄达 -XX:MaxTenuringThreshold（默认 15）；
• 动态年龄判定：Survivor 中同年龄对象大小总和超过 Survivor 一半，则大于等于该年龄的对象直接晋升（无需等满 15 岁）；
• 空间分配担保（Handle Promotion）：Minor GC 前，JVM 检查老年代最大可用连续空间是否大于新生代所有对象总空间——大于则 Minor GC 安全；否则再看是否大于历次晋升对象的平均大小，是则冒险 Minor GC，否则改为直接 Full GC（JDK 6 Update 24 后 -XX:HandlePromotionFailure 参数已废弃，该判断逻辑内置）。

此外 JIT 的逃逸分析（见第 17 题）可触发：

• 栈上分配：对象未逃逸出线程，直接在栈分配，随栈帧回收，避免堆压力；
• 标量替换：把对象拆成基本字段直接在栈/寄存器使用；
• 同步消除（锁消除）：锁对象未逃逸则消除同步。

17. 什么是逃逸分析？

答： 逃逸分析是 JIT 的静态分析技术，判断对象的动态作用域：若对象未逃逸出当前方法/线程（如仅方法内局部使用），则可做栈上分配、标量替换、锁消除等优化，减少堆分配与 GC 压力。

重要澄清（常见误区）：

• 「Java 对象一定分配在堆上」在新版本中已不严格成立——开启逃逸分析后，未逃逸对象可能被标量替换而根本不产生对象实例，这也是「对象的实际分配位置由 JVM 决定」的含义；
• 但理论上（JLS/JVM 规范层面）对象仍被视作分配在堆上，逃逸分析只是 JVM 的实现优化，不可依赖：HotSpot 并没有真正实现「栈上分配对象」，落地形式主要是标量替换。

18. 什么是 JIT 即时编译？解释器与 JIT 如何配合？

答： Java 是「半编译半解释」的语言：javac 先把源码编译为平台无关的字节码，运行期再由 JVM 执行。

• 解释器：逐条解释执行字节码，启动快，但执行效率低；
• JIT 编译器：把热点代码（频繁执行的方法/循环）编译成本地机器码并缓存，运行快，但编译本身耗时；
• 两者配合是 HotSpot 的经典设计：启动阶段靠解释器快速跑起来，随热点积累逐步用 JIT 替换，兼顾启动速度与峰值性能。

热点探测与分层编译：

• 方法调用计数器 + 回边计数器（回边即循环跳转）超过阈值即判定为热点；-XX:CompileThreshold 可调（C1 默认 1500，C2 默认 10000）；超过阈值后在栈上替换（OSR，On-Stack Replacement）继续执行编译后的代码；
• 分层编译（Tiered Compilation，JDK 8 起默认开启）：C1（Client 编译器，编译快、优化浅） → C2（Server 编译器，编译慢、优化激进），热点代码先经 C1 快速编译，收集剖面信息后再由 C2 深度优化。

JIT 常见的代表性优化：方法内联、逃逸分析（栈上分配/标量替换/锁消除）、锁粗化、循环展开、公共子表达式消除、分支预测等。

相关参数：-XX:+TieredCompilation、-XX:CompileThreshold、-XX:-UseCompilation（调试用）。生产不必手调，但理解它能解释「为什么同一个方法跑久了会变快」和「为什么压测要预热」。

---

下一篇：《JVM（二）》进入垃圾回收——对象存活判定、GC 算法、Serial 到 ZGC 的收集器演进，以及三色标记、卡表写屏障等支撑机制。