大对象直接进入老年代是硬性路径而非优化，需同时满足估算大小≥-XX:PretenureSizeThreshold且超过Eden最大连续空闲块，仅Serial/Parallel GC支持，G1等不适用。
Java中对象不一定要“熬过”多次Minor GC才能进老年代。大对象会跳过年轻代，直接在老年代分配——这是JVM为避免复制开销和内存碎片而设计的关键优化路径。
什么样的对象算“大对象”
大对象不是凭主观感觉判断的，而是满足两个硬性条件：
- 需要连续内存空间（如数组、长字符串底层char[]、ByteBuffer底层数组等）
- 估算大小 ≥ JVM参数 -XX:PretenureSizeThreshold 设置的阈值（单位字节，默认为0，即禁用）
注意：对象大小包含对象头、实例字段、对齐填充，但不包括引用指向的其他对象内容；数组对象本身小，但其元素数据区被整体计入——所以 new byte[4 * 1024 * 1024] 是典型的大对象，而 new ArrayList<String>() 即使存了百万条记录，只要底层数组未扩容超阈值，就不触发该机制。
为什么必须直接进老年代
核心是规避新生代复制算法的性能陷阱：
立即学习“Java免费学习笔记（深入）”；
- Eden + Survivor 空间有限，大对象反复复制成本极高
- 频繁分配大对象易导致新生代碎片化，提前触发GC，即使堆总体空闲
- 老年代使用标记-整理或标记-清除算法，更适合长期持有大块连续内存
配置要点与常见误区
这个机制并非所有垃圾收集器都支持：
- 仅对 Serial 和 Parallel（即 -XX:+UseParallelGC） 收集器生效；G1、ZGC、Shenandoah 使用完全不同的大对象处理逻辑（如G1的Humongous Region）
- 阈值建议设为略小于Eden区大小的一半（例如Eden=512MB，可设
-XX:PretenureSizeThreshold=200M），避免因单次分配失败引发Full GC - 若老年代剩余连续空间不足，即使满足阈值，也会触发
promotion failed并可能升级为Full GC - 必须显式启用收集器（如
-XX:+UseParallelGC），单独设置PretenureSizeThreshold无效
如何验证是否生效
添加JVM参数观察GC日志：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps- 关注日志中是否出现
PSYoungGen未参与分配、或老年代（tenured generation）使用量突增且与代码中大对象大小吻合 - 也可用
jol（Java Object Layout）工具精确计算对象内存布局，确认是否真超阈值
