首页 > 编程语言 >JVM常用GC策略对比与性能分析

JVM常用GC策略对比与性能分析

来源：互联网 2026-07-10 08:03:01

选对GC策略需在吞吐量、延迟和内存占用间权衡。年轻代采用复制算法，差异在于STW控制；老年代中Parallel吞吐优先，G1均衡，ZGC/Shenandoah极致低延迟。关键参数如-Xmn、PretenureSizeThreshold等直接影响回收效率。日志分析可识别对象过早晋升、内存压力等模式。

选对GC策略，从来不是一句“哪个好用”就能回答的问题。它本质上，是在吞吐量、延迟和内存占用（footprint）这三个维度之间，反复权衡、寻找那个最合适的平衡点。没有所谓“最好”的收集器，只有和你的业务场景最“匹配”的组合。

年轻代回收：复制算法是主流，但停顿大不同

这一点上，各家倒是出奇一致。从Serial、Parallel到CMS、G1，乃至最新的ZGC，年轻代回收的核心都是复制算法（Eden + Survivor这个经典组合）。流程上也没什么悬念：对象先在Eden区分配，Minor GC触发时，把存活下来的对象复制到Survivor区，年龄攒够了就晋升到老年代。真正的差异，体现在并发能力和线程模型上——用大白话说就是：全面暂停 vs 可控暂停。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

Serial和Parallel是典型的“暴脾气”：年轻代回收期间，所有应用线程都得停下，专心等它干完活（STW）。
G1、ZGC、Shenandoah虽然年轻代也会STW，但厉害的地方在于，它们能把单次停顿控制在极短的时间内（通常 < 10ms，甚至更低），让系统几乎感觉不到。

不过，这里有个很容易被忽略的细节：Survivor区的大小和晋升阈值（-XX:MaxTenuringThreshold）这两个参数，直接决定了对象会不会“过早地”被扔进老年代。如果出现“Promotion Failed”或者日志里“tenuring distribution”分布异常，那你就得琢磨一下，是不是该调调这两个值了。

老年代回收：一场吞吐与延迟的取舍

老年代的回收成本远高于年轻代，它的策略选择，基本就锁死了系统最终的响应表现。我们一个一个来看：

Parallel GC（吞吐优先）：用的是标记-整理算法，STW时间比较长，但能一次性把活干完，总耗时短。非常适合那些对延迟“心比较大”的场景，比如批处理、后台任务。
CMS（曾经的先行者，已退场）：JDK 9起就被标记为deprecated，JDK 14彻底移除。它靠并发标记+清除来缩短停顿，但后果是容易产生内存碎片，且一旦碎片严重，反而会触发代价更高的Full GC。属于典型的“小错不断，大错也犯”。
G1（均衡派的主力）：把堆划分成很多个Region，基于你设定的停顿时间目标，优先回收垃圾最多的区域。兼顾了吞吐和延迟（目标停顿 < 200ms），算是目前最通用的选择。
ZGC / Shenandoah（低延迟的标杆）：通过染色指针或转发指针，实现了几乎全程并发回收。STW时间压缩到毫秒级（ZGC目标 < 10ms），为响应式系统而生。

关键参数：有时候比直接换收集器还管用

调优久了会发现，参数配置往往比直接换收集器更见功夫。几个关键的调试点值得反复打磨：

-Xmn（年轻代大小）：一个经典的“跷跷板”问题。设小了，Minor GC会非常频繁；设大了，虽然GC次数少了，但单次STW时间会拉长，还可能挤占老年代的空间。没有标准答案，全看业务。
-XX:PretenureSizeThreshold（大对象阈值）：设定一个尺寸，超过这个大小的对象直接晋升老年代。这么做是为了避免它们在年轻代里来回复制，既消耗CPU，又可能导致碎片，甚至引发提前晋升。
G1独有参数：-XX:G1HeapRegionSize控制Region大小，影响大对象分配；-XX:MaxGCPauseMillis则是G1的停顿目标，注意它不是硬性保证，但会驱动GC动态地调整回收节奏。
-XX:+UseStringDeduplication（G1）：一个挺实用的小技巧，能帮你去掉重复的字符串对象。对于处理大量JSON或文本的服务，内存节省效果往往令人惊喜。

怎么看日志，才能真正判断问题

聪明地读日志，不是扫一眼看有没有Full GC这么简单，关键是要读出背后的“模式”：

如果连续多次Minor GC后，老年代的水平持续缓慢爬坡，那就要警惕了：要么是内存泄漏，要么就是对象过早晋升。这时候就该翻看晋升日志，找找“元凶”。
如果Minor GC频率很稳定，但每次回收后Eden区使用率依然居高不下，那很可能是年轻代设得太小了，压根装不下瞬时的分配压力。
在G1日志里，如果频繁出现“to-space exhausted”或“Evacuation Failure”这两个关键词，说明Region的回收压力已经很大了。通常的解法是：要么增大堆内存，要么降低停顿目标，让GC稍稍“慢一点”，别那么激进。
对于ZGC，值得警惕的是日志里“Pause Phases”时间突然增加。这往往意味着内存分配速率出现了激增，或者元数据区（Metaspace）压力过大。

JVM常用GC策略对比与性能分析