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 阶段被单独处理，回收时机非常受限：
- 仅在 Mixed GC 阶段可能被纳入回收集合，前提是并发标记已完成，且 G1 判定其所在的老年代 Region 区域整体具备回收价值
- JDK 8u40 起支持单 Region 级回收（即只释放某个 Humongous Continuation Region），但前提是该 Region 内所有对象都已不可达，依赖 SATB 标记精度
- 若对象长期被强引用持有，或连续空闲段始终不足，就容易退化为 Full GC
日常调优与监控要点
不能只看“有没有大对象”，关键要确认它是否正在拖慢 GC 效率：
- 开启详细日志：-Xlog:gc*,gc+humongous=debug，观察 Humongous 分配失败或频繁 Mixed GC 记录
- 用 jcmd
VM.native_memory summary 或 GC.class_stats 定位大对象来源（如百万行 JSON 解析生成的 List） - 常用参数：适当增大 RegionSize（如 -XX:G1HeapRegionSize=16M）可减少 Humongous Region 数量；提前触发 Mixed GC（-XX:InitiatingHeapOccupancyPercent=40）；预留防碎片内存（-XX:G1ReservePercent=10）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
