晋升阈值需匹配对象生命周期：通过-xx:+printtenuringdistribution观察实际年龄分布，若对象多在3～5轮gc后稳定且survivor区常超50%容量，则设为5更优；盲目调小易致老年代碎片化，应优先调大survivorratio而非压低阈值。
晋升阈值不是越小越好，也不是越大越稳，关键在于匹配应用的对象生命周期特征。默认的15次GC年龄阈值适用于大多数短生命周期对象场景，但真实业务中常需主动调整。
看对象存活规律再定阈值
先观察实际对象年龄分布，而不是凭经验拍板：
- 加-XX:+PrintTenuringDistribution运行一段时间，重点关注“age=1”“age=2”这些低龄段对象是否大量堆积在Survivor区；
- 如果发现多数存活对象在3～5轮GC后就稳定下来，且Survivor区反复出现“年龄≥4的对象总和占满一半以上”，说明默认15太高，可设为-XX:MaxTenuringThreshold=5；
- 反之，若打印日志里几乎看不到age≥3的对象，说明对象死得早，阈值可保持默认，甚至略调高，减少不必要的晋升检查开销。
结合Survivor空间使用率判断
SurvivorRatio=8（即Eden:S0:S1=8:1:1）是常见配置，但不等于合理。真正影响晋升节奏的是Survivor的实际承载能力：
- 当Minor GC后，Survivor中某一年龄段对象总大小超过其容量的一半，JVM会把所有≥该年龄的对象批量晋升——这是隐式触发晋升的关键机制；
- 如果频繁看到“Desired survivor size ××× bytes, new threshold ×× (max ××)”这类日志中threshold被动态下调，说明Survivor太小或对象存活偏多，应优先考虑增大Survivor比例（如-XX:SurvivorRatio=6），而非一味压低MaxTenuringThreshold；
- 单纯调小阈值可能让本该快速死亡的对象提前进老年代，反而加剧老年代碎片和Full GC风险。
避开大对象与担保失败的干扰
晋升阈值只管“年龄路径”，但还有两条直通老年代的捷径：
- 单个对象超过-XX:PretenureSizeThreshold（如1MB）会跳过年轻代，这跟阈值无关，需单独监控大对象分配频率；
- Minor GC时，若Eden+From中存活对象总量远超To区容量，超出部分直接晋升——这种“分配担保失败”属于空间不足导致的被动晋升，反映的是年轻代整体 sizing 问题，需通过-Xmn或-XX:NewRatio调整大小，而不是改阈值。
小步验证，避免激进调整
一次只动一个参数，用固定堆大小做可控实验：
- 例如启动参数：-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=4；
- 配合-XX:+PrintGCDetails观察几次Minor GC后对象是否按预期在age=4时集中晋升；
- 再对比阈值为8或15时的晋升分布和GC耗时变化，确认调整确实带来收益，而非掩盖了更底层的空间配置问题。
