启用 -xx:+printgcdetails 后，gc 日志中直接反映晋升行为的关键字段是：tenuring threshold（显示为 new threshold）、survivor 容量与使用量、old gen 增量，以及 psyounggen 存活大小变化；其中 new threshold 值动态体现实际晋升年龄门槛，old gen 增量与年轻代存活量差值可量化晋升字节数，survivor 区饱和时 new threshold 陡降或归零即表明强制晋升启动。
启用 -XX:+PrintGCDetails 后，GC 日志里哪些字段直接反映晋升行为
开启 -XX:+PrintGCDetails 后，每次 Minor GC 和 Mixed GC 的日志中，age、tenuring threshold、survivor 容量与使用量、old gen 增量这几项是判断对象是否晋升的关键信号。
例如一条典型的 Parallel GC 日志片段：
[GC (Allocation Failure) [PSYoungGen: 123456K->8765K(131072K)] 123456K->98765K(393216K), 0.0234567 secs]
这里 PSYoungGen: 123456K->8765K 表示 Eden + Survivor 共释放出约 114MB 存活对象；而总堆从 123456K->98765K 意味着有约 24.7MB 对象被晋升至老年代（123456 − 8765 = 114691；114691 − 98765 = 15926K ≈ 15.6MB）。
-
tenuring threshold出现在 Minor GC 日志末尾，如Desired survivor size 67108864 bytes, new threshold 15 (max 15)—— 表明当前 Survivor 区尚有余量，未触发动态年龄提升 - 若看到
new threshold 5 (max 15)，说明 Survivor 区已拥挤，一批年龄 ≥5 的对象集体晋升 - 若日志中
PSYoungGen后存活大小突增（比如从 2MB 跳到 20MB），但old gen增量几乎为 0，大概率是 Survivor 区内对象“原地升级”而非真正晋升（即 Survivor-to-Survivor 复制但年龄达标，尚未跨代）
如何从日志反推 -XX:MaxTenuringThreshold 是否生效
-XX:MaxTenuringThreshold 不是强制门槛，而是“最大允许年龄”。实际晋升年龄由 JVM 动态计算，取决于 Survivor 空间利用率。日志中 new threshold 值才是真实生效的阈值。
常见误判场景：
- 设了
-XX:MaxTenuringThreshold=5，但日志持续显示new threshold 15→ Survivor 区始终宽松，没触发动态调整 - 设了
-XX:MaxTenuringThreshold=15，某次 GC 却出现new threshold 3→ Survivor 使用率超 50%，JVM 提前把 ≥3 岁的对象全送进老年代 - 日志里反复出现
Desired survivor size ... new threshold 0→ Survivor 已完全无法容纳，所有存活对象（包括刚出生的）都直接晋升，这是严重信号
此时应配合 -XX:+PrintTenuringDistribution 查看每岁对象分布，否则仅靠 PrintGCDetails 无法定位具体哪批对象被提前晋升。
不同 GC 器对晋升日志的表达差异
Parallel GC、CMS、G1 对晋升的描述粒度和术语不一致，不能套用同一套解读逻辑：
-
Parallel GC：日志明确标出
tenuring threshold和Desired survivor size，适合直接分析年龄策略 -
CMS：Minor GC 日志中不报
tenuring threshold，只显示ParNew存活对象大小，需靠前后两次老年代使用量差值倒推晋升量 -
G1：不按年龄晋升，而是按 Region 存活率（
-XX:G1MixedGCLiveThresholdPercent）决定是否在 Mixed GC 中回收老年代 Region；日志中mixed gc阶段的old gen变化量才是关键，age字段基本无意义
例如 G1 下看到 [GC pause (G1 Evacuation Pause) (mixed), 0.0456789 secs]，后面紧跟 [Eden: 120.0M(120.0M)->0.0B(112.0M) Survivors: 8.0M->16.0M Heap: 345.6M(4096.0M)->210.5M(4096.0M)]，其中 Heap 总量下降 135MB，但 Eden 清空 + Survivor 增加仅占约 128MB → 剩余约 7MB 就是本次 Mixed GC 从老年代 Region 回收并压缩的净效果，不是传统意义上的“晋升”。
容易被忽略的晋升异常信号
仅盯住 tenuring threshold 或 old gen 增量，可能错过真正的问题点：
- Minor GC 后
PSYoungGen存活对象大小稳定在 5–10MB，但old gen每次涨 200KB → 很可能是小对象批量逃逸（如短生命周期的 byte[]、StringBuilder），它们因超过 TLAB 或 Survivor 容量限制，直接分配在老年代（direct to old），日志中不会体现为“晋升”，而是表现为老年代缓慢但持续增长 - 某次 Minor GC 后
old gen突增数百 MB，但PSYoungGen存活量无明显变化 → 极可能是 Promotion Failure（晋升失败），JVM 触发 Full GC 并将整个年轻代复制进老年代，这种情况下日志会带Full GC标识，且耗时显著拉长 - 使用 G1 时，
mixed gc频繁但old gen使用率不降反升 → 说明 Mixed GC 回收效率低，老年代存活对象太多，可能需要调高-XX:G1MixedGCCountTarget或降低-XX:G1OldCSetRegionThresholdPercent
真正影响系统稳定性的，往往不是“该不该晋升”，而是“为什么不得不晋升”——比如 SurvivorRatio 设置过小导致 Survivor 区太小，或对象创建速率远超 GC 处理能力，这些都藏在日志的数字节奏里，而不是单行文本中。
