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或特定版本支持
- ZGC：
如何根据业务需求选择合适的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免费学习笔记（深入）”；
