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）默认排除
HumongousRegion，除非该 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 <pid> VM.native_memory summary</pid>或jcmd <pid> GC.class_histogram</pid>找出高频byte[]、char[]、HashMap$Node[]实例，确认是否来自缓存、序列化或日志拼接 - 调整 Region 大小：
-XX:G1HeapRegionSize=2M（而非默认自动计算值），避免小对象被误判为 Humongous；注意该值必须是 2 的幂，且 1M~32M 之间 - 预留防碎片缓冲：
-XX:G1ReservePercent=15（默认 10%），为突发的大对象分配保留连续空闲 Region，减少跨 Region 分配导致的割裂
真正棘手的是那些生命周期长、尺寸固定的大对象——它们不会被 Mixed GC 触及，也不会被压缩，只能靠业务层控制创建节奏或改用池化结构。G1 的“无碎片”承诺，只在对象能被复制的前提下成立；一旦落入 Humongous 范畴，就进入了“只分配、不移动”的灰色地带。
