你问“收集器怎么选”其实是在问两件事吞吐量优先还是延迟优先你的堆有多大、停顿目标RT有多苛刻这篇先把主线讲清楚CMS 为什么曾经流行G1 为什么成为很多项目的默认选择ZGC 解决的是什么问题1. 你需要先会分清吞吐量 vs 延迟吞吐量优先单位时间处理更多请求允许更长停顿延迟优先单次停顿必须短且可控RT 稳定大多数在线服务更关心延迟稳定性尤其是 P99/P9992. CMS低停顿的老年代并发收集器历史重点CMS 的核心特点老年代并发标记/清理尽量减少 STW你只要记住它的经典问题碎片问题标记清除容易产生碎片并发失败回收赶不上分配可能退化成 Full GC对 CPU 资源更敏感工程上 CMS 常见的“感受”平时停顿短但偶尔会出现一次很长的 Full GC3. G1Region 化 可预测停顿G1 的核心思路把堆切成多个 Region每次回收按“收益”挑选 Region目标是满足你设定的停顿时间目标你只要先记住三个关键词RegionRemembered Set跨 Region 引用记录按收益回收收益高的先回4. ZGC超低停顿的并发收集器ZGC 的定位很清晰更大的堆更低的停顿你可以把它理解成把更多工作并发化尽量把 STW 的时间压缩到极短但你要注意选择 ZGC 往往意味着你对延迟极其敏感同时要考虑 JDK 版本与生产环境验证5. 面试/实战都能用的选择逻辑你可以按这个顺序回答“选哪个”堆大小大堆更倾向选择对大堆友好的收集器延迟目标是否要求可预测停顿CPU 预算并发收集会占用更多 CPU业务特性对象生命周期、峰值流量一个常见的工程表述方式大部分在线服务优先考虑G1对极低停顿/超大堆评估ZGCCMS更多是“理解历史与排老系统”6. 总结CMS并发清理、碎片与并发失败是典型问题G1Region 化 可预测停顿很多项目的主力选择ZGC更低停顿、更大堆的场景选型永远回到延迟目标 堆大小 资源预算