大对象直接进入老年代以避免复制开销，JVM通过-XX:PretenureSizeThreshold设定字节阈值，仅对Serial和ParNew收集器有效，G1/ZGC忽略该参数；阈值按运行时单次分配的连续内存大小判断，需注意单位、对齐及老年代空间是否充足。

大对象直接进入老年代，核心是避免复制开销——新生代用复制算法（如 Eden + Survivor），而大对象挪来挪去代价太高。所以 JVM 提供 -XX:PretenureSizeThreshold 参数，设定一个字节数阈值：只要新分配对象的大小 ≥ 这个值，就跳过新生代，直奔老年代。

这个阈值怎么起作用？

它不是按“对象引用大小”或“类结构”算的，而是看运行时实际申请的连续堆内存字节数。典型例子是 byte 数组、超长 String、大 ArrayList 底层数组等：

• 比如设 -XX:PretenureSizeThreshold=3145728（即 3MB），那么 new byte[3 * 1024 * 1024] 会直接进老年代；new byte[3 * 1024 * 1024 - 1]（2.999MB）则仍走正常路径：先在 Eden 分配。
• 注意：该参数只对 Serial 和 ParNew 收集器有效。用 G1 或 ZGC 时，此参数被忽略——G1 有自己基于 Region 的大对象（Humongous Object）处理逻辑。
• 阈值单位是字节，不支持 KB/MB 单位缩写（如不能写 3m），必须写纯数字，例如 3145728 或 1048576（1MB）。

内存判定的关键细节

JVM 判定是否“超限”，发生在对象分配那一刻，且只看单次 new 操作申请的连续内存大小，不累计、不估算、不包含对象头或对齐填充（但会对齐后判断）：

• 数组对象：按元素类型 × 长度 + 数组头（通常 12 字节）+ 对齐补齐（通常按 8 字节对齐）计算总大小，再与阈值比。
• 普通对象（如 new HashMap()）：本身很小（对象头 + 引用字段），不会触发该机制；但若其内部创建了大数组（如扩容后的 table），那个数组可能单独触发。
• 字符串：new String(new char[1000000]) 中的 char[] 是关键，char 占 2 字节，100 万个 char ≈ 2MB 内存，是否进老年代取决于阈值设置。

为什么不能只靠阈值？还得看 GC 器和堆布局

即使满足阈值条件，最终能否成功分配到老年代，还依赖当前老年代是否有足够连续空间：

• 如果老年代已碎片化严重，又没开启压缩（如 CMS 不做 Full GC 压缩），大对象可能因找不到连续空间而触发 Full GC，甚至 OOM。
• 使用 Parallel GC 时，该参数生效，但若老年代空间不足，也会提前触发老年代回收。
• 实践中建议配合 -XX:+PrintGCDetails 观察日志：看到 “Allocation Failure” 后直接出现老年代分配记录（如 “PSYoungGen” 不出现该对象，“ParOldGen” 出现），说明阈值生效。

常见误区提醒

别把 PretenureSizeThreshold 当成“性能银弹”：

• 设得太小（如 64KB），会导致大量中等对象涌入老年代，加速老年代填满，反而引发更频繁的 Full GC。
• 设得太大（如 16MB），等于基本失效，失去控制意义；而且很多应用根本没那么多真正的大对象。
• 它不解决内存泄漏，也不影响对象生命周期——进了老年代的对象，依然要等下次老年代 GC 才可能被回收。