过早晋升表现为老年代单次晋升量异常大（如>20mb/sec）、tenuring distribution中年龄阈值骤降至2且age1对象占比过高、老年代呈阶梯式增长且full gc释放极少；需排除大对象直入、system.gc()及gc算法差异干扰。

直接看 GC 日志里“老年代增长量”和“年轻代回收量”的差值是否异常大——如果每次 Minor GC 后，老年代使用量猛增（比如单次晋升几十 MB），但应用并无大量长生命周期对象，大概率就是过早晋升。

看日志中“Promoted”数值是否持续偏高

开启 -XX:+PrintGCDetails -XX:+PrintTenuringDistribution 后，每条 Minor GC 日志会隐含晋升量：

• 例如：[PSYoungGen: 71680K->5120K(71680K)] 112800K->81912K(159232K)
• 年轻代减少量 = 71680K − 5120K = 66560K
• 整个堆减少量 = 112800K − 81912K = 30888K
• → 晋升量 = 66560K − 30888K = 35672K（约 35MB）

若连续多次晋升量 >20MB/sec，且远超业务实际长生命周期对象规模，说明大量本该在年轻代消亡的对象被提前送入老年代。

查 Tenuring Distribution 是否“年龄断层”

日志中出现类似以下片段，是关键信号：

Desired survivor size 61054720 bytes, new threshold 2 (max 15)
- age   1:   12456784 bytes,   12456784 total
- age   2:    8765432 bytes,   21222216 total

这表示：仅存活 1 次 GC 的对象就占了 Survivor 一半以上，JVM 已将晋升阈值从默认 15 动态压到 2 ——意味着只要活过两次 GC 就强制进老年代。这是典型的 Survivor 区太小或对象分配速率过高导致的“被迫提前晋升”。

比对 Full GC 触发前的老年代占用模式

过早晋升不会立刻引发 Full GC，但会埋下隐患。观察周期内：

• 老年代使用量呈“阶梯式缓慢上升”，而非平缓增长
• 每次 Minor GC 后，老年代占用增加明显（如 +15~40MB），但之后几乎不下降
• Full GC 前，老年代已长期维持在 85%+，且清理后释放空间极少（比如只回收几 MB）

这种“只进不出”的老年代行为，说明里面塞满了本不该存在的短期对象，major GC 效率极低，停顿时间也更长。

排除其他干扰因素

确认是过早晋升，不是其他原因：

• 检查是否启用了 -XX:PretenureSizeThreshold，且有大对象直入老年代（日志中会标 humongous allocation）
• 确认没频繁调用 System.gc()（除非明确启用 -XX:+DisableExplicitGC，否则可能触发非预期 Full GC）
• 查看是否使用 G1/ZGC：它们的日志格式不同，需关注 G1EvacuationPause (young) 后的 Old 区变化，以及 Humongous Reclaim 是否频繁