大对象直接进入老年代是绕开复制算法硬限制的必要机制，而非优化；仅serial/parnew收集器支持-xx:pretenuresizethreshold（单位字节），需配合合理堆配置与gc日志验证。
大对象直接进入老年代，不是为了“优化性能”，而是为绕开新生代复制算法的硬性限制。它本质是一种必要机制，而非可选策略。
为什么必须跳过新生代？
新生代（尤其是 Eden + Survivor）采用标记-复制算法，要求每次 Minor GC 都要把存活对象从一个 Survivor 区复制到另一个。而大对象（如 new byte[4 * 1024 * 1024]）往往几 MB 起步，Survivor 区通常仅几百 KB 到 2MB，根本装不下。强行分配会导致：
- 每次 Minor GC 都要搬运数 MB 数据 → 内存带宽暴涨、STW 时间显著拉长
- Survivor 区快速溢出 → 触发担保失败（HandlePromotionFailure）→ 进而引发 Full GC
- Eden 区看似空闲，却因无法找到连续空间而频繁 Allocation Failure
-XX:PretenureSizeThreshold 的真实作用边界
该参数只在使用 Serial 或 ParNew 收集器时生效（注意：JDK 9+ 中 ParNew 已废弃，CMS 场景下仍可用；G1/ZGC/Shenandoah 完全忽略此参数）。关键细节包括：
- 单位必须是字节整数，不支持 4M、4m 等写法，正确示例：4194304 或 4*1024*1024（JDK 8u20+ 支持表达式）
- 默认值为 0，即关闭该机制；设为非零后，JVM 将完全跳过 Eden 分配流程，直接向老年代申请连续空间
- 若老年代当前剩余连续空间小于对象大小，分配失败 → 触发 Full GC，再重试分配
阈值设置不是越大越好
它是在「减少复制开销」和「加剧老年代压力/碎片」之间做权衡：
- 设得太低（如 64KB）：大量中等对象涌入老年代，老年代提前饱和，CMS 或 Full GC 更频繁
- 设得太高（如 16MB）：本该拦截的 4–8MB 缓冲区、批量响应体仍留在 Eden，Minor GC 时疯狂复制 → STW 暴涨
- 推荐起始值：1–4MB。电商订单体约 1KB，但 IO 缓冲、批量缓存、JSON 解析结果常达 2–3MB，可结合 GC 日志中 promotion failure 和 concurrent mode failure 频次动态下调
如何验证是否生效？
加 JVM 参数：-XX:+PrintGCDetails -XX:+UseSerialGC（或 -XX:+UseParNewGC），观察日志：
- Eden 使用率长期偏低（比如始终
- 老年代（tenured generation）使用量在对象创建后立即增长对应字节数（如 +4MB）
- 日志中无对应对象的 “promotion” 记录，因为它压根没经过新生代
