mixed gc 与 full gc 本质不同：mixed gc 仅回收部分老年代和全部年轻代 region，而 full gc 需 stw 扫描整堆并执行标记-清除-压缩。
OpenJDK G1 的 Mixed GC 和 Full GC 本质不同
Mixed GC 不是 Full GC，根本原因在于它不扫描、不处理整个堆，只回收部分老年代 Region + 全部年轻代 Region。Full GC 则必须停顿所有应用线程（STW），遍历整堆（包括所有 Old、Humongous、元空间等），执行标记-清除-压缩（或类似单线程整理逻辑）。两者触发条件、作用范围、算法强度、停顿时间量级都完全不同。
Mixed GC 触发依赖 InitiatingHeapOccupancyPercent 计算逻辑
这个参数的值不是「老年代使用率」，而是「老年代已用内存 / 整个堆大小」。如果配置了过高的 -XX:G1NewSizePercent（比如 40%），导致新生代始终占堆 40%，那老年代最多只能占 60%——此时即使设 -XX:InitiatingHeapOccupancyPercent=70，永远达不到触发阈值，Mixed GC 就不会启动，老年代持续堆积，最终只能靠 Full GC 救火。
- 常见错误配置：
-XX:G1NewSizePercent=40 -XX:InitiatingHeapOccupancyPercent=70 - 正确思路：确保
InitiatingHeapOccupancyPercent值低于100 - G1NewSizePercent的理论上限 - JDK 9+ 已修复该逻辑缺陷；JDK 8u202 之前版本必须手动规避
Mixed GC 回收失败会直接升级为 Full GC
当 Mixed GC 执行过程中发现没有足够空闲 Region 来搬运存活对象（即复制算法所需目标空间不足），就会立即中止当前 Mixed GC，并触发一次 Full GC。这个过程不是“混合变完整”，而是“混合失败后兜底”。所以看到频繁 Full GC，第一反应不该是调大堆，而应检查日志里是否反复出现 to-space exhausted 或 Evacuation Failure。
- 典型错误日志：
G1 Evacuation Failure、to-space overflow - 直接诱因：堆碎片化严重、Humongous 对象过多、Region 大小设置不合理（
-XX:G1HeapRegionSize） - 关键区别：Mixed GC 是预测性、增量式回收；Full GC 是被动、强制、全局接管
Full GC 在 JDK 10 后才支持并行化
在 JDK 9 以前，G1 的 Full GC 是单线程执行的 mark-sweep-compact，哪怕机器有 64 核，也只用 1 个线程干活，停顿动辄数秒。JDK 10 开始默认启用并行 Full GC，可通过 -XX:ParallelGCThreads 控制并发线程数。但 Mixed GC 从 JDK 7u4 之后就一直是多线程并行的——这是它能控制停顿时间的核心能力之一。
也就是说，你观察到的「Mixed GC 停顿 50ms，Full GC 停顿 3s」，不只是范围差异，更是算法实现层级的代际差距。别把后者当成前者的“加强版”，它们解决的是完全不同的问题域。
