G1收集器将大小超过RegionSize一半的对象标记为Humongous并直接分配到连续老年代Region，分配失败会触发Full GC或OOM；仅Mixed GC可回收，需并发标记完成且Region内对象全部不可达；调优需结合日志监控与参数调整。

G1 收集器对 Humongous 对象的管理不是简单地“扔进老年代”，而是一套有约束、有代价的连续分配机制。它直接影响 GC 行为、停顿时间，甚至可能触发 Full GC。

Humongous 对象怎么被识别？

判断依据是对象原始数据大小（如 byte[] 长度、String 内部 char[] 容量），而非引用本身：

• 只要对象大小 > RegionSize × 0.5，就标记为 Humongous；例如 Region 为 4MB，≥2MB 的对象即触发
• RegionSize 默认由堆总容量自动计算（≈堆大小 / 2048），范围在 1MB～32MB 之间，且为 2 的整数次幂
• 可通过 -XX:G1HeapRegionSize 手动调整，但不宜设得过小（如 1MB 导致 Region 数量爆炸、RSet 开销剧增）或过大（如 32MB 易造成空间浪费和回收滞后）

Humongous 对象如何分配？

跳过 Eden/Survivor，直接在老年代区域中寻找物理连续的空闲 Region：

• 首个 Region 标记为 Humongous Start，后续连续 Region 标记为 Humongous Continuation
• 若找不到足够数量的连续空闲 Region（比如需 3 个，但最大连续段只有 2 个），G1 会立即触发 Full GC 腾空间——这是生产环境 Full GC 突增的常见原因
• 分配失败也可能直接 OOM，尤其在大促或批量解析场景（如一次读取百万行 JSON 转 List）下高频创建又快速丢弃时

Humongous 对象何时被回收？

它不参与 Young GC，回收时机非常受限：

• 仅在 Mixed GC 阶段被纳入回收集合，前提是并发标记已完成，且 G1 判定该 Humongous Region 所在的老年代区域整体具备回收价值
• JDK 8u40 起支持单 Region 级回收（不再强求整组释放），但前提是该 Region 内所有对象都已不可达；实际效果依赖 SATB 标记精度
• 长期被持有引用、或连续空间持续紧张时，极易退化为 Full GC

怎么监控和调优？

不能只看“有没有大对象”，要确认它是否构成 GC 瓶颈：

• 开启详细 GC 日志：-Xlog:gc*,gc+humongous=debug:file=gc.log:time
• 查看 Humongous 分配记录：-Xlog:gc+heap=debug
• 统计对象分布定位来源：jcmd <pid> VM.native_memory summary 或 GC.class_stats
• 常用调优参数：-XX:G1HeapRegionSize=16M（减小 Humongous Region 数量）、-XX:InitiatingHeapOccupancyPercent=40（提前触发 Mixed GC）、-XX:G1ReservePercent=10（预留防碎片内存）