对象晋升策略影响gc频率、停顿与内存利用率；大对象直入老年代（-xx:pretenuresizethreshold）、年龄阈值调整（-xx:maxtenuringthreshold）及动态年龄判定机制共同优化晋升行为，空间分配担保则预防minor gc失败。
对象晋升策略直接影响 GC 频率、停顿时间与内存利用率。选错策略不会立刻报错，但会悄悄拖慢系统——比如老年代提前填满引发频繁 Full GC，或 Survivor 区反复溢出导致对象“早熟”晋升。
大对象直入老年代：避免复制开销
大对象（如 4MB 的 byte[]、超长 JSON 字符串）若在 Eden 分配，Minor GC 时需整块复制到 Survivor，既耗时又易触发空间不足。启用 -XX:PretenureSizeThreshold=3145728（3MB），可让 ≥3MB 的对象跳过新生代，直接进入老年代。
- 仅对 Serial 和 ParNew 收集器生效；Parallel Scavenge 不支持该参数
- 阈值不宜设得太低（如 128KB），否则大量中等对象涌入老年代，加速 Major GC
- 配合老年代 GC 器选择（如 CMS 或 G1）更稳妥，避免因碎片导致分配失败
年龄阈值控制：平衡存活对象沉淀与 Survivor 压力
对象每熬过一次 Minor GC，年龄 +1；默认达 15 岁才晋升，但实际常无需等到上限。通过 -XX:MaxTenuringThreshold 调整，本质是在“让对象多活几轮回收”和“及时腾空 Survivor”之间权衡。
- 设为 1：短期对象快速晋升 → 老年代膨胀快，Full GC 风险上升
- 设为 15（默认）：Survivor 区可能积压大量中龄对象，一旦总和超半区容量，触发动态晋升（见下条）
- 生产环境建议从 6–8 开始压测，观察老年代增长速率与 Minor GC 吞吐量
动态年龄判定：应对流量突变的自适应机制
JVM 不死守固定年龄阈值。当某年龄段（如 age=4）的所有对象总大小超过 Survivor 空间一半，所有 ≥4 岁的对象会立即晋升——这是防止 Survivor 溢出的保护性策略。
- 该机制自动生效，无需显式配置
- 说明 Survivor 区偏小或对象存活率高，应检查业务逻辑（如缓存未及时释放）或调大新生代
- GC 日志中若频繁出现 “age X -> old” 且 X 远低于 MaxTenuringThreshold，就是此机制在起作用
空间分配担保：Minor GC 前的关键安全检查
每次 Minor GC 前，JVM 会预估本次晋升到老年代的对象总量，并检查老年代是否有足够连续空间容纳。若不满足，可能跳过 Minor GC 直接触发 Full GC。
- 担保失败常见于老年代碎片化严重，或历史晋升平均大小被低估
- 可通过 -XX:+HandlePromotionFailure 允许“冒险”Minor GC（但风险是 Promotion Failure 导致 Full GC）
- 长期看，比参数调优更有效的是减少大对象、缩短对象生命周期，降低晋升压力
