企业官网建设流程全解析

1. 先看一次真实的晋升现场：老年代为什么突然变“热闹”

我最早对“对象何时进入老年代”这个问题产生强烈兴趣，不是因为面试题，而是因为一个线上事故。某个网关类服务，老年代GC原本两小时才触发一次，某天突然变成十分钟一次，老年代占用曲线像坐了电梯一样往上蹿。用GC日志和堆快照追了一圈，发现大量短命对象莫名其妙出现在老年代里——按业务逻辑来说，这些对象绝大部分应该在新生代就被回收掉，根本活不到老年代。

后来定位到根因，就是对象晋升的路径出了“意外”。这里得先把结论摆出来：Java对象进入老年代，远远不止“年龄到了15岁”这一条路。实际上，在HotSpot虚拟机里至少存在四条晋升通道，而很多线上老年代激增问题，恰恰是其中几条“非主流通道”在起作用。

这篇文章我会把这四条路全部拆开讲，每一路都配合参数配置、日志特征和实际表现。做JVM调优或者正准备Java面试的人，看完应该能建立起一套完整的判断体系，以后遇到老年代异常增长，至少知道该往哪个方向查。

2. 年龄计数器：一个对象从Eden到老年代的“熬资历”路径

2.1 新生代里对象的第一站：Eden区与Minor GC

绝大多数Java对象刚创建时，都分配在新生代的Eden区，这一步对应了热搜词里反复出现的“对象的创建”。Eden区本质是一块大内存池，新对象在这里分配时速度极快，因为它只做指针碰撞，不搞复杂的内存扫描。

Eden区满后触发Minor GC，垃圾回收器会把Eden区里还存活的对象复制到Survivor区的From（S0）中，同时清空Eden。注意这里用的是复制算法，不是标记清扫。下一次Minor GC时，把Eden区和From区里存活的对象再次复制到To（S1），然后交换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:MaxTenuringThreshold=20，JVM会忽略这个值，日志里仍然显示max=15。

年龄从1开始计算。对象第一次从Eden区复制到Survivor区时，年龄被置为1，之后每躲过一次Minor GC就加1。当年龄大于MaxTenuringThreshold时，下一次Minor GC过程中直接从Survivor区晋升到老年代。

-XX:MaxTenuringThreshold=15 # 默认值，Parallel和G1 -XX:MaxTenuringThreshold=6 # 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的复制量自然下降。

但这里有个代价：对象进老年代变早了。老年代GC（CMS的Concurrent Mark Sweep）回收频率会比默认15时高一些。所以在CMS场景下，6是“减少Minor GC复制成本”和“避免老年代GC过于频繁”这两者之间的经验平衡点，而不是什么严格的理论推导。

理解年龄计数的逻辑后，你会发现一个关键点：真正走到“年龄到了15才晋升”的对象，往往都是业务里确确实实需要长期存活的对