不同垃圾回收器对吞吐量影响显著：parallel gc吞吐最高（95%+），但stw卡顿；g1平衡延迟与吞吐，大堆下易因活跃对象过多导致吞吐下滑；zgc/shenandoah延迟极低但吞吐略低3%–8%；串行gc与cms已淘汰。
不同垃圾回收器对系统吞吐量的影响，核心在于它们如何分配CPU时间给用户代码与GC任务。吞吐量 = 用户代码运行时间 /（用户代码运行时间 + GC时间），所以任何增加GC频率或单次耗时的回收器，都会直接拉低吞吐量。
Parallel GC：吞吐量优先的设计
Parallel GC（又称吞吐量收集器）专为最大化吞吐量而生。它使用多线程并行清理新生代和老年代，但每次执行都是STW（Stop-The-World）。这意味着应用会阶段性卡顿，但总GC时间短、效率高。适合批处理、后台任务等对延迟不敏感、追求单位时间完成更多工作的场景。
- 堆配置建议：适当增大新生代（如 -Xmn2g），减少Minor GC次数；小堆+大新生代常比大堆+小新生代吞吐更高
- 典型表现：在500MB–4GB堆范围内，吞吐量常稳定在95%以上；但若对象晋升过快导致频繁Full GC，吞吐量会断崖式下跌
G1 GC：平衡吞吐与延迟的折中选择
G1通过分区（Region）和可预测停顿模型，在控制暂停时间（如 -XX:MaxGCPauseMillis=200）的同时维持较高吞吐。它用并发标记降低STW压力，但Remembered Set维护、跨区引用处理等带来额外CPU开销。
- 适用场景：响应时间需稳定在200ms内，且堆内存达4GB以上的企业级Web服务
- 关键限制：当活跃对象（live data）占比超过堆的45%–60%，G1会频繁触发混合回收甚至退化为Full GC，吞吐量明显下滑
ZGC & Shenandoah：低延迟代价是吞吐微损
ZGC和Shenandoah主打“毫秒级STW”，靠读屏障、染色指针、并发移动等机制把单次暂停压到10ms内。但这些机制持续占用CPU资源——比如ZGC的并发标记和重定位线程始终运行，会分走2–5%的处理器时间。
- 吞吐代价：在同等负载下，ZGC吞吐量通常比Parallel GC低3%–8%，比调优后的G1低1%–4%
- 适合场景：金融交易、实时风控、高交互UI后端等“宁可慢一点，也不能卡一下”的系统
串行GC与CMS：已淘汰或边缘化的吞吐表现
串行GC单线程执行，小堆（
- 串行GC仅建议用于嵌入式或极轻量工具类程序
- CMS遗留系统应尽快迁移到G1或ZGC，避免因碎片引发吞吐雪崩
