大对象直接进入老年代是绕开复制算法硬限制的必要机制，而非优化；仅Serial/ParNew收集器支持-XX:PretenureSizeThreshold（单位字节），需配合合理堆配置与GC日志验证。
大对象直接进老年代，不是“优化”，而是必须绕开复制算法的硬限制
大对象（比如 new byte[4 * 1024 * 1024] 这样的 4MB 数组）在 Serial 或 ParNew 收集器下，只要超过 -XX:PretenureSizeThreshold 阈值，就**根本不会尝试在 Eden 区分配**——JVM 直接跳过新生代，去老年代找连续空间。这不是可选策略，是避免触发“标记-复制”算法灾难性开销的底层机制。
- 新生代 GC 必须把存活对象从 Eden 复制到 Survivor，或从 From 复制到 To；复制一个 4MB 对象 = 每次 Minor GC 多扛 4MB 内存带宽 + 停顿时间
- Survivor 区通常只有几百 KB 到几 MB，根本装不下大对象，强行分配会导致频繁 Allocation Failure 和担保失败
-
-XX:PretenureSizeThreshold默认为 0（即关闭），启用后仅对 Serial/ParNew 有效；用 G1、ZGC、Shenandoah 时该参数**完全无效**
怎么设 -XX:PretenureSizeThreshold 才真正起作用
设了参数却没看到对象进老年代？大概率是因为收集器不匹配或单位写错。这个参数只接受**字节整数**，不支持 m、M、k 等后缀，写成 -XX:PretenureSizeThreshold=4M 会被 JVM 忽略（静默失效）。
- 正确写法：
-XX:PretenureSizeThreshold=4194304（4MB），或用常量表达式如4*1024*1024（需确保 JVM 版本支持，JDK 8u20+ 可识别） - 必须搭配 Serial 或 ParNew：加
-XX:+UseSerialGC或-XX:+UseParNewGC（注意后者在 JDK 9+ 已废弃，CMS 场景下仍可用） - 验证是否生效：加上
-XX:+PrintGCDetails，观察 GC 日志里 eden 使用率是否异常低，同时老年代（tenured generation）增长明显
设太高或太低都会出问题
阈值不是越大越好，也不是越小越安全。它本质是在「减少复制」和「加剧老年代碎片/压力」之间做权衡。
- 设得太低（比如 64KB）：大量中等对象进老年代，老年代提前填满，触发更频繁的 CMS 或 Full GC
- 设得太高（比如 16MB）：漏掉本该拦截的大对象，它们仍在 Eden 分配 → Minor GC 时疯狂复制 → STW 时间飙升
- 真实业务中建议从 1–4MB 起步（参考电商订单体约 1KB，但批量缓存/IO 缓冲区常达 2–3MB），再根据
GC log中promotion failure和concurrent mode failure频次动态下调
别忘了老年代本身得能接住这些大对象
就算 -XX:PretenureSizeThreshold 生效了，如果老年代剩余连续空间小于对象大小，JVM 会直接抛 java.lang.OutOfMemoryError: GC overhead limit exceeded 或触发 Full GC —— 这时候参数不是没用，而是暴露了堆结构设计缺陷。
- 必须保证老年代初始容量足够：比如总堆 3GB，年轻代设
-Xmn1g，老年代就有 2GB 可用，才能稳接多个 4MB 对象 - 避免用
-XX:MaxTenuringThreshold=1之类激进配置，否则年轻代对象“抢跑”晋升，进一步挤占老年代连续空间 - CMS 收集器下尤其要注意
-XX:CMSInitiatingOccupancyFraction，防止老年代还没满就提前并发收集，导致后续大对象无处安放
真正难的从来不是记住参数名，而是在 GC 日志里看出 tenured generation 的使用曲线是否平滑、有没有突刺，以及每次大对象分配后 Survivor 区是否突然“空了”——那说明动态年龄判断被触发了，而你可能根本没意识到。
