G1将大对象存入独立Humongous区而非老年代，其判定依据是对象体积是否超过当前Region大小的一半（50% Rule），Region大小由堆总大小自动推算或由-XX:G1HeapRegionSize指定；Humongous区不参与Young GC，仅在Mixed GC或Full GC时回收，且要求连续分配、不可压缩移动。
G1对大对象的处理不是“晋升到老年代”，而是单独划出Humongous区存放，且判定逻辑和参数强耦合——搞错Region大小，PretenureSizeThreshold就失效。
大对象怎么被识别：50% Rule不是固定字节数
G1不看绝对大小，只看对象体积是否超过当前Region大小的一半。这个Region大小由堆总大小自动推算（默认目标2048个Region），比如：
- 堆设为4GB → Region ≈ 2MB → 大对象阈值 = 1MB
- 堆设为16GB → Region ≈ 8MB → 大对象阈值 = 4MB
- 手动设
-XX:G1HeapRegionSize=4M→ 阈值就是2MB
所以同一段代码，在不同堆配置下可能触发/不触发Humongous分配。线上排查时，先用jstat -gc或GC日志里的Region size确认实际值，别直接套用“1MB”这种经验数字。
Humongous区不是老年代，但回收时机很特殊
Humongous区物理上是独立的Region集合，逻辑上不属于Eden/Survivor/Old三类中的任何一类。但它有两点关键行为：
- 一个大对象若跨多个Region（比如8MB对象在2MB Region下占4个），这些Region必须连续分配，否则直接
OutOfMemoryError: GC overhead limit exceeded - 它不会参与Young GC；只有Mixed GC或Full GC时才被扫描和回收——这意味着如果业务高频创建短期大对象（如临时图片Buffer），Humongous区会快速填满，又迟迟不被清理，最终拖垮Mixed GC频率
典型症状：GC日志里频繁出现Humongous allocation，同时Mixed GC次数猛增、停顿时间拉长，但Old区使用率反而不高。
怎么避免误入Humongous：绕开50%陷阱的实操手段
不是所有大对象都该进Humongous。如果对象生命周期短、复用率高，强行走Humongous反而放大碎片和GC压力。可用以下方式干预：
- 调大
-XX:G1HeapRegionSize（如从2M→4M），让原本1.5MB的对象避开阈值——但注意：Region变大会减少Region总数，影响G1的精细回收能力，MaxGCPauseMillis可能更难达标 - 用
-XX:PretenureSizeThreshold强制指定“多大就直接进老年代”，但G1中该参数仅对未达Humongous阈值的对象有效；一旦超了50%，此参数被忽略 - 代码层改用池化：
ByteBuffer.allocateDirect()换成ByteBufferPool.acquire()，把10MB图片Buffer变成可复用对象，彻底绕过单次大分配
最常被忽略的一点：Humongous区本身不压缩，也不移动对象。哪怕只用了其中1KB，整个Region（比如2MB）就一直被占用，直到整块被回收。这不是内存浪费，是设计使然——G1选择用空间换并发标记的简洁性。
