大对象直接进入老年代的核心是避免复制开销，依据单次分配的浅堆大小（含头、数据、对齐）与-xx:pretenuresizethreshold阈值比较，仅serial/parnew收集器生效，且需老年代有足够连续空间。
大对象直接进入老年代，核心是绕过新生代复制流程，避免高开销和内存碎片。它不依赖对象存活时间，而由单次分配的连续内存大小触发，且受垃圾收集器类型和堆空间状态双重约束。
触发条件：只看单次分配的实际字节数
JVM 在 new 操作执行时，立即计算该对象所需连续堆内存大小（含数组头、对齐填充），再与阈值比较：
- 数组类对象（如 byte[]、char[]、int[]）按元素类型 × 长度 + 头部（通常12字节）+ 对齐补齐后总字节数判定
- 普通对象（如 new HashMap()）本身很小，不会触发；但其内部扩容产生的大数组（如 table 数组）可能单独触发
- 字符串如 new String(new char[2_000_000])，char 占2字节，约占用4MB内存，是否进老年代取决于阈值设置
- 单位必须是纯数字字节，不支持 3m 或 3MB 写法，例如 3145728 表示3MB
参数配置：-XX:PretenureSizeThreshold 的生效前提
该参数仅在使用 Serial 或 ParNew 收集器时有效，G1、ZGC、Shenandoah 等现代收集器完全忽略它：
- 未设置时默认为0，所有对象都走常规路径（Eden → Survivor → 老年代）
- 设置为 -XX:PretenureSizeThreshold=4194304（即4MB），则 ≥4MB 的单次分配对象直接尝试在老年代分配
- 若同时启用 -XX:+UseParNewGC 和 -XX:+UseConcMarkSweepGC，该参数才起作用
- 搭配 -XX:+PrintGCDetails 观察日志：若对象未出现在 PSYoungGen 分配记录中，却出现在 ParOldGen 使用统计里，说明已生效
能否成功分配，还得看老年代有没有“地方”
满足阈值只是第一步，最终能否落进老年代，取决于当前老年代是否有足够连续空闲空间：
- 若老年代碎片化严重（如 CMS 未开启压缩），即使阈值达标，也可能因找不到连续块而触发 Full GC
- Parallel GC 下，若老年代空间不足，会提前启动老年代回收，而非直接拒绝分配
- JVM 在每次 Minor GC 前会做“空间分配担保”预判：老年代最大连续空闲空间 ≥ 当前新生代全部存活对象大小？若不满足，可能直接升级为 Full GC
- 因此，单纯调大阈值却不监控老年代碎片率和使用率，反而容易引发意外 OOM
典型误用与规避建议
实践中常见误区包括阈值设得过大、忽略收集器兼容性、或忽视堆布局影响：
- 不要把阈值设成远高于实际业务大对象尺寸（如设16MB却只分配5MB数组），既浪费判断开销，又失去优化意义
- 切换到 G1 后仍保留该参数，属于无效配置，应改用 -XX:G1HeapRegionSize 和 Humongous 区逻辑分析大对象行为
- 批量导入、音视频处理、缓存序列化等场景易产生大对象，建议结合 -XX:+PrintGCDetails 和 jstat 定期观察晋升量与老年代增长趋势
- 配合 -XX:+HandlePromotionFailure（JDK 6u24+ 默认开启）可减少因担保失败导致的 Full GC 风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
