深入理解 Java 垃圾回收机制：从分代收集到 G1、ZGC 的演进

目录

深入理解 Java 垃圾回收机制：从分代收集到 G1、ZGC 的演进

一、Java GC 的分类体系

1. 分代垃圾回收器

2. 分区垃圾回收器

3. 按执行方式分类

二、主流垃圾回收器详解

1. Serial GC（JDK 1.3.1 前默认）

2. Parallel GC（吞吐量优先）

3. CMS（Concurrent Mark Sweep）

4. G1（Garbage-First）

5. ZGC（Z Garbage Collector）

6. Shenandoah GC

三、G1 GC 的核心工作机制

1. Region 分区设计

2. 回收阶段详解

四、G1 与 CMS 的对比分析

五、如何选择合适的 GC 回收器？

1. 考虑因素

2. JDK 版本建议

3. 典型配置示例

六、Java GC 的未来趋势

总结

---

在 Java 应用性能优化的旅程中，垃圾回收（GC）机制始终是绕不开的核心话题。从早期的 Serial GC 到如今的 G1、ZGC，Java 的 GC 技术经历了多次重大变革，每一次变革都旨在解决特定场景下的痛点。本文将全面解析 Java GC 的分类体系，并重点探讨 G1 垃圾回收器的工作原理与应用场景。

一、Java GC 的分类体系

Java 的垃圾回收器根据其设计理念、回收策略和应用场景可以分为以下几大类：

1. 分代垃圾回收器

基于 "分代假说"（Most objects die young）理论，将堆内存分为年轻代（Young Generation）和老年代（Old Generation）：

• 年轻代：新创建的对象在此区域，回收率高
• 老年代：长期存活的对象在此区域，回收频率低

代表回收器：Serial、Parallel、CMS、G1

2. 分区垃圾回收器

将堆内存划分为多个独立的区域（Region），提高回收效率：

• 代表回收器：G1、ZGC、Shenandoah

3. 按执行方式分类

• 并行回收器：多线程同时执行 GC，降低 STW 时间
• 并发回收器：GC 线程与应用线程交替执行，减少停顿
• 代表回收器：
  并行：Parallel Scavenge、Parallel Old
  并发：CMS、G1、ZGC

二、主流垃圾回收器详解

1. Serial GC（JDK 1.3.1 前默认）

• 特点：单线程执行，STW 时间长
• 适用场景：小型应用、客户端模式
• 启动参数：-XX:+UseSerialGC

2. Parallel GC（吞吐量优先）

• 特点：多线程并行回收，关注整体吞吐量
• 适用场景：科学计算、数据处理等 CPU 密集型任务
• 启动参数：
  -XX:+UseParallelGC（年轻代）
  -XX:+UseParallelOldGC（老年代）

3. CMS（Concurrent Mark Sweep）

• 特点：并发标记 - 清除，追求低延迟
• 工作流程：
  初始标记（STW）→ 并发标记 → 重新标记（STW）→ 并发清除
• 缺点：产生内存碎片、CPU 资源敏感
• 启动参数：-XX:+UseConcMarkSweepGC

4. G1（Garbage-First）

• JDK 版本：JDK 7u4 引入，JDK 9 起成为默认 GC
• 革命性设计：
  • 分区化：将堆划分为多个大小相等的 Region（默认 2048 个）
  • 分代混合：每个 Region 动态扮演 Eden、Survivor 或 Old 角色
  • 优先回收价值高：跟踪各 Region 的垃圾占比，优先回收收益最大的区域
  • 并发与并行结合：标记阶段与应用线程并发执行，减少 STW
  • 内存整理：采用复制算法，避免 CMS 的碎片问题
• 适用场景：大内存、多 CPU 的服务器应用，追求低延迟
• 核心参数：
  -XX:+UseG1GC（启用 G1）
  -XX:MaxGCPauseMillis=200（目标最大停顿时间，毫秒）
  -XX:G1HeapRegionSize=8m（Region 大小）

5. ZGC（Z Garbage Collector）

• JDK 版本：JDK 11 引入，JDK 15 起生产可用
• 突破性特性：
  • 几乎无停顿：STW 时间控制在 10ms 以内（无论堆多大）
  • 支持 TB 级内存：使用染色指针（Colored Pointers）和读屏障（Load Barrier）
  • 并发整理：完全并发的标记 - 整理算法
