动态年龄判定核心是空间驱动而非时间驱动：JVM每次Minor GC后按年龄从小到大累加Survivor中对象大小，累计≥50%容量时即晋升所有≥该年龄对象；实际阈值由-XX:SurvivorRatio和-XX:MaxTenuringThreshold协同调控，并通过GC日志中“new threshold”验证。
Java 虚拟机调优中对象晋升年龄的动态调整，核心不是“设一个固定数字”，而是让 JVM 的自适应机制在合理空间约束下，自然算出更匹配业务对象生命周期的晋升节奏。
动态年龄判定的本质是空间驱动，不是时间驱动
JVM 每次 Minor GC 后，会按年龄从小到大累加 Survivor 区中各年龄段对象的大小。一旦某一年龄 N 及以上对象的累计大小 ≥ Survivor 总容量的 50%（由 TargetSurvivorRatio 控制，默认 50），就立刻把所有年龄 ≥ N 的对象晋升到老年代。这个 N 就是“动态晋升年龄”，日志里显示为 new threshold N (max X)。
真正起作用的参数组合
-
-XX:SurvivorRatio=6：让 Eden:S0:S1 = 6:1:1，Survivor 总占比升至约 1/8 → 空间变大，同一批对象更难触达 50% 累加线 → 晋升延后 -
-XX:MaxTenuringThreshold=6：设一个合理上限，既防极端情况（如突发流量塞爆 Survivor）导致 age=1 就晋升，又给动态机制留调节余地 -
-XX:+UseAdaptiveSizePolicy：必须开启（默认已开），否则动态年龄判定不生效，退化为固定阈值
怎么确认调优是否生效
启用 -XX:+PrintGCDetails -XX:+PrintTenuringDistribution，观察 GC 日志：
- 关注
Desired survivor size xxx bytes, new threshold N (max X)—— 这才是真实晋升年龄 - 查看
S0: xx%/S1: yy%—— 目标是稳定在 30%～45%，长期 > 50% 说明 Survivor 还是太小 - 对比
tenured字段大小变化 —— 若某次 GC 后晋升量突增，且对应 Survivor 使用率接近 50%，基本就是动态判定被触发了
常见踩坑点
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 盲目把
-XX:MaxTenuringThreshold改成 0 或 1：等于废掉 Survivor 缓冲，所有存活对象直奔老年代 - 只调
MaxTenuringThreshold却不看 Survivor 容量：比如设成 15，但 Survivor 太小，实际new threshold常年是 2，改了也白改 - 忽略大对象干扰：用
-XX:PretenureSizeThreshold把超阈值的大数组、大缓存直接分配进老年代，避免挤占 Survivor
不复杂但容易忽略。
立即学习“Java免费学习笔记（深入）”；
