真正能一针见血识别新生代晋升过早，关键是盯住三个可量化日志信号：晋升量异常（连续超20MB/sec）、年龄分布断层（age 1对象占比过高）、老年代阶梯式上涨（Minor GC后持续缓慢增长）。
面试中一提到GC日志分析，很多人堆砌术语却答不到点上。真正能“一针见血”识别新生代晋升过早，关键不是背参数，而是抓住三个可量化的日志信号：晋升量异常、年龄分布断层、老年代阶梯式上涨。这三点在日志里清晰可见，不需要工具，肉眼就能判断。
盯住每次Minor GC后的“晋升量”是否持续超标
这不是看“Promoted”字段有没有出现，而是自己算出来：
- 从日志如 [PSYoungGen: 71680K->5120K(71680K)] 112800K->81912K(159232K) 中，年轻代减少量 = 71680K − 5120K = 66560K
- 整个堆减少量 = 112800K − 81912K = 30888K
- 晋升量 = 66560K − 30888K = 35672K（约35MB）
如果连续几次都超过20MB/sec，且业务并无大量缓存或长生命周期对象，这就是强信号——大量本该在Eden消亡的对象被提前送进老年代。
看Tenuring Distribution里有没有“年龄1就霸屏”
开启-XX:+PrintTenuringDistribution后，重点扫这几行：
- Desired survivor size xxx bytes, newthreshold 2 (max 15) → 晋升阈值被动态压到2，说明Survivor撑不住了
- - age 1: 12456784 bytes, 12456784 total → 所有存活对象里，只经历1次GC的就占了一半以上
这种“年龄断层”不是JVM保守，是被迫：要么Survivor太小，要么对象分配速率太高，导致刚躲过Eden就被踢进老年代。
观察老年代占用是否“只进不出”
过早晋升不会立刻触发Full GC，但会留下典型痕迹：
- 老年代使用量呈**阶梯式缓慢爬升**（每次Minor GC后+15~40MB），而不是平缓波动
- Minor GC后老年代几乎不下降，长期维持在85%+，Full GC清理后只释放几MB
- 对应业务无明显大促或数据导入，但老年代却像“漏斗底端堵住”一样越积越多
这时老年代塞的不是真正的长生命周期对象，而是本该在年轻代就死掉的“短命客”，Major GC效率低、停顿长，隐患已埋实。
快速排除干扰项，锁定真因
避免把其他问题误判为晋升过早：
- 查日志里有没有humongous allocation字样——有则说明是大对象直入老年代，不是晋升问题
- 确认没频繁调用System.gc()（除非明确加了-XX:+DisableExplicitGC）
- 如果是G1/ZGC，不看Tenuring Distribution，改盯G1EvacuationPause (young)后Old区变化量
面试时讲清这四步，比罗列十种GC参数更有说服力——你不是在读日志，是在解构系统行为。
