Java对象晋升老年代由JVM在Minor GC时根据内存压力等实时决策，核心触发条件有四：年龄达标（含动态年龄判定）、大对象直入、Survivor空间不足就地升级、空间分配担保机制。
Java对象晋升老年代不是靠“时间到了就搬家”，而是JVM在每次Minor GC过程中，根据内存压力、对象存活特征和空间布局实时决策的结果。核心逻辑是：**新生代空间紧张时，把一部分对象转移出去，腾出空间继续分配新对象**。理解它，关键在于抓住四个触发条件及其背后的权衡意图。
年龄达标：默认15次，但实际常更早
新对象出生在Eden区，年龄为0；每次Minor GC后存活并进入Survivor区，年龄+1。当年龄达到-XX:MaxTenuringThreshold设定值（默认15），就会晋升。
但要注意：这个值只是上限，不是固定门槛。JVM会动态判断——如果某次GC后，Survivor中年龄为N的对象总大小超过该区容量的一半，那么所有年龄≥N的对象立即晋升，且N可能远小于15（比如2或3）。这叫“动态年龄判定”，目的是防止Survivor被大龄对象长期占满，导致新存活的小对象无处可放。
配置建议：
立即学习“Java免费学习笔记（深入）”；
- 用
-XX:+PrintTenuringDistribution观察每次GC后的年龄分布，看实际new threshold是多少 - 若日志频繁出现
new threshold 1或new threshold 2，说明Survivor太小或对象生命周期高度集中，可调大-XX:SurvivorRatio（如从8改为6）或适当降低-XX:MaxTenuringThreshold - 不建议盲目设为1——年龄过低会导致大量中年对象提前进老年代，加速老年代膨胀
大对象直入：跳过新生代，直接落老年代
特别大的数组、长字符串等（如new byte[4_000_000]），复制成本高、易造成内存碎片。JVM干脆绕过Eden→Survivor流程，直接在老年代分配。
启用条件：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 设置
-XX:PretenureSizeThreshold=4194304（即4MB） - 仅对Serial和ParNew收集器生效；Parallel Scavenge不支持该参数
- 未设置时默认为0，所有对象走常规路径
适用场景：已知存在稳定的大对象（如缓存块、批量导入数据），可提前设阈值避免频繁复制；但不宜设得太低（如1MB），否则会把本可快速回收的中等对象也推入老年代。
Survivor空间不足：就地升级，不管年龄
Minor GC后，Eden + 当前From Survivor中的存活对象要统一复制到To Survivor区。但如果To区装不下：
- 超出部分，无论年龄多小（哪怕刚出生1轮），全部直接晋升老年代
- 这叫“分配担保失败”，常见于突发流量（秒杀、报表导出）或Survivor比例过小
排查信号：
- GC日志中出现
Desired survivor size …, new threshold … (max …)后紧跟着大量晋升（Promotion Failure） - 老年代使用率在Minor GC后陡增，但没触发Full GC
缓解方式：
- 增大Survivor空间：调小
-XX:SurvivorRatio（如从8降到6），让每个Survivor占比更高 - 增大整个年轻代：
-Xmn调高，间接提升Survivor绝对大小 - 结合
-XX:+PrintGCDetails确认是否真因Survivor不足，而非老年代本身已快满
空间分配担保机制：晋升前先“问老年代借地方”
每次Minor GC前，JVM会预判：万一Survivor装不下，老年代能不能兜底？分两步检查：
- 老年代最大连续空闲空间 ≥ 当前新生代全部对象大小 → 安全，直接GC
- 否则，再看是否 ≥ 历次晋升平均大小 → 若是，尝试带风险GC；若否，直接触发Full GC腾空间
这个机制由-XX:+HandlePromotionFailure控制（JDK 6u24后默认开启）。它本质是防止Minor GC后因晋升失败而OOM，但也会带来副作用：老年代碎片多时，明明总空闲够，却因“不连续”而误判，引发不必要的Full GC。
调优提示：
- 若频繁看到Minor GC前触发Full GC，优先检查老年代碎片（可用G1或ZGC降低碎片影响）
- 不建议关闭
HandlePromotionFailure，除非你明确知道老年代始终有足够连续空间 - 配合
-XX:+PrintGCDetails观察每次Minor GC前是否有promotion failed字样
