1. JVM 内存结构是怎样的？各个区域作用是？

标准答案

JVM 的内存结构由堆（Heap）、方法区（Method Area）、虚拟机栈（Java Stack）、本地方法栈（Native Stack）、程序计数器（PC Register）组成。堆是对象存储的核心区域，方法区存储类元数据，虚拟机栈用于方法调用和局部变量存储，本地方法栈用于 JNI 调用，程序计数器记录当前线程的执行位置。这些区域的设计保障了 Java 运行时的高效性，同时也对 GC 及性能优化有重要影响。

答案解析

JVM 的内存可以分为线程共享区域和线程私有区域：

线程共享区域（所有线程共享，受 GC 影响）

• 堆（Heap）
  • 存放所有 Java 对象实例，由 GC 负责管理。
  • 堆进一步分为：
    • 新生代（Young Generation）
      • Eden 区：新创建的对象首先分配到这里。
      • Survivor 区（S0 和 S1）：Eden 区 GC 后幸存的对象转移到 Survivor，再次 GC 后可能晋升到老年代。
    • 老年代（Old Generation）
      • 存放存活时间较长的对象，Minor GC 期间未被回收的对象最终晋升到老年代。
    • 大对象（Large Object）
      • 一般情况下，超过一定大小（如 1MB 以上）的对象会直接分配到老年代，避免在 Survivor 区频繁复制。
• 方法区（Method Area）（JDK 8 以前是永久代，JDK 8+ 使用 Metaspace）
  • 存储类元数据（类的名称、字段、方法、运行时常量池）、JIT 编译后的代码等。
  • JDK 8 以前，方法区使用 永久代（PermGen），但由于管理难度大，在 JDK 8 之后被 元空间（Metaspace） 取代。

线程私有区域（每个线程独立拥有，不受 GC 影响）

• 虚拟机栈（Java Stack）
  • 每个线程独立拥有，存储方法调用的 栈帧（Stack Frame），每个栈帧包含：
    • 局部变量表（Local Variable Table）：存储基本数据类型和对象引用。
    • 操作数栈（Operand Stack）：用于字节码指令计算。
    • 动态链接（Dynamic Linking）：指向运行时常量池的方法引用。
    • 方法返回地址：存储方法执行完毕后的返回信息。
  • 栈溢出（StackOverflowError）：方法调用层级过深，导致栈空间不足。
• 本地方法栈（Native Stack）
  • 用于 JNI（Java Native Interface） 本地方法调用。
  • 可能会因为本地方法调用过多或递归过深导致 StackOverflowError。
• 程序计数器（PC Register）
  • 记录当前线程执行的 字节码指令地址，用于线程切换后恢复执行状态。
  • 由于每个线程都有独立的 PC 寄存器，因此不会发生 OOM。

JVM 内存管理策略

JVM 采用 分代管理 机制对堆进行优化：

1. 新生代 GC（Minor GC）：发生在新生代（Eden + Survivor），使用 复制算法，GC 频率高但耗时短。
2. 老年代 GC（Major GC 或 Full GC）：发生在老年代，通常采用 标记-整理（Mark-Compact） 或 标记-清除（Mark-Sweep） 算法，GC 频率低但耗时长。
3. 永久代/元空间管理：JDK 8 之后，类元数据存储在 元空间（Metaspace），可以动态调整大小，避免 OutOfMemoryError: PermGen，但如果 Metaspace 设置不合理，仍然可能发生 OOM。

常见错误及优化策略

错误 1：堆内存不足导致 OOM

• 现象：java.lang.OutOfMemoryError: Java heap space
• 解决方案：
  • 通过 -Xmx 和 -Xms 增大堆内存。
  • 通过 -XX:NewRatio 调整新生代与老年代比例，优化对象存活率。

错误 2：栈溢出（StackOverflowError）

• 现象：递归调用过深，导致栈空间耗尽。
• 解决方案：
  • 通过 -Xss 调整栈大小（一般 512K - 1M）。
  • 避免无限递归或深度递归调用。

错误 3：Metaspace OOM

• 现象：java.lang.OutOfMemoryError: Metaspace，通常由于大量动态生成的类导致元空间溢出。
• 解决方案：
  • 通过 -XX:MaxMetaspaceSize=512m 限制元空间大小。
  • 使用 jmap -clstats 检查类加载情况，避免重复加载类。

错误 4：GC 频繁导致应用卡顿

• 现象：GC 日志显示 Full GC 频繁，应用长时间停顿（STW）。
• 解决方案：
  • 调整 -XX:InitiatingHeapOccupancyPercent 限制老年代 GC 触发阈值。
  • 使用 G1GC 或 ZGC 代替 CMS，减少 STW 停顿。

深入追问

1. 为什么 JDK 8 取消永久代？Metaspace 如何管理内存？
2. 如何通过 GC 日志判断 Minor GC 和 Full GC 是否频繁？如何优化？
3. G1 和 ZGC 如何优化堆管理？它们是如何减少 STW 停顿的？
4. Java 线程栈大小如何影响性能？栈设置过大会导致什么问题？
5. JVM 是如何优化对象分配和回收的？TLAB 在对象分配中的作用是什么？

相关面试题

• Java 对象的分配策略，TLAB 和大对象如何分配？
• 什么是垃圾回收根（GC Root），如何判断对象是否存活？
• CMS、G1、ZGC 的主要区别，它们各自的适用场景是什么？
• 如何使用 jmap、jstack、jstat 监控 JVM 内存？
• 如何分析 Java OOM 问题？Metaspace OOM 的解决方案是什么？