G1中大对象指超过单Region 50%大小的对象，必须分配在连续Region中，因JVM寻址依赖单一线性地址段；若无足够连续空闲Region则直接OOM，而非碎片整理。
Java中大对象（Humongous Object）在G1垃圾回收器里不是“稍大一点的对象”，而是指大小超过单个Region容量50%的对象。它触发的是完全不同的内存分配路径，一旦处理不当，极易直接引发java.lang.OutOfMemoryError: Java heap space (large object allocation)——这不是普通堆满，而是连续空闲Region告罄的硬性失败。
为什么大对象必须独占连续Region
G1要求每个Humongous Object必须完整落在一组**物理连续、逻辑相邻**的Region中。原因根植于底层内存寻址机制：
- JVM字段访问依赖“基址寄存器 + 固定偏移量”快速计算地址，这要求整个对象处于**单一线性虚拟地址段**内；
- 若对象跨非连续Region，引用将无法用一个指针+偏移统一表示，CPU寻址失效；
- GC移动对象时需原子更新所有外部引用，而巨型对象的引用可能遍布堆、栈甚至元空间，同步成本不可接受，因此G1禁止移动Humongous Region。
特批分配如何变成OOM导火索
所谓“特批”，实为绕过常规分配逻辑的权宜之计，代价是资源调度刚性极大：
- 分配时需扫描全堆，查找长度足够的**空闲Region连续段**，时间复杂度接近O(n)；
- 找不到足够连续空闲块时，G1不会尝试碎片整理或拆分，而是立即放弃，抛出OOM；
- 即使有足够总空闲内存，只要它们分散在不连续Region中，就无法满足大对象需求——这就是典型的**外部碎片**。
常见诱因与可落地的应对措施
业务中高频出现OOM，往往不是堆太小，而是大对象使用模式与G1机制错配：
立即学习“Java免费学习笔记（深入）”；
-
Region尺寸不合理：默认Region大小（如1~4MB）易使1MB左右的byte[]、ArrayList等落入Humongous区间。可调大Region（如
-XX:G1HeapRegionSize=16M），让多数大对象回归普通分配路径； -
缺乏预留缓冲：未设置
-XX:G1ReservePercent=10，导致Mixed GC后无余量承接突发大对象； -
监控缺失：未开启
-Xlog:gc+humongous*=debug，无法定位哪些类在持续生成巨型对象（如日志序列化、临时缓存、未分片的批量响应体）； - 代码层规避：避免一次性new超大数组；改用流式处理、分块读写、对象池复用等手段，从源头减少Humongous分配请求。
