为什么 G1 收集器的 Full GC 是单线程串行的？探讨其作为“兜底方案”在现代架构下的角色。

关于为什么G1 Full GC是单线程的，很多人第一反应是“设计缺陷”。但恰恰相反，这其实是JVM在权衡之下做出的主动选择。当并发标记失败、混合回收跟不上分配速率，或者特大对象（Humongous Object）触发连续内存压力时，G1会果断放弃所有并行和并发逻辑，直接调用SerialOld收集器来接管整个堆。从JDK 8u40一直到JDK 17，这个行为始终一致，被明确写死为兜底路径，从未被标记为bug。

关键点在于，G1的并发标记和混合回收严重依赖Region级别的元数据——比如Remembered Set（RSet）、SATB缓冲区。一旦这些结构出现严重不一致（类似于CMS失败时的“并发模式失败”），重建成本会高得吓人，远超过直接Stop-The-World并用最简单可靠的单线程方式收尾。这个时候如果强行上多线程，反而可能因为竞争导致更长的停顿，甚至把状态弄得一团糟。

G1 Full GC触发的典型场景

G1 Full GC不是“偶尔发生”的小概率事件，它是系统出现结构性压力的明确信号。

最常见的是to-space exhausted——年轻代晋升时，老年代拿不出足够的连续空间来容纳存活对象。这种情况在大量短期大对象频繁分配、又快速死亡时尤其常见，因为G1还没来得及回收那些占用的连续H-Region。

另一个典型是并发标记失败（Concurrent Mark Abort）：初始标记完成后，应用线程分配速度过快，导致标记线程追不上，最终只能放弃并发流程，降级为Full GC。

还有Remembered Set更新溢出的情况：某个Region的RSet缓冲区持续满载，来不及处理，G1判断跨Region的引用关系已经不可信，拒绝继续混合回收。

最后别忘了元空间（Metaspace）耗尽后的连带效应。虽然元空间本身不由G1管理，但JVM在抛出ja va.lang.OutOfMemoryError: Metaspace之前，会强制触发一次Full GC尝试回收类加载器——这时候走的也是单线程路径。

为什么不能把G1 Full GC改成并行

这不是JVM实现偷懒，而是在工程上不可行。

G1的并行能力主要集中在Young GC和Mixed GC阶段，这些阶段复用Parallel Sca venge的工作线程池和任务分片机制。而Full GC路径直接跳过了所有G1特有的结构，调用的是共享的SerialOld代码路径。这条路径从JDK 1.3起就从未支持并行化改造——它不维护RSet、不区分Region、不跟踪TAMS指针，只做最朴素的标记-整理。相当于让一支习惯了现代化作战的部队突然使用冷兵器，设计初衷就不是为了并行。

即便强行注入并行逻辑，也会面临严重的问题：老年代Region之间的引用关系在Full GC之前已经失效，无法安全地划分任务。更何况，单次Full GC本身就是异常态，投入资源去优化它的收益，远低于花精力去预防它发生。

真正实现全堆并发回收的，是JDK 12+引入的ZGC和JDK 11+的Shenandoah，但它们是全新设计的垃圾回收器，与G1没有继承关系。

在现代架构下，G1 Full GC的真实角色

G1 Full GC已经不是“备用回收方案”，而是系统健康度的硬性红灯。

在容器化环境（比如Kubernetes）中，一次G1 Full GC常常伴随着2到10秒的STW停顿。这段时间足以触发服务探针失败、连接池超时、熔断器开启。如果GC日志里反复出现Full GC (Ergonomics)或Full GC (Metadata GC Threshold)，说明应用存在内存泄漏、缓存未设置上限，或者-XX:MaxGCPauseMillis设得过于激进——比如设成50ms，但实际堆内对象图的深度远超预期。

真正需要做的不是调大堆内存或者加线程数，而是立刻检查几件事：jstat -gc 中FGC列是否在递增；jmap -histo 是否存在异常增长的类实例；GC日志里是否有连续的to-space exhausted提示。

值得留意的是，JDK 17之后默认启用了ZGC（Linux/x64），G1 Full GC的“兜底”地位正在被逐步取代。但在金融、电信等仍然锚定JDK 8/11的场景中，它依然是最后一道必须读懂的防线。