• 适用场景：超大堆内存（4TB+）、超低延迟要求（如金融交易）
• 启动参数：-XX:+UseZGC

6. Shenandoah GC

• 特点：与 ZGC 类似，追求极低延迟，OpenJDK 社区开发
• 适用场景：与 ZGC 类似，但对 JDK 版本支持略有不同

三、G1 GC 的核心工作机制

1. Region 分区设计

G1 将整个堆内存划分为多个大小相等的 Region（1-32MB，根据堆大小自动计算），每个 Region 可以动态扮演不同角色：

• Eden Region：存储新创建的对象
• Survivor Region：存储 GC 后存活的对象
• Old Region：存储长期存活的对象
• Humongous Region：专门存储大于 Region 一半大小的巨型对象

2. 回收阶段详解

G1 的垃圾回收过程分为四个主要阶段：

1. 初始标记（Initial Mark）

   • STW 阶段，标记 GC Roots 直接可达的对象
   • 与 Minor GC 同步进行，开销较小

2. 并发标记（Concurrent Marking）

   • 与应用线程并发执行，遍历所有对象
   • 标记存活对象，记录引用变化

3. 最终标记（Final Mark）

   • STW 阶段，处理并发标记阶段的遗留工作
   • 使用 SATB（Snapshot At The Beginning）算法确保一致性

4. 筛选回收（Evacuation）

   • 根据 Region 的回收价值（垃圾占比）排序
   • 多线程并行复制存活对象到新 Region，同时清理旧 Region
   • 此阶段会触发 STW，但通过优先处理高价值 Region 控制停顿时间

四、G1 与 CMS 的对比分析

特性	G1	CMS
算法类型	标记 - 整理（无碎片）	标记 - 清除（产生碎片）
STW 时间	可控（通过 -XX:MaxGCPauseMillis）	较长（尤其在 Full GC 时）
内存布局	分区（Region）	分代（Young/Old）
并发程度	并发与并行结合	主要依赖并发
适用场景	大内存、低延迟	中小内存、重视响应时间

五、如何选择合适的 GC 回收器？

1. 考虑因素

• 堆内存大小：
  小堆（<4GB）：Serial/Parallel
  中堆（4-16GB）：G1
  大堆（>16GB）：G1/ZGC

• 应用延迟要求：
  高要求（<100ms）：G1/ZGC
  中等要求：CMS
  低要求：Parallel

• CPU 核心数：并行回收器需要多核支持，单核环境慎用

2. JDK 版本建议

• JDK 8：默认 Parallel，推荐手动启用 G1（-XX:+UseG1GC）
• JDK 9+：默认 G1
• JDK 11+：大内存 / 低延迟场景推荐 ZGC（-XX:+UseZGC）

3. 典型配置示例

bash

# G1配置（适合8GB+内存的低延迟应用）
java -Xmx16g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar

# ZGC配置（适合TB级内存的超大型应用）
java -Xmx4096g -XX:+UseZGC -XX:ConcGCThreads=4 -jar app.jar

六、Java GC 的未来趋势

1. ZGC/Shenandoah 成为主流
   随着云原生和微服务架构的普及，对超低延迟 GC 的需求将推动 ZGC 和 Shenandoah 逐渐取代 G1。

2. Epsilon GC 的特殊应用
   作为实验性的 "无操作"GC，Epsilon 不执行任何垃圾回收，仅用于性能测试和特殊场景。

3. 提前编译（AOT）技术的崛起
   GraalVM 等技术通过 AOT 编译减少对 GC 的依赖，可能改变未来 Java 应用的部署方式。

总结

Java 的垃圾回收机制从早期的简单分代收集，发展到 G1 的分区化智能回收，再到 ZGC 的近乎无停顿回收，每一次演进都在不断突破性能瓶颈。对于开发者而言，理解不同 GC 的特性和适用场景，合理配置 JVM 参数，是优化 Java 应用性能的关键。在未来，随着硬件性能提升和应用场景复杂化，GC 技术也将持续创新，为 Java 生态带来更高效、更智能的内存管理方案。