G1将超过Region容量50%的对象标记为Humongous并强制分配连续Region；识别依据是对象原始数据大小，分配跳过年轻代直接在老年代寻找连续空闲Region，首个为HS、后续为HC；因需物理连续性，碎片易致Full GC；回收仅限Mixed GC且要求并发标记完成，JDK8u40后支持单Region回收但受限于对象可达性；调优需结合日志分析典型大小、预留空间及代码层优化。

G1 不是“跨 Region 存储一个对象”，而是为超大对象分配一组物理连续的 Region，并整体标记为 Humongous —— 这是内存布局硬约束下的应对方案，不是灵活分片存储。

Humongous 对象怎么被识别和分配

判断依据是对象原始数据大小，比如 byte[] 的 length、String 内部 char[] 的容量，而不是引用变量本身。只要该大小超过当前 Region 容量的一半（> RegionSize × 0.5），G1 就将其标记为 Humongous 对象。

• Region 大小由堆总容量自动推导（≈堆大小 / 2048），范围在 1MB～32MB 之间，且必须是 2 的整数次幂；可通过 -XX:G1HeapRegionSize 手动指定
• 分配不经过 Eden 或 Survivor，直接在老年代可用区域中寻找足够数量的物理连续空闲 Region
• 首个 Region 标记为 Humongous Start，后续连续 Region 标记为 Humongous Continuation，整组 Region 统一视为一个逻辑单元

为什么必须连续？这不是设计选择，而是 JVM 底层限制

Java 对象需要对象头 + 实际数据位于同一段连续地址空间，JVM 仅通过单一指针访问整个对象。G1 没有实现跨 Region 的间接寻址机制（比如页表或跳转表），因此无法支持“分散存储、统一视图”的方式。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 哪怕堆中总空闲 Region 数量充足，只要没有足够长的连续段，分配就会失败
• 此时 G1 会立即触发 Full GC 尝试腾出连续空间；若仍失败，则抛出 OutOfMemoryError
• 这种对碎片极度敏感的特性，是生产环境突发 Full GC 的常见根源

Humongous 对象如何被回收

它不参与 Young GC，也不在 Initial Mark 或 Concurrent Mark 阶段被单独处理，回收时机非常受限：

立即学习“Java免费学习笔记（深入）”；

• 仅在 Mixed GC 阶段可能被纳入回收集合，前提是并发标记已完成，且 G1 判定其所在的老年代 Region 区域整体具备回收价值
• JDK 8u40 起支持单 Region 级回收（即只释放某个 Humongous Continuation Region），但前提是该 Region 内所有对象都已不可达，依赖 SATB 标记精度
• 若对象长期被强引用持有，或连续空闲段始终不足，就容易退化为 Full GC

日常调优与监控要点

不能只看“有没有大对象”，关键要确认它是否正在拖慢 GC 效率：

• 开启详细日志：-Xlog:gc*,gc+humongous=debug，观察 Humongous 分配失败或频繁 Mixed GC 记录
• 用 jcmd <pid> VM.native_memory summary 或 GC.class_stats 定位大对象来源（如百万行 JSON 解析生成的 List）
• 常用参数：适当增大 RegionSize（如 -XX:G1HeapRegionSize=16M）可减少 Humongous Region 数量；提前触发 Mixed GC（-XX:InitiatingHeapOccupancyPercent=40）；预留防碎片内存（-XX:G1ReservePercent=10）