G1 GC没有“Incremental Collection”这一独立回收类型；它通过Young GC与Mixed GC分阶段、按Region切片回收实现增量式停顿控制，而非机制层面的步进式GC。
G1 GC 本身没有叫 “Incremental Collection” 的独立回收类型，这是常见误解；它通过 Young GC + Mixed GC 的分阶段、按 Region 切片回收，实现事实上的增量式停顿控制 —— 不是靠“增量标记/清除”，而是靠“只处理一部分 Region”。
为什么 G1 不提 Incremental Collection 这个词
“Incremental GC” 在早期 JVM（如某些实时 JVM 或部分嵌入式 GC 实现）中指将一次 Full GC 拆成多个极小步长、穿插在应用线程间执行的机制。但 G1 的设计哲学不同：它压根不走 Full GC 路线来回收老年代，而是用并发标记 + 混合回收（Mixed GC）把老年代清理任务“摊薄”到多次 STW 中。
常见错误现象：GC log 里搜不到 Incremental 字样；有人误以为 -XX:+UseG1GC 启用了某种“增量模式”，结果调参失败。
- G1 的并发标记（Concurrent Marking）阶段确实和应用线程并发运行，但它不释放内存，只做标记
- 真正释放内存的动作发生在 STW 的 Young GC 或 Mixed GC 阶段，且每次只选若干 Region 回收
- 所谓“增量”，是效果层面的 —— 停顿时间可控、堆越大越不线性增长，而非机制层面的“步进式 GC”
Mixed GC 是怎么把老年代回收“切片”的
Mixed GC 是 G1 避免 Full GC 的核心机制：它不是一次性扫完整个老年代，而是在并发标记完成后，从老年代中挑选一批“垃圾最多、回收收益最高”的 Region，和当次 Eden/Survivor 一起回收。
关键参数与行为：
-
-XX:MaxGCPauseMillis=200：G1 的目标停顿时间，它会据此动态调整每次 Mixed GC 回收的 Region 数量 —— 时间紧就少收几个，时间宽就多收几个 - 触发条件：并发标记完成 + 老年代占用率超过
-XX:G1MixedGCLiveThresholdPercent（默认 85%） - 每次 Mixed GC 回收的老年代 Region 数量受
-XX:G1OldCSetRegionThresholdPercent限制（默认 10%，即最多回收老年代 10% 的 Region） - 回收完一批后，若剩余垃圾仍多，下一轮 Mixed GC 继续选新 Region，直到老年代“干净度”达标
这相当于把“清理整个老年代”这个大任务，拆成若干个可预测、可中断、可调度的小任务，每个任务都只造成毫秒级 STW。
Young GC 和 Mixed GC 如何协同绕过 Full GC
Full GC 在 G1 中是退化路径（fallback），只在极端情况下发生，比如 Humongous 对象分配失败、或 Mixed GC 持续无法腾出足够空间。正常路径下，Young GC 和 Mixed GC 构成闭环：
- Young GC：只处理 Eden/Survivor Region，对象晋升时若老年代空间不足，会触发并发标记周期
- 并发标记周期完成后，自动转入 Mixed GC 阶段，开始清理部分老年代 Region
- Mixed GC 反复执行，持续降低老年代占用率；只要它跑得够快、选得够准，老年代就不会“堵死”
- Humongous 区域单独管理：超大对象直接进 H 区，G1 会在 Mixed GC 中优先回收整个 H Region（因单个 H Region 就是完整对象）
容易踩的坑：-XX:G1HeapRegionSize 设得过大（如 4MB），会导致中等大小对象也被判为 Humongous，挤占大量连续 Region，反而增加 Mixed GC 压力；设得太小（如 128KB），则 Region 数过多，标记开销上升。
真正决定是否触发 Full GC 的几个硬指标
G1 的 Full GC 不是“慢慢积累出来的”，而是某次分配或回收动作失败的即时结果。以下任一情况发生，就会 fallback 到单线程、全堆扫描的 Full GC：
- 年轻代晋升失败（
Promotion Failed）：Eden 区对象要晋升，但老年代没足够连续空间容纳（尤其被 Humongous 区碎片化后） - 并发标记失败（
Concurrent Mode Failure）：应用分配速度远超并发标记进度，导致标记未完成就不得不启动 Mixed GC，最终因空间不足退化 - 巨型对象分配失败（
Humongous Allocation）：申请一个超大对象，但找不到足够连续的空闲 Region（哪怕总空闲内存充足） - 元空间（Metaspace）或直接内存（Direct Buffer）耗尽，也会间接诱发 Full GC
这些场景的共性是：G1 的 Region 管理模型在那一刻“失灵”了——要么空间不连续，要么标记跟不上分配。此时它放弃所有优化逻辑，回归最保守的全堆扫描。
复杂点在于：这些失败往往不是孤立事件。比如一次 Promotion Failed 后触发的 Full GC，会重置整个堆的 Region 状态，导致后续并发标记周期重新开始，形成恶性循环。所以监控 GC log 中的 Full GC、Promotion Failed、Concurrent Mode Failure 出现频率，比单纯调 MaxGCPauseMillis 更关键。
