1. 先看一次真实的晋升现场老年代为什么突然变“热闹”我最早对“对象何时进入老年代”这个问题产生强烈兴趣不是因为面试题而是因为一个线上事故。某个网关类服务老年代GC原本两小时才触发一次某天突然变成十分钟一次老年代占用曲线像坐了电梯一样往上蹿。用GC日志和堆快照追了一圈发现大量短命对象莫名其妙出现在老年代里——按业务逻辑来说这些对象绝大部分应该在新生代就被回收掉根本活不到老年代。后来定位到根因就是对象晋升的路径出了“意外”。这里得先把结论摆出来Java对象进入老年代远远不止“年龄到了15岁”这一条路。实际上在HotSpot虚拟机里至少存在四条晋升通道而很多线上老年代激增问题恰恰是其中几条“非主流通道”在起作用。晋升路径触发条件关键参数年龄达标晋升对象熬过Minor GC的次数达到阈值MaxTenuringThreshold动态年龄判定同年龄对象累计大小超过Survivor目标使用率TargetSurvivorRatio大对象直接晋升对象大小超过配置阈值直接在老年代分配PretenureSizeThresholdSurvivor空间不足Minor GC后存活对象放不进Survivor区SurvivorRatio这篇文章我会把这四条路全部拆开讲每一路都配合参数配置、日志特征和实际表现。做JVM调优或者正准备Java面试的人看完应该能建立起一套完整的判断体系以后遇到老年代异常增长至少知道该往哪个方向查。2. 年龄计数器一个对象从Eden到老年代的“熬资历”路径2.1 新生代里对象的第一站Eden区与Minor GC绝大多数Java对象刚创建时都分配在新生代的Eden区这一步对应了热搜词里反复出现的“对象的创建”。Eden区本质是一块大内存池新对象在这里分配时速度极快因为它只做指针碰撞不搞复杂的内存扫描。Eden区满后触发Minor GC垃圾回收器会把Eden区里还存活的对象复制到Survivor区的FromS0中同时清空Eden。注意这里用的是复制算法不是标记清扫。下一次Minor GC时把Eden区和From区里存活的对象再次复制到ToS1然后交换From和To的角色。每经历一次Minor GC后还能活下来的对象年龄计数器加1这就是“熬资历”的过程。很多人的误解在于认为对象只要从新生代出来就一定会经历完整的0到15次Minor GC。实际不是这样的绝大多数对象在第一次Minor GC时就被回收了只有少数对象才会真的“熬”到阈值。2.2 Mark Word中4个bit决定的年龄上限15年龄计数器这个字段存放在对象头Mark Word里大小是4个bit。4个bit能表示的二进制范围是0000到1111也就是0到15。所以HotSpot里MaxTenuringThreshold无论怎么配最大值都只能是15。这就解释了为什么“对象熬过15次Minor GC后会进入老年代”。不是JVM故意设置15这个看起来很整的数字而是对象头结构里只分配了4个bit给年龄字段物理上限决定了它只能是15。如果你硬配置-XX:MaxTenuringThreshold20JVM会忽略这个值日志里仍然显示max15。年龄从1开始计算。对象第一次从Eden区复制到Survivor区时年龄被置为1之后每躲过一次Minor GC就加1。当年龄大于MaxTenuringThreshold时下一次Minor GC过程中直接从Survivor区晋升到老年代。-XX:MaxTenuringThreshold15 # 默认值Parallel和G1 -XX:MaxTenuringThreshold6 # CMS收集器默认值这里有个很实用的调试技巧如果想把所有对象在第一次Minor GC后立刻晋升可以把MaxTenuringThreshold设成0。这个参数常用于测试环境验证晋升行为也可以配合某些“不想让对象留在Survivor里”的场景。2.3 为什么CMS的默认阈值只有6既然物理上限是15为什么CMS把默认阈值调成6这个问题的本质是对象在新生代“熬”的次数越多复制成本越高。每一次Minor GC存活对象都要被复制一次。一个对象如果能活到15岁意味着它至少被复制了15次。CMS收集器更关注低延迟如果大量对象在Survivor区里反复横跳Minor GC的复制开销会直接反映在停顿时间上。把阈值调低到6对象熬个6次就晋升老年代Survivor区里的“存货”减少后续Minor GC的复制量自然下降。但这里有个代价对象进老年代变早了。老年代GCCMS的Concurrent Mark Sweep回收频率会比默认15时高一些。所以在CMS场景下6是“减少Minor GC复制成本”和“避免老年代GC过于频繁”这两者之间的经验平衡点而不是什么严格的理论推导。理解年龄计数的逻辑后你会发现一个关键点真正走到“年龄到了15才晋升”的对象往往都是业务里确确实实需要长期存活的对