g1中humongous region采用强制连续region分配机制，对象超region容量50%即被标记为humongous，跳过eden直接分配在老年代连续region中，仅在mixed gc或full gc中回收，不参与young gc。
G1中Humongous Region不是简单地把大对象“塞进老年代”，而是采用一套有约束的连续分配机制：只要对象大小超过当前Region容量的50%，就强制为其分配一组物理连续的Region，并标记为Humongous类型。这种设计避免了跨Region引用带来的Remembered Set开销，但也带来碎片与回收延迟风险——尤其当这类对象频繁创建又短命时，极易诱发Mixed GC压力甚至退化为Full GC。
Humongous对象如何被分配和回收
Humongous对象跳过Eden区，直接进入老年代区域中的连续Humongous Region。它不参与Young GC，只可能在以下两种情况下被回收：
- Mixed GC阶段：当并发标记完成、G1识别出足够多可回收的老年代Region（含Humongous Region）时，会将其纳入回收集合
- Full GC：若Humongous Region无法被及时回收（如被长期持有引用），或连续空间不足导致分配失败，就会触发Full GC
注意：JDK 8u40之后，G1支持对单个Humongous Region进行独立回收（不再必须整组回收），但前提是该Region内所有对象都已不可达——这依赖准确的SATB标记，实际中仍较难达成。
识别大对象是否正在拖慢GC
不能只看“有没有大对象”，关键要看它们是否构成GC瓶颈。可通过以下方式快速定位：
- 开启GC日志：添加-Xlog:gc*,gc+humongous=debug:file=gc.log:time,tags,level（JDK 10+）或旧版-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
- 关注日志中的humongous allocation、humongous region freed、humongous total等关键词
- 观察Mixed GC频率是否异常升高，以及每次Mixed GC中Humongous Region的回收占比
- 用jstat -gc
查看H（Humongous allocated）和HU（Humongous used）指标变化趋势
针对性调优策略
核心思路是：减少Humongous分配次数 + 提升其回收效率 + 避免因它引发连锁反应。
- 调整Region大小：默认Region由堆大小自动计算（≈堆/2048），但易导致临界值敏感。例如堆8GB → Region≈4MB，那么≥2MB对象即为Humongous。可手动设为-XX:G1HeapRegionSize=1M，使2MB对象需占2个Region而非1个，降低“刚好卡线”的误判概率
- 控制大对象生命周期：避免临时缓存、批量读取时一次性加载数百万行数据到ArrayList。改用流式处理、分页加载，或使用堆外内存（如ByteBuffer.allocateDirect）承载真正的大块数据
- 避免Humongous Region碎片化：连续Region一旦被占用，中间若有部分对象存活，整个Region都无法释放。可配合-XX:G1HeapWastePercent=5（默认5%）放宽G1对“可回收价值”的判断，促使更早启动Mixed GC
- 监控IHOP阈值：初始堆占用率（-XX:InitiatingOccupancyPercent）默认45%，若Humongous对象集中爆发，可能在老年代还没填满时就因连续空间告急而失败。适当调低至35~40，让并发标记提前介入
一个典型误配案例
某实时风控服务堆设为16GB，默认Region≈8MB，业务中一个固定大小的byte[5MB]缓存对象每秒创建数十次。虽然单个仅5MB（＜8MB），但＞4MB（50%阈值），被判定为Humongous，每秒占用多个连续Region。几天后老年代碎片严重，Mixed GC无法凑出足够连续空间，最终每小时触发一次Full GC，停顿超10秒。解决方式：将Region调为2MB，该对象变为普通对象走Young GC；同时改用对象池复用byte数组。
