JVM 垃圾回收器的选择与应用原则

选JVM垃圾回收器，说白了就是做取舍：要么保吞吐量，要么压停顿时间，世上根本没有“全能型选手”。关键不在于参数设置得多花哨，而在于是否真正匹配你的应用负载特征。举个例子，一个支付接口每秒扛5000请求，哪怕堆内存只设了2G，用Serial GC的话，用户等得都能产生幻觉；而一个夜间跑报表的批处理任务，硬上ZGC反而白白浪费CPU资源。所以，到底怎么选？得从三个维度来考量。 先说业务类型：你是要吞吐量优先，还是对延迟敏感？ 这是最直接的决策起点。 对于后台任务，比如ETL、日志归档、离线计算这些，选Parallel GC最合适。它用多线程拼命抢时间，目标就是让业务逻辑跑得越久越好。你可以设置-XX:GCTimeRatio=99，这意味着GC总时间不能超过总运行时间的1%。 而对于在线服务，比如API接口、Web应用、交易系统，停顿必须短。CMS曾是主流，但已经废弃了；现在推荐G1（JDK 9+的默认选项），或者更高阶的ZGC/Shenandoah（JDK 11+支持）。它们能把单次STW（Stop-The-World）控制在10ms以内，对用户几乎无感。 还有嵌入式或桌面小工具，内存不超过1GB、单核CPU的场景，Serial GC反而是最轻量、最稳当的选择，没有线程调度开销，STW时间也很短。 接下来，硬件配置这一关也绕不过去。回收器不是孤立工作的，它得和机器的CPU核心数与堆大小咬合在一起。 如果堆小于4GB，且CPU少于4核，用Parallel GC或Serial GC就行了，别强行上G1——它的并发线程和区域管理反而会拖慢小堆的性能。 如果堆在8GB以上，而且多核（≥8核），G1就开始体现价值了。它按Region划分堆，能预测性地控制停顿，还能通过-XX:MaxGCPauseMillis=20设定目标停顿上限。 如果堆≥16GB，对延迟要求又特别严苛，比如金融行情、实时风控这类场景，ZGC是更优解。它采用着色指针加并发标记/移动，停顿基本稳定在10ms内，而且不受堆大小影响。 最后，还得看看实际的GC行为表现。配置再漂亮，不看日志等于盲调。 建议加上-Xlog:gc*:file=gc.log:time,tags（JDK 10+）或-XX:+PrintGCDetails -XX:+PrintGCTimeStamps（旧版），抓取真实的GC频率、停顿时长、晋升速率。 需要重点关注这几个指标：Full GC是否频繁？这说明老年代压力大，可能因为对象过早晋升或内存泄漏。Minor GC间隔是否急剧缩短？说明Eden区太小或对象存活率高。GC后老年代使用率是否持续上涨？那可能意味着CMS失败或G1的混合回收跟不上。 别迷信“默认值”。JDK 8默认Parallel，JDK 11+默认G1，但默认不代表最适配。电商大促前换掉默认回收器，是常见的预案。 不过，有几个典型错误得提一下，线上故障里反复出现过。 比如用Parallel GC跑Web API：吞吐量是上去了，但一次Full GC停顿2秒，用户请求全超时，接口监控直接告警爆炸。 又比如给小内存服务硬配ZGC：ZGC需要额外元数据空间和着色指针支持，在2GB堆下启动反而慢，还吃更多CPU。 还有忽略CMS已被移除的：JDK 14起彻底删除了CMS，JDK 17+不再支持。还在生产环境写-XX:+UseConcMarkSweepGC，启动直接失败。 最后，只调回收器，不调堆结构也是一大坑。比如用G1却把-XX:NewRatio设成2，强制年轻代过大，反而加剧了Mixed GC的压力。