G1中巨型对象必须分配在连续Region中，因其需满足JVM对象连续内存布局要求且无跨Region寻址机制；若无足够连续空闲Region则触发Full GC。
巨型对象（Humongous Object）在G1垃圾回收器中不走常规分配路径，本质是内存寻址约束下的工程妥协——它绕开了“指针直接寻址+偏移量计算”的通用方式，转而依赖连续物理页映射与区域预留机制。
为什么巨型对象不能像普通对象那样分配
Java对象在堆中通过对象头+实例数据+对齐填充构成，其引用本质是一个指向起始地址的指针。JVM通过基址寄存器（如R12）加偏移量快速定位字段，前提是对象整体落在一个可寻址的连续内存块内。但当对象大小超过Region容量的一半（例如Region为2MB时，对象＞1MB），它就无法被完整装入单个Region——而G1要求每个Region最多容纳一个巨型对象，且该对象必须独占连续Region序列。
此时若强行按普通方式分配，会出现两种寻址失效风险：
- 跨Region指针无法用单一基址+偏移表示：对象横跨多个非相邻Region，破坏了“一个引用对应一个线性地址空间”的基本假设；
- GC移动时无法原子更新所有引用：复制巨型对象需同步更新所有指向它的引用，而这些引用可能散落在堆各处甚至栈/元空间，成本远超收益。
特批分配如何规避寻址困境
G1为巨型对象开辟专用的Humongous Region（H区），并强制要求它们占据连续的Region物理序列。这种设计把寻址问题转化为内存管理问题：
- 每个H区首地址仍符合JVM虚拟地址空间布局，对象起始地址可用标准指针表示；
- 对象内部字段访问仍靠基址+偏移，只要整个对象落在连续虚拟页内（由OS保证连续Region映射到连续虚拟页），CPU寻址逻辑完全不变；
- GC标记阶段将整个H区视为不可分割单元，避免逐字段扫描；回收时整块释放，不触发复制或整理，也就无需更新外部引用。
连续Region需求带来的副作用
连续Region不是天然存在的，而是需要运行时拼凑。当堆中没有足够长度的空闲Region链时，G1只能触发Full GC来压缩腾挪——这不是算法缺陷，而是内存寻址硬约束倒逼出的保底策略：
- 普通对象分配只需找到任意空闲Region，时间复杂度O(1)；
- 巨型对象分配需查找最长空闲Region段，时间复杂度接近O(n)，且失败即退化；
- 一旦发生并发分配竞争，还可能因写屏障记录旧引用而加剧RSet开销，进一步拖慢标记过程。
实际开发中的关键影响点
开发者感知不到寻址细节，但以下行为直接受其制约：
- 避免手动构造超大数组（如
new byte[2*1024*1024]）——很可能直接落入H区，引发频繁的Humongous Allocation Failure； - 设置
-XX:G1HeapRegionSize时需权衡：Region太大，浪费空间且小对象碎片增多；Region太小，H区更容易因连续空闲不足而失败； - 监控
G1HumongousAllocation日志和Humongous Total指标，比看“老年代使用率”更能预判是否即将触发Full GC。
