概述纵观 Java 的发展历程一个完整意义上的 Java 虚拟机以主流的 HotSpot VM 为例其垃圾回收器的名单有很多包括了负责不同分区的老牌回收器以及一些有特定用途的“特种”回收器。下面这张图可以帮你从整体上理解它们的分类和配合关系分代收集器物理逻辑均分代分区收集器逻辑分代/物理不分代特殊用途特殊用途Epsilon无操作C4Azul Zing分区收集器G1ZGCShenandoahGenerational ZGCJDK 21分代收集器老年代收集器新生代收集器Serial Old标记-整理SerialCMS标记-清除ParNewParallel ScavengeParallel Old标记-整理垃圾回收器 经典分代收集器这是 JVM 历史上最经典的一类回收器。它们严格遵循“分代”理论将堆内存物理地划分为新生代和老年代并在不同区域使用不同的回收算法。回收器所属年代算法线程模型特点与地位状态Serial新生代复制算法单线程最基础的回收器。进行垃圾回收时会触发“Stop-The-World”STW即暂停所有应用线程。历史Serial Old老年代标记-整理算法单线程Serial 的老年代版本。常作为 CMS 的后备方案。历史ParNew新生代复制算法多线程Serial 的多线程版本。能与 CMS 配合是其老搭档。历史Parallel Scavenge新生代复制算法多线程JDK 8 及之前版本的默认收集器。侧重点是吞吐量优先。成熟Parallel Old老年代标记-整理算法多线程Parallel Scavenge 的老年代版本同样侧重吞吐量。是JDK 8 默认的 GC 组合。成熟CMS老年代标记-清除算法多线程首款真正意义上的并发收集器为追求低延迟而生。已在JDK 14 中被正式移除。淘汰️ 分区与超低延迟收集器随着硬件发展和应用对响应时间的要求越来越高GC 的设计开始从关注“吞吐量”转向关注“低延迟”。这一代的回收器打破了物理分代的限制采用了更灵活的内存布局和算法。回收器核心算法特点与地位默认/推荐JDKG1Region 复制算法平衡吞吐量和延迟提供可预测的停顿时间模型。自JDK 9 起成为默认垃圾回收器。JDK 9 默认ZGCRegion 染色指针 读屏障追求极致的低延迟亚毫秒级停顿暂停时间不随堆大小增长。JDK 15 起生产可用。从 JDK 21 开始引入了分代 ZGC 以进一步提升性能。JDK 21 推荐ShenandoahRegion 转发指针 读屏障与 ZGC 目标相似同样追求超低延迟主要由 OpenJDK 社区维护。JDK 15 起生产可用。JDK 15 可用️ 特殊用途收集器除了通用回收器Java 还提供了一些用于特定场景的“特种工具”。Epsilon GC一个“无操作”No-Op的回收器。它只分配内存从不回收当堆内存耗尽时JVM 会直接退出。主要用于性能测试、内存压力测试等以排除 GC 本身带来的性能干扰。C4 (Continuously Concurrent Compacting Collector)这是高性能商业虚拟机 Azul Zing 中的 GC。它利用“读屏障”等技术实现了无停顿的并发压缩即使是处理 TB 级的堆内存也能保持毫秒级的暂停。ShenandoahOpenJDK 的“超低延迟”GC。与 ZGC 类似也使用转发指针和读屏障技术通过“Brooks Pointer”实现并发对象移动。它是OpenJDK 独有的项目不在 OracleJDK 中提供。要获取你当前 Java 环境使用的垃圾回收器组合可以在命令行中尝试运行java-XX:PrintCommandLineFlags-version常用垃圾回收器Java常用垃圾回收器有Parallel Scavenge / Parallel Old CMSG1ZGC。要理解这几个垃圾回收器关键在于把握吞吐量、延迟STW暂停时间和内存大小这几个核心维度的权衡。下面我们逐一解析。1. Parallel Scavenge / Parallel Old这是JDK 8及之前版本的默认GC组合属于并行、分代、吞吐量优先的回收器。工作原理Parallel Scavenge年轻代采用复制算法。GC触发时所有工作线程同时暂停Stop-The-WorldSTW并行地复制存活对象到Survivor或老年代。Parallel Old老年代采用标记-整理算法。同样STW并行完成标记和整理消除内存碎片。核心特点它可以主动调节堆大小和分区比例来达到用户设定的吞吐量目标例如-XXGCTimeRatio99表示GC时间占比不超过1%。优点吞吐量极高因为GC时所有CPU核心都用来做清理没有并发阶段的额外开销。CPU利用率高非常适合计算密集型任务。实现简单管理内存开销小。缺点延迟高GC暂停时间与堆内存大小成正比。堆越大暂停时间越长可能达到数秒甚至十秒级。不可控无法将最大暂停时间控制在几十毫秒内。适用场景批处理任务、大数据计算如Hadoop离线任务、Spark SQL。后台作业编译、压测、科学计算。对响应时间不敏感但对处理数据总量有要求的场景。堆内存不大 4GB且CPU核数多的环境。2. CMS全称Concurrent Mark Sweep是JDK 8时代追求低延迟的首选但已在JDK 9中标记为废弃JDK 14中彻底移除。工作原理核心是分代标记-清除并发回收。主要分为4个阶段初始标记STW快速标记GC Roots直接引用的对象暂停很短。并发标记遍历整个对象图标记所有存活对象与应用线程并发执行耗时较长但无暂停。重新标记STW修正并发标记期间因用户程序运行而变动的标记暂停时间比初始标记稍长但仍可控。并发清除清除未被标记的对象并发执行。优点低延迟最耗时的两个阶段并发标记、并发清除都不暂停应用整体STW时间远低于Parallel。响应快适合交互式应用。缺点产生内存碎片标记-清除算法会导致大量不连续内存最终可能因无法分配大对象而触发Full GC此时退化为Serial Old暂停时间极长。浮动垃圾并发清理时用户线程仍在运行新产生的垃圾本次无法处理需要预留空间。CPU敏感并发阶段会抢占应用线程的CPU资源导致总吞吐量下降。可能发生“并发模式失败”如果老年代填满速度超过CMS回收速度会降级为Serial Old进行Full GC导致长时间停顿。对大型堆32GB表现不佳。适用场景Web服务器、微服务低延迟要求高但堆内存不超过32GB。中小型内存4GB - 32GB的在线应用。需要比Parallel更低的暂停时间但又承受不了G1的额外开销注意现在G1通常是更好的选择。3. G1全称Garbage First从JDK 9开始成为默认GC目标是在可控的暂停时间内实现高吞吐。工作原理分Region不再区分物理上的年轻代和老年代而是将整个堆划分为约2048个大小相等的Region。停顿预测模型用户可以指定期望的暂停时间如-XXMaxGCPauseMillis200G1会根据历史数据动态选择一批Region来回收这就是“Garbage First”名字的由来——优先回收垃圾最多的Region。回收过程年轻代回收将Eden区存活对象复制到Survivor或直接晋升到老年代Region。全程STW但并行执行。并发标记类似CMS的并发标记找出老年代Region中的垃圾。混合回收同时回收年轻代和部分高价值的老年代Region使用复制算法消除碎片。使用SATBSnapshot-At-The-Beginning算法处理并发标记时的对象引用变化。优点可预测的暂停时间通过控制每次回收的Region数量将暂停时间控制在用户期望范围内通常几十到两百毫秒。自动管理无需手动设定年轻代/老年代大小。内存整合本质上是复制算法无内存碎片。大堆支持良好设计目标之一是处理数十GB的堆。缺点CPU和内存开销略高需要维护Remembered SetRSet来记录跨Region引用占额外内存大约堆的5%-10%。吞吐量略低于Parallel因为有一些维护和并发的开销。Full GC可能发生当对象复制速度跟不上分配速度时会退化为单线程Serial Full GCJDK 10以后可并行Full GC。适用场景中等及以上堆内存6GB - 64GB甚至更大。对暂停时间有明确要求例如要求GC暂停200ms。替代CMS需要低延迟但不想处理CMS的碎片和并发模式失败问题。大多数通用服务端应用Spring Boot微服务、交易系统等。4. ZGC全称Z Garbage Collector从JDK 11引入目标是极其低延迟暂停时间不超过1ms甚至0.5ms且堆容量可到16TB。工作原理染色指针将指针的高位额外64位中的几位用于存储对象状态信息如是否可访问、是否在重定位中因此无需在对象头中保存额外标记信息。读屏障当应用线程从堆中读取对象引用时会触发一小段代码。这段代码会检查指针颜色如果对象正在被移动则帮助完成指针修复。并发几乎所有阶段标记、重定位、重映射都是并发的。唯一的STW阶段是“暂停所有线程以启动下一个GC周期”但这个暂停时间与堆大小无关通常小于1ms。优点亚毫秒级暂停STW时间恒定且极短1ms。超大堆支持可轻松处理从几百MB到16TB的堆。无碎片使用重定位技术压缩堆。高吞吐量JDK 15以后随着优化如JDK 14引入了指针压缩JDK 15成为生产就绪吞吐量已接近G1。缺点CPU负载较高读屏障在每个引用加载时都会执行会轻微增加CPU开销约5%-10%。内存占用染色指针需要更多的虚拟地址空间但其实物理内存占用尚可。JDK版本要求需要JDK 11且最好使用JDK 15的生产版本。不适用小于4GB的堆因为收益不明显且有一定开销。适用场景超低延迟系统如高频交易、实时分析、在线游戏服务端。巨型内存应用堆内存 64GB甚至达到1TB级别。要求极其稳定的延迟不能有任何超过几十毫秒的抖动。快速对比总结表特性Parallel Scavenge / OldCMSG1ZGC目标高吞吐量中低延迟平衡延迟与吞吐超低延迟1ms算法复制 标记-整理标记-清除复制 Region划分染色指针 读屏障STW暂停长随堆增大而增大中等但会碎片Full GC可控默认200ms内极短1ms恒定内存碎片无有无无CPU开销低中等并发阶段高中等较高堆大小建议2GB - 16GB4GB - 32GB6GB - 64GB16GB - 16TBJDK版本JDK 8默认JDK 8可用9废弃JDK 9默认JDK 15 生产就绪如何选择你的应用是批处理/后台计算不关心偶尔卡顿→Parallel Scavenge / Parallel Old(JDK 8) 或G1(JDK 11 设为吞吐量优先模式)你的应用是Web/微服务堆 8GB希望暂停 100ms→G1(JDK 9) 或Parallel(如果延迟要求不严)你的应用堆 8GB - 32GB对暂停敏感但无法升级JDK 8→CMS(但要做好参数调优并准备接受碎片风险) —— 更建议升级到JDK 11使用G1你的应用要求 GC 暂停 10ms甚至 1ms堆很大16GB→ZGC(JDK 15)如果完全不懂怎么选→ 使用你JDK版本的默认GCJDK 8默认Parallel。如果你只写业务代码且没调优过大概率还是这个。可以考虑主动切换为G1。JDK 11/17/21默认G1。这是最安全、最通用的选择。最后提醒GC的选择和调优需要结合监控数据GC日志、JMX指标来做。不要盲目追求ZGC如果你的应用暂停大部分在50ms以下G1可能已经足够好了。
