观测晋升频率需联动jstat -gc时序数据与-xx:+printtenuringdistribution日志：用jstat -gc推算ou增量得单次晋升量，结合年龄分布判断生命周期模式，并通过e、s0u/s1u、o三指标交叉验证异常晋升。
要观测变量晋升频率并监测其生命周期分布，核心是把 jstat -gc 的时序数据和 -XX:+PrintTenuringDistribution 日志联动分析，不能只看单次快照。
抓取晋升频率的关键指标
晋升本身不直接出现在 jstat -gcutil 中，必须用 jstat -gc 推算：
- 持续运行
jstat -gc <pid> 1000 10</pid>（每秒一次，共10次），记录 OU 列数值变化 - 每次 YGC 后 OU 的增量（单位 KB）即为本次晋升量，例如 OU 从 1200000 → 1245000，说明约 45MB 对象晋升
- 若连续多次 YGC 都带来 >30MB 晋升，且 S0U/S1U 始终未清空，大概率存在 Survivor 区空间不足导致的批量提前晋升
- 注意排除 FGC 干扰：FGC 会回收老年代，OU 下降后又上升，容易误判为“某次 YGC 晋升特别多”，需同步看 FGC 次数与 FGCT
结合年龄分布识别生命周期模式
启用 -XX:+PrintTenuringDistribution（需重启 JVM），GC 日志中会出现类似：
- age 2: 215040 bytes, 1107200 total
- age 3: 98304 bytes, 1205504 total
Desired survivor size 1048576 bytes, new threshold 2 (max 15)
- 如果
age 1 total就已接近或超过 Desired survivor size（如上例中 892KB > 1048KB × 0.5），说明 age1 对象已占满 Survivor 半壁江山，JVM 会把 age1 及以上全部晋升——这是典型的“一岁就进老年代” - 若
age 3+ total稳定增长且长期不减少，说明有中长期存活对象（如连接池、缓存容器），需确认是否合理 -
new threshold在 2～4 之间频繁跳变，表明 Survivor 空间持续承压，不是对象“该活多久”，而是“Survivor 已装不下”
定位异常晋升的三步交叉验证
单看任一指标都易误判，需三项联动：
- E 使用率 + YGC 频次：E 在 90%～99% 区间 1～2 秒内反复打满又清空，YGC 次数陡增 → Eden 分配过快，晋升压力前置
- S0U/S1U 波动形态：正常应“一空一满”交替；若两者长期都在 40%～70%，说明 Survivor 区利用率高但清空不彻底，易触发动态年龄晋升
- O 列变化节奏：OU 随 YGC 呈阶梯式稳定上升（如每次 +1.2%）属正常；若某次 YGC 后 O 突增 4%～6% 且无 FGC，极可能是大对象直入老年代或 Survivor 溢出式晋升
