G1将超50%Region大小的对象标记为Humongous，直接分配连续Region（首为Start、余为Continuation），不经过Eden/Survivor；若无足够连续空闲Region则触发Full GC，因Java对象需连续内存布局且G1无跨Region寻址机制。
G1 对巨型对象的处理不是“分配大变量空间”，而是按需占用连续 Region 的物理块。只要一个对象大小超过单个 Region 容量的 50%，G1 就把它标记为 Humongous 对象，并尝试为其分配一组物理上连续的 Region——这些 Region 共同构成该对象的存储空间，而不是“跨 Region 存储一个变量”。
Humongous 对象如何被分配
分配过程不经过 Eden 或 Survivor，而是直接由 G1 在老年代区域中寻找连续空闲 Region。关键点如下：
- 判断依据是对象原始大小（如 byte[]、String 内部 char[]），而非引用本身；
- 若当前堆中没有足够数量的连续空闲 Region来容纳该对象（例如需要 3 个连续 Region，但最大空闲段只有 2 个），G1 会立即触发一次 Full GC 来腾出空间；
- 一旦分配成功，这些 Region 被统一标记为 Humongous Region，其中第一个称为 Humongous Start，后续为 Humongous Continuation；
- 整个 Humongous 区域在回收前不会被拆分或复用，哪怕对象只用了其中一小部分空间。
为什么必须连续？
这是 JVM 对象内存布局的底层约束决定的：
- Java 对象头 + 实际数据必须位于连续地址空间，否则无法通过单一指针访问；
- G1 没有为跨 Region 对象设计额外的间接寻址机制，所以只能靠物理连续性保证语义正确；
- 这也导致 Humongous 分配对堆碎片极其敏感——即使总空闲 Region 数量充足，只要不连续，就可能失败。
常见问题与影响
这类分配行为容易引发两类典型问题：
- 频繁触发 Mixed GC：Humongous 对象直接进入老年代，抬高老年代使用率，加速并发标记周期启动，进而提前触发混合回收；
- 加剧内存浪费与碎片化：比如 Region 大小为 2MB，而对象大小为 2.1MB，就需要占用 2 个连续 Region（4MB），浪费近一半空间；若之后该对象被回收，这 2 个 Region 仍需同时释放才能复用，中间插入其他对象会阻断连续性。
怎么避免踩坑
实际开发中可从三方面控制 Humongous 风险：
- 监控日志：开启
-XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy，留意Humongous Allocation和Full GC (Ergonomics)日志； - 调参前置：若已知应用存在大量大数组（如缓存批量数据），可适当增大
-XX:G1HeapRegionSize（如设为 4MB），减少跨 Region 需求，但注意 Region 过大会降低回收精度； - 代码规避：对可预估大小的缓冲区（如文件读取、序列化输出流），优先使用池化对象（
ByteBuffer.allocateDirect()可控）或分块处理，避免单次申请超限。
