G1触发Full GC会退化为Serial Old单线程回收，导致秒级STW卡顿，主要因并发模式失败、疏散失败和巨型对象分配失败；需通过调优G1ReservePercent、InitiatingHeapOccupancyPercent等参数主动预防。
G1收集器在设计上尽量避免Full GC，但一旦触发，会退化为Serial Old单线程收集器执行整堆回收，导致秒级STW（Stop-The-World），应用出现明显卡顿甚至假死。这不是G1的“正常流程”，而是其并发机制失效后的兜底行为，需重点防范。
G1触发Full GC的三大典型场景
这些情况都会绕过G1的混合回收逻辑，强制进入全局停顿式清理：
- 并发模式失败（Concurrent Mode Failure）：G1启动并发标记周期后，老年代在Mixed GC开始前就被填满，标记被迫中止，直接触发Full GC。常见于大促流量突增、对象晋升速率远超预期时。
- 疏散失败（Evacuation Failure）：GC过程中，Survivor或老年代目标区域（to-space）没有足够连续空间容纳存活对象，日志中可见to-space exhausted。本质是预留内存不足或区域碎片化严重。
- 巨型对象分配失败（Humongous Allocation Failure）：对象大小 ≥ ½ Region Size，被划为“巨型对象”（Humongous Object），需连续多个Region存放。若找不到足够连续空闲Region，G1会立即触发Full GC尝试腾出大块空间。
Serial Old退化带来的实际风险
退化后使用Serial Old，意味着：
- 单线程扫描+标记+整理整个堆，无并行能力，暂停时间与堆大小强相关（例如32GB堆可能停顿5–12秒）；
- 无法利用多核CPU，资源利用率归零，期间所有请求积压或超时；
- 退化本身是不可逆的——本次Full GC完成后，下次GC仍可能继续退化，形成恶性循环；
- 日志中明确体现为Using Serial Old或GC pause (full)，而非G1 Evacuation Pause。
关键预防配置建议
不是调大堆就万事大吉，要针对性加固G1的并发稳定性：
- 预留缓冲：设置-XX:G1ReservePercent=15（默认10%），为疏散失败预留更多空Region；
- 提前干预：降低-XX:InitiatingHeapOccupancyPercent=35（默认45%），让并发标记更早启动；
- 加速标记：增加并发线程数-XX:ConcGCThreads=4（建议设为ParallelGCThreads的1/4）；
- 控制巨型对象：适当调高-XX:G1HeapRegionSize=4M（默认按堆大小动态计算），减少Humongous对象数量；
- 监控兜底：通过-Xlog:gc*,gc+heap=debug持续观察to-space overflow和concurrent-cycle-aborted等关键事件。
退化不是G1的缺陷，而是对资源预估不足或负载突变的警示信号。把并发标记节奏、内存预留和巨型对象管理三个环节控住，Serial Old退化就能从“偶发事故”变成“可规避状态”。
