Mixed GC 无法清理 Humongous Region，因其专用于存放超大对象且不参与复制式回收，仅当完全为空时才释放；它默认被排除在回收集外，加剧老年代外部碎片。

Mixed GC 本身不解决老年代碎片化，反而可能因 Humongous 对象加剧外部碎片。G1 的设计目标是控制停顿时间，不是彻底消除碎片；当老年代 Region 中大量存在 Humongous 对象（≥ Region 大小一半），且这些对象长期存活、分布零散时，Mixed GC 无法回收它们，还会因预留空闲 Region 导致可用空间进一步割裂。

为什么 Mixed GC 无法清理 Humongous Region

Humongous Region 是 G1 中特殊的一类 Region，专用于存放超大对象（如大数组、缓存块）。它不参与常规的复制式回收流程：

• Humongous 对象一旦分配，就独占一个或多个连续 Region，且不会被移动（G1 不对它们做复制或整理）
• Mixed GC 的回收集（Collection Set）默认排除 Humongous Region，除非该 Region 完全为空（此时才释放）
• 日志中出现 Humongous allocation 或 humongous object allocated 表明已有碎片风险起点

如何让 Mixed GC 更早、更有效地介入老年代回收

关键不是“强制 Mixed GC 清理碎片”，而是通过参数引导它提前回收高垃圾占比的老年代 Region，减少后续晋升压力和 Humongous 分配需求：

• 降低触发阈值：-XX:InitiatingHeapOccupancyPercent=35（默认 45%），让并发标记周期更早启动，为 Mixed GC 预留更多可选 Region
• 提高单次回收强度：-XX:G1MixedGCLiveThresholdPercent=70（默认 65%），只回收垃圾占比更高的 Region，提升单位时间收益
• 限制回收节奏但避免过少：-XX:G1MixedGCCountTarget=12（默认 8），配合 -XX:G1HeapWastePercent=5（默认 10%），防止因“回收太少”而反复触发低效 Mixed GC

必须同步做的三件事：否则调参无效

单纯调优 Mixed GC 参数治标不治本。以下操作直接影响 Humongous 对象生成与 Region 连续性：

• 检查并收缩大对象：用 jcmd VM.native_memory summary 或 jcmd GC.class_histogram 找出高频 byte[]、char[]、HashMap$Node[] 实例，确认是否来自缓存、序列化或日志拼接
• 调整 Region 大小：-XX:G1HeapRegionSize=2M（而非默认自动计算值），避免小对象被误判为 Humongous；注意该值必须是 2 的幂，且 1M~32M 之间
• 预留防碎片缓冲：-XX:G1ReservePercent=15（默认 10%），为突发的大对象分配保留连续空闲 Region，减少跨 Region 分配导致的割裂

真正棘手的是那些生命周期长、尺寸固定的大对象——它们不会被 Mixed GC 触及，也不会被压缩，只能靠业务层控制创建节奏或改用池化结构。G1 的“无碎片”承诺，只在对象能被复制的前提下成立；一旦落入 Humongous 范畴，就进入了“只分配、不移动”的灰色地带。