Java 性能优化之分代回收原理与选择

什么是分代回收？

Java 虚拟机将堆内存划分为不同的区域，即“分代”，以适应对象生命周期的不同特征。在使用 jvisualvm 等监控工具观察堆内存时，通常可以看到以下几个数据块：

从左到右区域说明如下：

• Metaspace：元空间，用于存储类加载信息。
• Old：老年代，存储生命周期较长的对象。
• Eden + S0 + S1：这三部分共同组成年轻代（Young Generation）。

年轻代内部结构：

• Eden 区：新创建的对象主要分配在此区域。
• S0 和 S1（Survivor 区）：幸存者区，分为 From 和 To，用于暂存经过清理后仍然存活的对象。

目前市面上主流的垃圾收集器（如 Serial、Parallel、CMS、G1 等）均基于这种分代假设进行设计，但在具体实现细节上存在显著差异。本章重点聚焦于年轻代和老年代的回收机制。

为什么采用分代回收？

大多数对象具有朝生夕灭的特征，只有少部分对象能跨越多个生命周期。将堆内存按年龄分层，可以使垃圾收集器更有针对性地执行回收操作，从而减少因垃圾回收导致的 Stop The World (STW) 停顿时间。

年轻代回收（Minor GC）

对象创建后首先被分配到年轻代的 Eden 区。当 Eden 区空间不足时，触发 Minor GC。此时 JVM 会暂停所有应用线程（STW），执行以下步骤：

1. 扫描并回收 Eden 区中不再引用的对象。
2. 将存活对象移动到 Survivor 区（S0 或 S1）。
3. 若 Survivor 区容量不足或对象年龄达到阈值，晋升至老年代。

分代算法的核心优势在于：

• 局部回收：仅处理年轻代这一小部分堆空间，相比全堆扫描，耗时更短，STW 时间可控。
• 内存整理：Eden 区的清空本质上是一次内存压缩，避免了碎片化，保持内存连续可用。

尽管年轻代回收频率较高，但每次停顿时间极短，对用户体验影响微弱。

老年代回收（Major GC / Full GC）

当长期存活的对象逐渐积累，老年代空间被填满时，将触发 Full GC（或 Major GC）。此过程同样需要 STW，且由于涉及整个堆及元空间的扫描、复制和整理，耗时较长。

长时间的全停会对高并发、低延迟的业务造成严重影响，因此 Full GC 的频率和执行时间是 JVM 调优的关键指标。

高级回收方式：并发收集器

传统分代回收依赖串行或并行算法，必须暂停用户线程才能进行标记和清除。为降低 STW 时间，现代 JVM 引入了并发垃圾收集器（如 CMS 和 G1）。

• CMS（Concurrent Mark Sweep）：通过后台线程与用户线程并行工作，尽量减少标记阶段的停顿。
• G1（Garbage First）：将堆划分为多个独立区域，可并行且并发地进行垃圾回收，并能预测停顿时间。

这些收集器被称为低停顿收集器，它们以消耗更多 CPU 资源为代价，换取更流畅的应用体验。

垃圾收集器的权衡与选择

没有绝对完美的收集器，只有最适合业务场景的选择。决策时需权衡以下三个核心指标：

1. 吞吐量（Throughput）

指单位时间内用户代码执行时间与总时间的比值。适合大批量离线数据处理或后台批处理任务。

• 推荐：Parallel Scavenge + Parallel Old 收集器。它们最大化 CPU 利用率，虽然 STW 时间可能较长，但整体处理效率高。

2. 响应时间（Response Time）

指单次请求的处理速度。适合 Web 服务、API 接口等高交互性场景，要求尽量避免卡顿。

• 推荐：CMS 或 G1 收集器。它们通过并发算法将停顿控制在毫秒级以内，保障快速响应。

3. CPU 资源消耗

并发收集器需要在后台维护复杂的标记和清理逻辑，这会占用额外的 CPU 周期。如果服务器 CPU 资源紧张，需评估并发带来的开销是否超出收益。

综上所述，理解分代回收原理是 Java 性能优化的基础。对于实时性要求高的系统，应优先关注 G1 等低停顿收集器的参数配置；对于计算密集型任务，则可选择吞吐量优先的组合。

以上就是 Java 性能优化之分代回收原理与选择的详细内容，更多关于 Java 垃圾回收器调优的资料请关注本站其它相关文章！