MaxTenuringThreshold 仅是晋升年龄上限，JVM 会根据 Survivor 空间使用情况动态下调真实阈值；若 Survivor 溢出，年龄为1的对象也可能直接晋升老年代。
MaxTenuringThreshold 是怎么被 JVM 动态覆盖的
它不是你写多少就生效多少——JVM 会根据 Survivor 空间实际使用情况，在 GC 过程中动态调整对象晋升年龄阈值，MaxTenuringThreshold 只是上限。哪怕你设成 15，如果 Survivor 区连放不下一次复制的对象，JVM 可能下一轮 GC 就直接把年龄为 1 的对象推进老年代。
- 触发动态调整的时机：每次 Minor GC 后，JVM 统计当前 Survivor 中所有存活对象的年龄分布，计算“能容纳下全部存活对象的最小年龄阈值”
- 真实晋升年龄 =
min(对象当前年龄, JVM 计算出的阈值)，而这个计算出的阈值 ≤MaxTenuringThreshold - 典型现象：
-XX:MaxTenuringThreshold=15，但jstat -gc显示很多对象在 age=2 就进了老年代——说明 Survivor 溢出，JVM 主动降级了阈值
SurvivorRatio 和 MaxTenuringThreshold 要一起看
只调 MaxTenuringThreshold 不碰 SurvivorRatio，大概率白忙。Survivor 空间太小，再高的阈值也没意义；空间够大，低阈值反而导致过早晋升。
-
SurvivorRatio=8（默认）表示 Eden : Survivor = 8 : 1 : 1，即两个 Survivor 合计占年轻代 1/5；若年轻代 1GB，则每个 Survivor 仅 100MB - 当大量短期对象在 GC 后仍存活，Survivor 快速填满，JVM 就被迫提前晋升——此时增大
SurvivorRatio（比如设为 4）比调高MaxTenuringThreshold更有效 - 反例：把
MaxTenuringThreshold设成 1，同时SurvivorRatio=16，结果 Survivor 空间太大、回收效率下降，Minor GC 时间反而拉长
用 jstat 和 -XX:+PrintGCDetails 验证真实晋升行为
别信配置文件里的数字，要看 GC 日志里每轮实际发生了什么。JVM 不会告诉你“本次用了几岁晋升”，但日志里的 age 列和 tenured 数量能反推。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 开启详细 GC 日志：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注类似[PSYoungGen: 324275K->24970K(353280K)] 324275K->24970K(1161216K), 0.0224550 secs]这行之后的age分布段 - 用
jstat -gc <pid></pid>查看S0C/S1C（Survivor 容量）、EC（Eden 容量）、YGC（次数）和YGCT（耗时），持续观察 Survivor 使用率是否长期 >80% - 关键信号：
S0U或S1U在 GC 后反复接近S0C，说明 Survivor 挤满，晋升阈值已被动态压低
Parallel GC 和 G1 GC 对 MaxTenuringThreshold 的处理差异
这个参数在不同垃圾收集器里地位完全不同：对 Parallel GC 是重要调节杠杆，对 G1 GC 几乎无效。
立即学习“Java免费学习笔记（深入）”；
- Parallel GC（
-XX:+UseParallelGC）严格遵守MaxTenuringThreshold的语义，且支持动态调整，是主要调优项 - G1 GC（
-XX:+UseG1GC）完全忽略该参数，它用-XX:G1MaxNewSizePercent和-XX:G1NewSizePercent控制年轻代大小，并通过预测模型决定何时晋升，不依赖固定年龄阈值 - 常见误操作：在 G1 下还花时间调
MaxTenuringThreshold，日志里根本看不到 age 相关统计，参数形同虚设
MaxTenuringThreshold 却不看 S0U/S0C 比值，就像调音时不听实际声音。 
