Java虚拟机JVM提供了多种垃圾回收器每种都有其独特的工作原理、适用场景和性能特点。以下是主流垃圾回收器的详细解析。1. Serial / Serial Old 收集器Serial 和 Serial Old 是历史最悠久的收集器分别用于新生代和老年代均为单线程工作。工作原理Serial新生代采用复制算法。它将新生代划分为一个Eden区和两个Survivor区。垃圾回收时会触发“Stop-The-World”STW暂停所有用户线程。随后单线程将Eden和一个Survivor区中存活的对象复制到另一个空的Survivor区然后清空Eden和已使用的Survivor区。Serial Old老年代采用标记-整理算法。同样在STW下单线程进行标记、整理将存活对象向一端移动和清除。核心特点简单高效在单核或内存极小的环境下由于没有线程交互开销效率很高。STW时间长单线程处理在堆内存较大或对象较多时停顿时间会很长。适用场景客户端模式如桌面应用或内存资源极其有限的嵌入式系统。在JDK的客户端模式下如使用-client参数可能是默认选项。启用参数-XX:UseSerialGC2. ParNew 收集器ParNew 是 Serial 收集器的多线程并行版本仅用于新生代。工作原理与 Serial 收集器完全相同也采用复制算法。关键区别在于垃圾回收时会使用多个GC线程并行地进行垃圾回收从而在多核CPU环境下缩短STW时间。核心特点除了多线程并行回收外其他行为如内存分配策略、控制参数与Serial收集器一致。在JDK 9及之后ParNew 不再被推荐与 CMS 搭配使用CMS 有了新的并行年轻代收集器ParNew已被标记为废弃。适用场景需要与 CMS 收集器配合使用的历史场景在JDK 8及之前。多核服务器上追求比 Serial 更短的新生代回收停顿。启用参数-XX:UseParNewGC3. Parallel Scavenge / Parallel Old 收集器这是一对吞吐量优先的收集器组合分别用于新生代和老年代。工作原理Parallel Scavenge新生代采用复制算法的多线程并行收集器。它的目标是达到一个可控制的吞吐量。吞吐量 运行用户代码时间 / (运行用户代码时间 垃圾回收时间)。Parallel Old老年代采用标记-整理算法的多线程并行收集器是 Parallel Scavenge 的老年代版本。核心特点吞吐量优先可以通过参数如-XX:GCTimeRatio精确设置期望的吞吐量目标收集器会自适应调整堆大小等参数来尽可能达到目标。自适应调节提供了-XX:UseAdaptiveSizePolicy参数默认开启JVM会根据运行情况动态调整新生代大小、Eden与Survivor比例等以优化性能。适用场景后台运算、科学计算、批处理任务等这类应用对高吞吐量有要求对停顿时间不敏感。启用参数-XX:UseParallelGC # 启用 Parallel Scavenge新生代 -XX:UseParallelOldGC # 启用 Parallel Old老年代通常两者一起使用 # 或者直接使用 -XX:UseParallelGC4. CMS (Concurrent Mark Sweep) 收集器CMS 是一个以获取最短回收停顿时间为目标的老年代收集器基于标记-清除算法其工作过程较为复杂。工作原理分为四个阶段初始标记 (Initial Mark)STW。仅标记与GC Roots直接关联的老年代对象。速度很快。并发标记 (Concurrent Mark)并发执行。从初始标记的对象出发遍历整个老年代对象图。此阶段与用户线程并发耗时较长但不会暂停应用。重新标记 (Remark)STW。修正并发标记期间因用户线程继续运行而导致标记产生变动的对象。这个阶段停顿时间通常比初始标记长但远短于并发标记的总体时间。并发清除 (Concurrent Sweep)并发执行。清除未被标记即死亡的对象回收空间。此阶段也与用户线程并发。核心特点与缺点低延迟大部分标记和清除工作与用户线程并发显著减少了STW时间。对CPU资源敏感并发阶段会占用一部分CPU资源导致应用程序吞吐量降低。无法处理“浮动垃圾”并发清除阶段用户线程可能产生新的垃圾这些垃圾只能留待下一次GC回收因此CMS不能像其他收集器那样等到老年代几乎满了再收集需要预留空间通过-XX:CMSInitiatingOccupancyFraction设置触发百分比。内存碎片使用标记-清除算法会产生内存碎片。可能导致Full GCSerial Old提前触发或大对象无法分配。适用场景互联网B/S架构的服务端应用对服务响应速度要求高能够接受一定的吞吐量损失和内存碎片风险。在JDK 8时代是许多Web应用的首选低延迟收集器。启用参数-XX:UseConcMarkSweepGC5. G1 (Garbage-First) 收集器G1 是面向服务端应用的垃圾收集器目标是在延迟可控的情况下获得尽可能高的吞吐量。它采用了全新的分区Region模型。核心设计Region分区G1将整个Java堆划分为多个大小相等1M-32M的独立区域Region。物理上不再坚持固定的新生代/老年代划分但逻辑上仍然保留分代概念。每个Region都可以根据需要扮演Eden、Survivor或Old角色。收集集合 (CSet)每次垃圾回收时G1会选取一部分Region作为回收目标这些Region的集合称为CSet。选择的标准是回收效益最大化即优先回收垃圾最多的RegionGarbage-First名字的由来。记忆集 (RSet)每个Region都有一个对应的记忆集用于记录其他Region中的对象对本Region的引用。这使得G1在进行新生代回收Young GC时无需扫描整个老年代只需扫描RSet即可确定跨代引用大大减少了扫描范围。工作模式年轻代GC (Young GC)当Eden区满时触发。STW采用复制算法将Eden区和Survivor区From的存活对象复制到新的Survivor区To或晋升到老年代Region。整个过程是多线程并行执行的。并发标记周期 (Concurrent Marking Cycle)当堆内存使用达到一定阈值默认45%时触发目的是标记老年代Region中的存活对象。过程类似于CMS但针对整个堆初始标记STW伴随一次Young GC进行。根区域扫描扫描Survivor区对老年代的引用。并发标记并发遍历堆标记存活对象。最终标记STW处理SATBSnapshot-At-The-Beginning记录完成标记。清理STW统计各Region存活对象比例识别完全空闲的Region并决定哪些Region加入下次Mixed GC的CSet。混合回收 (Mixed GC)在并发标记周期之后G1会开始进行多次Mixed GC。它不仅回收年轻代Region还会回收一部分被标记为垃圾比例高的老年代Region根据预设的停顿时间目标-XX:MaxGCPauseMillis选择。采用复制算法将选定Region中的存活对象复制到空闲Region。核心特点可预测的停顿时间模型通过设置-XX:MaxGCPauseMillis默认200msG1会尽力保证在一次回收周期内的停顿时间不超过这个目标值。空间整合整体上看是基于“标记-整理”算法Region之间是复制算法但都意味着回收后不会产生内存碎片。权衡吞吐与延迟旨在提供相对CMS更稳定的停顿时间同时保持较高的吞吐量。适用场景需要低延迟且堆内存较大如6GB以上的应用。从JDK 9开始成为服务端模式的默认垃圾收集器。启用参数-XX:UseG1GC -XX:MaxGCPauseMillis200 # 设置期望的最大停顿时间目标毫秒6. ZGC 与 Shenandoah 收集器它们是JDK 11及以后引入的超低延迟收集器目标是将STW停顿时间控制在10毫秒以内甚至达到亚毫秒级且停顿时间不随堆大小增长而显著增加。共同核心思想并发处理将标记、转移移动存活对象、重定位更新引用等最耗时的阶段全部与用户线程并发执行。使用读屏障在应用程序读取对象引用时插入屏障代码协助完成并发阶段的工作如处理对象移动后的指针更新这与G1/CMS主要在写时使用写屏障不同。区域划分类似G1将堆划分为多个区域ZGC称为PageShenandoah称为Region但管理更精细。ZGC 特点染色指针将对象标记信息如存活、转发地址存储在对象指针本身的几位中而非对象头里。这减少了内存访问开销是ZGC实现高并发性的关键。支持NUMA对非统一内存访问架构有更好的支持。Shenandoah 特点Brooks指针在每个对象头前增加一个额外的转发指针。当对象被移动时旧位置保留这个转发指针指向新地址从而允许并发转移时用户线程通过旧地址也能访问到对象。适用场景超大堆内存数百GB至TB级别的应用如大数据平台、实时分析系统。对响应时间有极致要求无法接受超过10ms停顿的金融交易、电信核心网等场景。启用参数# 启用 ZGC (JDK 15 生产可用) -XX:UseZGC # 启用 Shenandoah (需要OpenJDK或特定发行版支持) -XX:UseShenandoahGC总结对比收集器目标工作区域算法线程模式关键优点关键缺点/挑战最佳适用场景Serial / Serial Old简单高效新生代/老年代复制/标记-整理单线程单核下效率高无交互开销STW时间长客户端、微嵌入式系统ParNew缩短新生代STW新生代复制多线程并行多核下新生代回收更快仅新生代需搭配其他老年代收集器历史搭配CMS使用Parallel Scavenge / Old高吞吐量新生代/老年代复制/标记-整理多线程并行吞吐量可控自适应调节STW停顿时间不可控后台计算、批处理CMS低延迟老年代标记-清除并发与并行混合并发收集停顿时间短CPU敏感、内存碎片、浮动垃圾响应速度优先的B/S服务JDK8时代G1可控延迟与高吞吐整个堆Region复制/标记-整理并发与并行混合可预测停顿空间整合内存占用稍高RSet等调优复杂大内存服务端应用JDK9默认ZGC / Shenandoah超低延迟整个堆并发标记-整理几乎全并发亚毫秒至10ms级停顿堆大小无关JDK版本要求高可能牺牲部分吞吐超大堆、极致低延迟场景选择垃圾回收器时需根据应用的性能目标吞吐量 vs 延迟、硬件资源CPU核心数、内存大小和JDK版本进行综合考量。通常从G1开始尝试是一个稳妥的选择对于有特殊极致需求的场景再考虑ZGC或Shenandoah。参考来源【面试精讲】Java有哪些垃圾回收器工作原理都是什么它们有什么区别高效内存管理与性能优化Java Hotspot G1 GC全景解析提升JVM性能CMS垃圾回收器的优化分析与案例研究深入JVM详解G1垃圾回收器原理Java垃圾回收器JVM垃圾回收器介绍和对比