大对象直接进入老年代是为了规避新生代复制开销，避免 Survivor 区溢出和 Minor GC 停顿加剧；典型大对象包括超长字符串、大数组及框架中预分配的大型缓存结构，其判定标准因 GC 器而异：G1 以 Region 大小为基准，Parallel/CMS 则依赖阈值或 Eden 半区估算。
大对象在 JVM 中不走常规路径，而是直接绕过新生代，进入老年代。这是为了规避复制开销、减少 GC 频次，但也会加速老年代空间消耗，带来潜在的 Full GC 风险。
哪些算大对象
所谓“大”，不是固定字节数，而是指需要大量连续内存空间的对象，典型如：
- 超长字符串（如 new String(new char[1024 * 1024])）
- 大数组（如 byte[8MB]、int[2M]）
- 某些框架中一次性加载的大型缓存结构或序列化数据
判定标准取决于垃圾收集器：
- G1：以 -XX:G1HeapRegionSize 设置的 Region 大小为基准，若对象 ≥ 一个 Region，则视为大对象（Humongous Object），直接进老年代（更准确地说，是专门的 Humongous 区）
- Parallel Scavenge / CMS：无硬性阈值，由 JVM 动态估算并决策；通常对象大小超过 Eden 区一半时，就可能触发直接晋升
为什么大对象不走 Eden → Survivor 路径
新生代采用复制算法（Eden + 两个 Survivor），每次 Minor GC 都需将存活对象从一块区域复制到另一块。大对象复制成本极高：
- 拷贝耗时长，拖慢 Minor GC 速度
- 容易导致 Survivor 空间不足，触发分配担保失败，反而要提前挪到老年代
- 频繁复制还可能造成内存带宽压力和 CPU 占用上升
直接进老年代，省去多次复制，也避免干扰新生代 GC 的节奏。
大对象的回收特点
大对象一旦进入老年代，其生命周期往往较长，但并非永不回收：
- 仍受老年代 GC 管控（如 CMS 的并发标记清除、G1 的 Mixed GC、ZGC 的并发标记）
- 若长期无引用，会在下一次老年代 GC 中被识别并清理
- 特别注意 G1 的 Humongous 区：只有当整个 Region 中所有对象都不可达时，该 Region 才会被整体回收；单个大对象释放不会立即归还内存
常见风险是：多个大对象堆积，快速填满老年代，诱发 Major GC 或 Full GC，造成明显 STW 停顿。
如何观察与调优
定位大对象问题，关键靠日志与工具：
- 启用 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注 GC 日志中是否频繁出现 “Humongous Allocation” 或 “promotion failed”
- 使用 jstat -gc <pid> 观察老年代使用率（OU）是否陡升、YGC 次数是否异常降低（说明部分对象没走新生代）
- 通过 jmap -histo <pid> 或 MAT 分析堆快照，按实例数或总占比排序，快速锁定大对象类型
- 必要时调整：-XX:PretenureSizeThreshold（仅 Parallel GC 有效，设为字节数，强制 ≥ 该值的对象直接进老年代）
