Mixed GC 本身不解决老年代碎片，但通过其触发逻辑、回收范围控制与并发标记质量间接管控外部碎片；它不处理 Humongous Region，后者是主要碎片来源，需靠调优 IHOP、G1HeapWastePercent 及显式设置 G1HeapRegionSize 来缓解。
Mixed GC 本身不解决老年代碎片，但它是 G1 控制碎片的关键执行环节。G1 不会产生传统 CMS 那种内部碎片，但会因 Humongous Region 分散和 Mixed GC 回收不充分，导致外部碎片（空闲 Region 不连续），进而影响大对象分配。真正起作用的不是 Mixed GC 的“执行”，而是它背后的触发逻辑、回收范围控制与并发标记质量。
为什么 Mixed GC 容易被误认为“能自动整理老年代”
常见误解是：既然 Mixed GC 会回收部分老年代 Region，又用复制算法移动对象，那碎片就自然没了。但实际中，Mixed GC 只在满足条件时才启动，且每次只挑一部分老年代 Region —— 如果选中的 Region 存活率高、可释放空间少，或者根本没覆盖到碎片最严重的区域，那“整理”就形同虚设。
- 触发依赖
InitiatingHeapOccupancyPercent（默认 45%），等老年代快满了才动，此时碎片可能已固化 - 每次回收的老年代 Region 数量受
G1MixedGCCountTarget（默认 8 次）和G1HeapWastePercent（默认 5%）联合限制，容易提前终止 - 并发标记阶段若被频繁 Young GC 中断，可能导致老年代存活对象统计不准，CSet 选区失衡
怎么让 Mixed GC 真正覆盖高碎片风险区域
关键不在调大停顿时间，而在让 G1 更早、更准、更持续地识别并清理“低价值+高碎片”的老年代 Region。
- 把
InitiatingHeapOccupancyPercent从默认 45 改为 35～40，尤其在有稳定大对象分配节奏的场景（如定时批量导入），避免等到堆快满才启动标记周期 - 降低
G1HeapWastePercent到 2～3%，迫使 Mixed GC 多跑几轮，而不是“刚清出一点垃圾就收手” - 配合
-Xlog:gc+ergo=debug观察日志里Concurrent Mark阶段是否频繁被 Young GC 打断；若中断多，可适当增大MaxGCPauseMillis（比如从 200ms→250ms），给并发标记留出完成窗口 - 避免人为干预 CSet 构成（G1 不开放手动指定 Region），但可通过
G1OldCSetRegionThreshold（JDK 16+）限制单次 Mixed GC 最多选多少老年代 Region，防止单次压力过大影响响应
Humongous Region 是碎片化主因，Mixed GC 对它基本无效
Mixed GC 不回收 Humongous Region —— 它们由单独的 Full GC 或下次并发标记周期末尾的 Cleanup 阶段处理。这意味着：只要应用持续分配 > Region size × 0.5 的对象（比如 2MB 对象配默认 4MB Region），Humongous Region 就会不断新增、长期驻留、彼此隔离，直接制造外部碎片。
- 查当前 Region 大小：
jstat -gc <pid>看NGCMN/NGCMX推算，或用-Xlog:gc+heap=debug启动时看日志首行 - 若业务确定存在固定大对象（如缓存块、报表数据），优先用
-XX:G1HeapRegionSize=2M或4M显式设定，避免默认值下大量对象刚好卡在 50% 边界反复触发 Humongous 分配 - 监控
Humongous Allocation日志频率，超过每分钟几次就要警惕；此时Mixed GC再勤快也救不了 —— 必须改代码或拆分对象
真正难处理的不是 Mixed GC 跑不跑，而是它跑的时候有没有“看到”该清的碎片。并发标记的完整性、IHOP 阈值是否匹配业务内存增长斜率、Humongous 对象是否可控——这三者缺一，碎片风险就始终悬着。日志里反复出现 Humongous region allocation failed 或 to-space exhausted，说明 Mixed GC 已经在补漏，但漏太大，得从源头堵。
