G1垃圾回收器在合理配置和匹配负载下可稳定甚至提升吞吐量，其通过分Region回收、混合收集及自适应调优平衡停顿与效率，但大对象堆积、写屏障开销或STW过长可能导致吞吐下降。
G1垃圾回收器对系统吞吐量的影响不是单向增或减，而是通过动态权衡停顿时间与回收效率，在多数服务端场景中实现吞吐量的稳定甚至提升——前提是配置合理、负载匹配。
吞吐量的本质与G1的设计取向
吞吐量 = 用户代码执行时间 /（用户代码执行时间 + GC时间）。G1不追求GC绝对次数最少，而是把每次GC的耗时控制在可预期范围内，避免出现长时间Full GC拖垮整体运行节奏。它用“分Region回收+混合收集”代替传统全堆扫描，让GC开销更平滑、更可预测。
- 传统Parallel GC可能在大堆下触发频繁且耗时的Full GC，导致吞吐量骤降；G1通过优先回收垃圾最多的Region，减少无效扫描，降低单位时间GC总耗时。
- G1默认启用自适应调优（-XX:+UseAdaptiveSizePolicy），会根据应用对象生命周期自动调整新生代占比，避免因年轻代过小引发高频Minor GC，或因老年代过小诱发Mixed GC失控。
- 当堆内存较大（如4GB以上）、对象存活率中等（20%~70%）、且存在周期性业务高峰时，G1通常比CMS或Parallel Old更能维持吞吐量稳定性。
影响吞吐量的关键配置项
G1的吞吐量表现高度依赖参数设置，尤其以下三项直接影响GC频率与单次耗时的平衡：
- -XX:MaxGCPauseMillis=N：设定目标停顿上限（如200ms）。设得太低（如50ms）会导致G1频繁启动、每次只回收少量Region，GC总次数上升，反而拉低吞吐量；设得过高（如500ms）则可能错过及时清理，堆积压力引发更重回收。
- -Xmx与-Xms保持一致：G1依赖固定堆大小做Region划分和预测模型。若堆动态伸缩，Region数量变动会干扰回收收益估算，导致吞吐量波动。
- -XX:G1HeapRegionSize：Region大小影响大对象分配与Humongous区管理。默认值（2MB左右）适合多数场景；若应用大量分配接近1MB的对象，适当调大Region可减少跨Region引用开销和碎片化压力，间接提升吞吐。
典型吞吐量受损场景及原因
并非所有系统启用G1后吞吐量都会提升。以下情况容易造成实际吞吐下降：
- 堆中长期存在大量生命周期长的大对象（如缓存池、静态数据结构），导致老年代Region难以被有效回收，Mixed GC持续高频率运行，CPU时间被大量消耗在RSet更新和跨Region扫描上。
- 写屏障开销显著：G1依赖写屏障维护记忆集（RSet），在高并发写密集型场景（如高频更新共享状态的微服务），这部分额外指令会抬升CPU使用率，间接压缩用户线程执行时间。
- 初始标记与最终标记阶段仍需Stop-The-World（STW），若应用GC Roots极多（如Spring Bean容器庞大、反射调用泛滥），这两个STW阶段可能超出预期，形成“短而频”的卡顿，累积效应削弱吞吐。
评估建议：不止看GC日志中的pause time
判断G1是否真正提升了吞吐量，不能只盯着单次GC停顿毫秒数，而要结合业务指标综合观察：
- 对比启用G1前后，单位时间内成功处理的请求量（TPS/QPS）变化趋势，尤其关注高峰期是否出现吞吐拐点或平台期延长。
- 检查JVM整体GC时间占比（可通过
-XX:+PrintGCDetails -Xloggc:gc.log统计），理想状态下应稳定在5%以内；若超过8%，说明GC已成瓶颈，需调参或排查内存泄漏。 - 观察老年代占用增长率：G1虽能延迟Full GC，但若老年代每小时增长超15%，即使没触发Full GC，也预示着Mixed GC压力持续攀升，后续吞吐可能不可持续。
