Java的垃圾回收器（Garbage Collector，简称GC）是JVM中自动管理内存的核心机制。它负责回收不再使用的对象所占用的内存空间，从而避免内存泄漏和手动释放内存带来的风险。不同的垃圾回收器适用于不同的应用场景，选择合适的GC对程序性能至关重要。

常见的垃圾回收器分类及特点

目前主流的JVM（如HotSpot）提供了多种垃圾回收器，主要分为以下几类：

1. Serial GC：单线程回收器

• 适用场景：客户端模式或小型应用
• 特点：
  • 使用单个线程进行垃圾回收，简单高效
  • 在执行GC时会暂停所有用户线程（Stop-The-World）
  • 内存占用小，适合运行在单核CPU或内存较小的环境中
• 使用参数：-XX:+UseSerialGC

2. Parallel Scavenge GC：多线程吞吐优先回收器

• 适用场景：注重吞吐量的后端服务
• 特点：
  • 多线程并行执行GC，提升效率
  • 主要关注“吞吐量”（应用程序运行时间 / 总时间）
  • 年轻代使用复制算法，老年代使用标记-整理算法
• 使用参数：-XX:+UseParallelGC

3. CMS（Concurrent Mark Sweep）GC：低延迟回收器

• 适用场景：需要响应时间较短的应用，如Web服务器
• 特点：
  • 以低停顿为目标，适合交互式系统
  • 老年代GC过程分为多个阶段，部分阶段与用户线程并发执行
  • 存在“并发模式失败”和“内存碎片”问题
• 使用参数：-XX:+UseConcMarkSweepGC（注意：JDK9开始废弃，JDK14移除）

4. G1（Garbage First）GC：平衡吞吐与延迟的分区回收器

• 适用场景：堆内存较大、希望兼顾吞吐和响应时间的系统
• 特点：
  • 将堆划分为多个大小相等的Region
  • 可预测的停顿时间模型，优先回收垃圾最多的区域
  • 支持并发执行，减少停顿时间
• 使用参数：-XX:+UseG1GC（JDK7+推荐使用）

5. ZGC 和 Shenandoah：新一代低延迟GC

• 适用场景：超大堆内存（TB级）且要求极低延迟的系统
• 特点：
  • 几乎所有阶段都可以与用户线程并发执行
  • ZGC支持TB级堆，停顿时间通常小于10ms
  • Shenandoah也主打低延迟，适合高并发场景
• 使用参数：
  • ZGC：-XX:+UseZGC
  • Shenandoah：第三方JVM或特定版本支持

如何根据业务需求选择合适的GC？

选择GC的关键在于理解你的应用类型和性能目标。下面是一些实用建议：

关注点一：吞吐量 vs 响应时间

• 如果你运行的是后台批处理任务，更看重整体吞吐量，可以选择 Parallel Scavenge GC
• 如果是在线服务系统，例如Web应用、API服务，需要快速响应请求，建议选择 G1 GC 或 CMS（已过时）

关注点二：堆内存大小

• 堆内存较小（比如几百MB以内），Serial GC 是轻量而高效的选择
• 堆内存超过几十GB，考虑使用 G1 GC
• 若堆达到TB级别，追求更低延迟，可以尝试 ZGC 或 Shenandoah

关注点三：GC停顿对业务的影响

• 对停顿敏感的系统（如金融交易、实时计算），应避免长时间STW（Stop-The-World）
• 这类场景下，G1、ZGC 和 Shenandoah 更合适

实际选型的一些建议

• 默认选择 G1 GC：从 JDK9 开始，G1 成为默认GC，适应大多数通用场景
• 不要盲目追求低延迟：ZGC 和 Shenandoah 虽然停顿短，但配置复杂，且可能牺牲一些吞吐能力
• 测试验证最重要：不同GC在实际负载下的表现差异可能很大，建议通过压力测试观察GC日志，对比吞吐量、停顿时长等指标

总结一下

Java中的GC种类多样，各有侧重。选择合适的垃圾回收器，关键是看你的应用对吞吐、延迟、堆大小的具体要求。如果你不确定该用哪个，先用 G1 GC，然后根据实际运行情况调整。基本上就这些，不复杂但容易忽略细节的地方还是得靠实测来验证。

立即学习“Java免费学习笔记（深入）”；