常用垃圾回收器对比
以下是主流Java垃圾回收器的对比分析，结合不同特性、适用场景及版本演进进行总结：
一、基础型回收器
Serial/Serial Old
• 算法：新生代（复制算法），老年代（标记-整理算法）。
• 特点：单线程执行，全程STW（Stop-The-World），简单高效但停顿时间长。
• 适用场景：客户端程序、小型微服务（内存<200MB）或硬件资源受限环境。
• 缺点：多核CPU下吞吐量低，大堆场景停顿不可接受。
ParNew
• 算法：新生代多线程并行复制算法。
• 特点：Serial的多线程版本，需与CMS配合，默认线程数与CPU核数相同。
• 适用场景：JDK8及之前与CMS搭配，注重低延迟的Web服务。
• 缺点：JDK9后逐渐被G1取代，仅用于兼容旧系统。
二、吞吐量优先型
Parallel Scavenge/Old
• 算法：新生代（复制算法），老年代（标记-整理算法）。
• 特点：多线程并行回收，关注吞吐量而非单次停顿时间，支持自适应调整堆参数。
• 适用场景：后台批处理、大数据计算（如Hadoop）。
• 缺点：无法保证单次停顿时间，交互式应用体验差。
三、低延迟型
CMS（Concurrent Mark Sweep）
• 算法：老年代标记-清除算法，并发执行以减少停顿。
• 特点：
◦ 并发标记阶段允许用户线程运行，仅部分阶段STW。
◦ 存在内存碎片问题，需Full GC时整理（默认触发条件为内存不足）。
• 适用场景：高并发Web服务（如电商订单系统），JDK8及之前的主流选择。
• 缺点：内存碎片导致频繁Full GC，JDK14后废弃。
G1（Garbage-First）
• 算法：分Region回收（复制+标记-整理），支持混合回收（Mixed GC）。
• 特点：
◦ 可预测停顿时间（通过
-XX:MaxGCPauseMillis设置）。◦ 适用于大堆（>4GB），无内存碎片问题。
• 适用场景：JDK9+默认回收器，兼顾吞吐量和低延迟。
• 缺点：小堆场景性能不如CMS，内存占用较高。
四、新一代超低延迟型
Shenandoah
• 特点：Red Hat开发，并发整理，堆大小对STW无影响，停顿<10ms。
• 适用场景：对延迟极度敏感的系统（如实时交易）。
ZGC
• 特点：Oracle开发，基于染色指针技术，STW<1ms，支持TB级堆。
• 适用场景：超大内存（16TB+）、云原生及实时系统（如金融高频交易）。
五、选择建议
| 场景需求 | 推荐回收器 | JDK版本 |
|---|---|---|
| 小型应用/客户端程序 | Serial/Serial Old | 全版本 |
| 后台批处理（高吞吐量） | Parallel Scavenge + Old | JDK8及之前 |
| 高并发Web服务（低延迟） | CMS（JDK8）或G1（JDK9+） | JDK8/9+ |
| 大堆且需平衡吞吐量与延迟 | G1 | JDK9+（默认） |
| 超低延迟（毫秒级响应） | Shenandoah/ZGC | JDK11+ |
六、版本演进与弃用
• JDK8：默认Parallel Scavenge/Old，CMS主流。
• JDK9+：G1成为默认，CMS标记为废弃。
• JDK14：移除CMS，弃用Parallel Scavenge/Old。
通过合理选择回收器，结合-Xmx、-XX:MaxGCPauseMillis等参数调优，可显著提升应用性能。具体配置需结合GC日志分析工具（如GCEasy）进行监控和优化。