JVM 调优这件事我做了快十年线上问题排查了大半个职业生涯最常被问到的、也是面试官最爱考的一个点就是对象到底什么时候从新生代跑到老年代。很多人背了“年龄到 15 就晋升”这句话就觉得自己会了结果一线上排查GC 日志里全是意外对象十几岁还在 Survivor 里赖着不走或者才一岁就被动态判定直接踢进老年代老年代占用率像坐了火箭一样往上蹿Full GC 一顿一顿地卡业务。这个知识点看起来就是个名词解释但实际上它背后藏着 JVM 分代回收设计的全部心思也是你配置堆参数、排查内存问题的基本功。这篇东西我按照实战经验来写从对象分配链路讲起把四个晋升时机年龄阈值、动态年龄判定、大对象直入、分配担保逐个掰开揉碎再带上我实际排查过的 GC 日志和问题案例最后给出一套可以直接抄走的参数配置和排查工具清单。适合正在做 Java 后端开发、准备 JVM 面试、以及被线上 Full GC 困扰得睡不着觉的运维同学。1. 先把对象的一生捋清楚从分配开始说起1.1 对象分配的完整链路想要搞清楚晋升时机得先明白对象一出生会经历什么。一个普通 Java 对象new 出来之后并不是直接走进堆内存随便找个地方住下的它要先过三关栈上分配尝试、TLAB 分配、Eden 区分配。先说栈上分配。JVM 做逃逸分析的时候如果发现一个对象不会被方法外部引用那它就直接在栈帧里分配内存方法执行完栈帧弹出对象也跟着销毁压根不进堆。这是最理想的情况省掉了 GC 的全部成本。实际场景里短生命周期的小对象最容易满足这个条件这也是 JIT 编译器为性能做的优化之一。如果逃逸分析没通过对象就会去堆上找地方。这里还有个小加速机制叫 TLAB全称 Thread Local Allocation Buffer也就是线程本地分配缓冲区。因为 Eden 区是多个线程共享的如果所有线程都直接往 Eden 里塞对象那必然要加锁控制并发性能就崩了。所以 JVM 给每个线程在 Eden 里划了一块私有区域线程先在自己的 TLAB 里分配对象满了或者对象太大装不下才去 Eden 公共区域申请。这块缓冲区的大小默认是 Eden 的 1%可以通过-XX:TLABSize调整。最后绝大多数普通对象会被放进 Eden 区。Eden 区是什么概念就是新生代里最热闹的地方所有新对象先在这待着然后绝大部分对象IBM 做过统计约 98%在这活不过第一次垃圾回收就成了垃圾也就是俗称的“朝生夕灭”。只有极少数对象在 Minor GC 之后存活下来被复制到 Survivor 区。1.2 为什么要把对象分代管理分代回收不是 JVM 拍脑袋想出来的核心原因只有一个绝大多数对象活不长。如果所有对象都堆在一起做 GC每次都得扫描整堆那停顿时间根本压不住。所以 JVM 把堆分成新生代和老年代新生代里尽量放大批短命对象用复制算法快速清理老年代放长命对象用标记整理或标记清除降低频率。这里有个很形象的类比新生代就像商场里的快餐区人流密集但停留时间短一拨人吃完马上翻台老年代像小区里的长期住户住下了就不太搬家管理起来不用那么频繁。对象从快餐区搬到居民区这个过程就是晋升。搞明白晋升的时机其实就是搞明白 JVM 在什么情况下会把这个对象从“短命区”挪到“长命区”这直接决定老年代的增长速度也决定 Full GC 会不会频繁降临。2. 对象进入老年代的四个核心时机2.1 年龄计数器到点熬过 Minor GC 的“十五朝元老”先讲最广为人知的机制年龄计数器。对象在 Survivor 区每熬过一次 Minor GC年龄就加一岁。这个年龄字段存储在哪存在对象头 Mark Word 里的 4 个 bit 位所以理论上年龄上限就是 152 的 4 次方减 1。当年龄达到-XX:MaxTenuringThreshold设定的阈值时对象就会进入老年代。默认值是多少不同收集器不一样HotSpot 默认是 15但 CMS 的默认值是 6G1 的默认值也是 15注意有些版本实际生效值会被动态调整。这里有个细节很多人搞错对象不是从 Eden 进 Survivor 的那一瞬间就算一岁的而是第一次熬过 Minor GC、从 Eden 被复制到 Survivor 时年龄 1。之后每在 Survivor 里挺过一轮 Minor GC年龄再 1。举个例子一个对象第一次 Minor GC 存活年龄变成 1第二次 Minor GC 又存活年龄变成 2到了第 15 次 Minor GC 还活着年龄就达到 15下一次 Minor GC 时它就会被晋升到老年代。对于这个机制我要多说一句MaxTenuringThreshold 并不是设得越大越好。设大了对象在 Survivor 区里来回复制浪费复制带宽Survivor 空间也可能被长期存活对象占满设小了对象过早晋升到老年代老年代压力变大Full GC 频率上升。这个阈值到底怎么定得看业务对象的存活曲线这个我在后面调优章节会详细说。2.2 动态年龄判定最容易被忽略的“群体晋升”规则如果只有年龄到点才晋升Survivor 区可能会被大量“岁数不大但赖着不走”的对象占满导致新存活下来的对象没地方放Minor GC 频繁。所以 HotSpot 还有一个动态年龄判定机制。规则是这样的在 Minor GC 结束时JVM 会统计 Survivor 区里每个年龄对应的对象大小总和如果发现某个年龄 N 及其以上年龄的对象总大小超过 Survivor 区的一半就把年龄大于等于 N 的对象全部晋升到老年代晋升阈值取 N 和 MaxTenuringThreshold 的较小值。我举个例子你就能明白假设 Survivor 区是 100MBMaxTenuringThreshold 设置的是 15。Minor GC 结束后统计发现年龄为 1 的对象占了 60MB超过了一半那么所有年龄 1 的对象也就是该 Survivor 里几乎所有存活对象这次全部晋升。反之如果年龄为 1 的对象只有 10MB年龄为 2 的对象有 30MB两个加起来不到一半那就不触发动态晋升继续等年龄到点。这里有一个容易被误解的点动态年龄判定不是每次 Minor GC 都会触发它只看年龄对应的对象总大小不看单个对象的大小。而且这个“一半”不是硬编码的它跟-XX:TargetSurvivorRatio参数有关默认值是 50%也就是说 JVM 期望 Minor GC 之后 Survivor 区的占用率是 50%。实际实现里JVM 会计算一个目标存活年龄targetAge让晋升后 Survivor 占用不超过 50%如果当前累计存活对象大小已经超过希望值就触发晋升。这也是为什么很多情况下对象没到 15 岁就被晋升了完全正常。2.3 大对象直接空降PretenureSizeThreshold 这道门第三种时机是大对象直接进入老年代。设定阈值-XX:PretenureSizeThreshold当对象大小超过这个值时直接在老年代分配不走 Eden 区和 Survivor 区。为什么这么设计因为大对象在新生代的 Eden 和 Survivor 之间来回复制复制开销巨大而且一个大对象大概率会把 Survivor 区空间撑爆导致动态年龄瞬间判定、一大批对象被晋升反而打乱节奏。所以 JVM 干脆把超过阈值的大对象直接扔进老年代用老年代的大空间和低频 GC 来消化它。这里必须给大家提个醒这个参数只对 Serial 和 ParNew 收集器生效Parallel Scavenge 收集器不认它G1 更不认。G1 里大对象的判定是看 Region 大小超过 Region 容量 50% 的对象会被放到 Humongous 区域而且 Humongous 区域在老年代和新生代之间不是严格意义上的老年代对象分配需要单独注意。阈值设多大常见经验值是 1MB 到 4MB。如果设得太大大对象还是在新生代里来回折腾设得太小老年代里堆满了短命的大对象Full GC 会更频繁反而得不偿失。我见过有人图省事直接设 1MB结果大量 1MB 左右的小数组对象全进老年代老年代很快被打满线上 Full GC 频率从原来的一天几次干到一小时几十次。所以这个参数设置前一定要先摸清业务里对象大小的分布最好通过 JFR 或者堆转储分析做一轮统计再下结论。2.4 分配担保机制Survivor 装不下的兜底方案第四个晋升时机是分配担保机制引发的“被迫晋升”。这个机制很多人只听过名字不知道它实际怎么运作。Minor GC 开始前JVM 要先做一次风险评估如果这次 GC 之后新生代里存活对象要晋升到老年代老年代空间够不够放具体判断逻辑是先看老年代最大可用连续空间是否 新生代所有对象的总大小。如果是说明这次 Minor GC 是安全的可以放心执行。如果否就要检查老年代可用连续空间是否 历次晋升到老年代对象的平均大小。如果大于等于说明虽然有点风险但大概率能装下于是冒险执行 Minor GC如果连平均晋升大小都不满足那就直接升级成 Full GC把整个堆都清理一遍来腾空间。这里有个历史遗留问题JDK 6 Update 24 之前分配担保是否冒险还受-XX:HandlePromotionFailure参数控制但从 6u24 之后这个参数就被废弃了规则固定为只要老年代连续空间大于新生代对象总大小或历次晋升平均大小就尝试 Minor GC否则改为 Full GC。网上很多老博客还在让人设置 HandlePromotionFailure已经过时了别被误导。分配担保其实是在说一件事Minor GC 不是想当然就能做的它本质上依赖老年代做“接盘侠”。如果老年代空间不足还硬做 Minor GC结果就是 Minor GC 结束后晋升对象塞不进去立刻触发一次 Full GC停顿时间成倍增长。所以老年代的大小和剩余空间直接影响着新生代回收的决策。3. 实操5 分钟学会用 GC 日志和 jstat 定位晋升异常3.1 用 jstat 看对象晋升的实时情况理论说完了来点能直接上手的。排查线上问题时我第一个用的工具永远是jstat这是 JDK 自带的轻量级监控工具对性能影响极小线上可以直接跑。最常用的命令是jstat -gcutil pid 1000这个命令每秒打印一次 GC 统计信息。重点关注几个列S0、S1是两块 Survivor 区的使用率E是 Eden 使用率O是老年代使用率YGC和FGC是 Minor GC 和 Full GC 的次数FGCT是 Full GC 累计停顿时间。看晋升异常的核心思路是什么记住一个判断指标如果YGC次数增长很快同时O老年代使用率也在稳步爬升每做几次 Minor GC老年代就涨一截那说明有大量对象在晋升。这时候你就要去分析到底是谁在晋升是动态年龄判定的问题还是对象本身年龄到点了还是大对象阈值设置不合理。jstat只能给你表象数据它不会告诉你具体哪个对象在晋升但你至少能确定方向。如果FGC次数也上来了且FGCT时间很长那基本就是老年代被打满后的 Full GC 连锁反应。这时候再用jmap -histo:live pid看老年代里哪些对象占大头进一步缩小排查范围。3.2 从 GC 日志里读出晋升细节jstat看的是现状GC 日志看的是过程和原因。强烈建议所有线上 Java 服务开启 GC 日志成本极低排查问题时价值不可估量。JDK 8 及之前版本通常这么配置-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintTenuringDistribution -Xloggc:/path/to/gc.logJDK 9 及以后日志系统统一了配置方式变成-Xlog:gc*:file/path/to/gc.log:time,uptime,level,tags关键在哪里就是PrintTenuringDistribution这个参数它会在每次 Minor GC 后打印 Survivor 区里各个年龄对象的分布情况。日志里会出现类似这样的内容Desired survivor size 52428800 bytes, new threshold 10 (max 15) - age 1: 2048000 bytes, 2048000 total - age 2: 1024000 bytes, 3072000 total - age 3: 8192000 bytes, 11264000 total ...这段日志信息量非常大Desired survivor size表示 JVM 期望 Minor GC 后 Survivor 的存活对象总大小new threshold表示经过动态年龄计算后本次 GC 使用的晋升阈值这里算出来是 10而 max 是 15。下面每一行是各年龄对象的占用和累计值。怎么判断是否异常两条经验法则第一如果new threshold常年远低于max说明动态年龄判定经常被触发对象被迫提前晋升你需要看看 Survivor 区是不是太小了或者TargetSurvivorRatio是不是偏激进。第二如果age 1的对象就占据了绝对大头超过了Desired survivor size那这波存活对象大概率是业务上批量创建的中间对象短命但量大晋升老年代后很快就变成垃圾反而增加了老年代的 GC 压力。3.3 Tomcat 启动参数配置里的晋升相关项很多人部署 Java Web 应用用的是 Tomcat启动参数在catalina.sh或setenv.sh里配置 JAVA_OPTS。我刚工作那几年最常干的事就是给 Tomcat 调 JVM 参数现在给你一套基于晋升机制理解的合理配置模板JDK 8 默认 Parallel 收集器JAVA_OPTS-Xms4g -Xmx4g -Xmn1536m -XX:SurvivorRatio8 -XX:MaxTenuringThreshold6 -XX:TargetSurvivorRatio50 -XX:UseConcMarkSweepGC -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintTenuringDistribution -Xloggc:/opt/tomcat/logs/gc.log展开说一下各参数的含义和取舍-Xms4g -Xmx4g把堆大小固定为 4G避免动态扩容带来的性能抖动和 Full GC。-Xmn1536m把新生代设为 1.5G老年代就是 2.5G。-SurvivorRatio8意味着 Eden : From : To 8 : 1 : 1Eden 有 1.2G每块 Survivor 150M。-XX:MaxTenuringThreshold6是因为使用了 CMS 收集器CMS 默认阈值就是 6这也是对象晋升的兜底线。TargetSurvivorRatio50保持默认意思是希望 GC 后 Survivor 占用率不超过 50%。这套配置的关键逻辑是什么150M 的 Survivor 空间要能容纳高峰期 Minor GC 后存活对象的大小如果每次 Minor GC 后存活对象只有几十兆那动态年龄判定基本不会被频繁触发对象的晋升节奏就完全是年龄阈值在控制可控性极强。如果业务高峰期存活对象超过 150M动态年龄判定会立刻接管大批对象提前晋升。这时候你需要把 Survivor 调大也就是调大新生代或者调整 SurvivorRatio而不是去死磕 MaxTenuringThreshold。4. 对象晋升异常的几个典型场景与排查实录4.1 场景一Survivor 太小对象全员提前晋升有一年线上订单服务 Full GC 频率异常从每天两三次变成每半小时一次。我先用jstat -gcutil pid 1000看了一眼YGC 频率很高每次 Minor GC 后老年代使用率O都会涨 1% 左右FGC 次数持续增长。然后翻了 GC 日志里的年龄分布发现每次 Minor GC 后age 1 的对象就占到了 Survivor 区的 80% 以上触发了动态年龄判定new threshold直接被算成了 1。也就是说几乎所有熬过第一次 Minor GC 的对象第二次 Minor GC 就集体晋升老年代。这些对象其实大多很快就能被回收但因为没有 Survivor 空间容纳它们被迫在做客老年代等 Full GC 才能清理老年代占用当然只升不降。问题的根因就一个Survivor 区容量太小。我当时的修法是调大新生代同时把SurvivorRatio从默认的 8 改到 4让每块 Survivor 大小从原来的几十兆涨到两百多兆然后动态年龄判定不再触发大量对象安安心心待在 Survivor 里等年龄到点。改完观察两天FGC 次数归零。这里分享一个排查结论看到new threshold频繁变成 1 或者 2十有八九是 Survivor 空间不足优先加大 Survivor而不是去调大 MaxTenuringThreshold——阈值调得再大动态年龄判定照样能把对象赶去老年代。4.2 场景二大对象阈值设置激进老年代被短命对象填满另一个经典案例同事把-XX:PretenureSizeThreshold设成了 512KB目的是不想让大对象在新生代来回复制。结果线上的老年代占用率肉眼可见地飙升Full GC 频繁。原因分析这个服务里大量存活时间不超过几秒的 JSON 序列化缓冲对象大小都在 512KB 到 1MB 之间。阈值 512KB 直接把这些短命但稍大的对象全部送进了老年代它们本来应该死在新生代的结果全跑到老年代占坑最后只能靠 Full GC 清扫。这事的教训非常直接大对象直接进老年代这个策略只适合“大而长命”的对象比如缓存对象、连接池对象。如果大对象是短命的那这参数就是引狼入室。后来我把阈值调到了 2MB低于这个值的对象继续走新生代高于这个值的对象才是真正的长命大对象Full GC 频率立刻降下来了。4.3 场景三分配担保失败Minor GC 秒变 Full GC还有一种不太常见但极其隐蔽的情况明明新生代空间充足GC 日志里却频繁出现 Full GC。我排查过的一个案例日志里先是连续的 Minor GC紧接着就出现 Full GC而且老年代占用其实不高但每次 Full GC 后老年代可用空间反而更小了。这个问题的根因是连续空间碎片化。老年代用的是标记清除算法如果老年代里的大对象分布不连续最大可用连续空间很小Minor GC 前的分配担保判断就会觉得“老年代装不下晋升对象”于是放弃 Minor GC 直接做 Full GC。Full GC 做了压缩整理后把碎片凑成整块才敢继续做 Minor GC。这种场景最常见的解法有两个一个是切换到 G1 收集器用 Region 和可预测的停顿模型来解决碎片化问题另一个是用 CMS 时开启-XX:UseCMSCompactAtFullCollection和-XX:CMSFullGCsBeforeCompaction注意这些参数在新版本 JDK 中已默认或被移除。如果你是 JDK 8 上用 CMS可以考虑在 Full GC 前做一次压缩整理减少碎片。4.4 配套工具链内存泄露排查里怎么结合晋升分析文章开头提到热词里有“jvm内存泄露查看工具”这里我一起说透。当发现老年代持续增长、FGC 频繁时需要判断两个方向是对象晋升过多过快属于分配结构问题还是老年代里的对象真的泄露了属于长存对象问题。工具配合三步走第一步jstat -gcutil pid确定 GC 频率和老年代增长率锁定问题方向。第二步jmap -histo:live pid | head -20看看老年代里哪个类对象占内存最多。如果排在最前面的是大量byte[]、char[]、String大概率是业务代码里缓存了不该缓存的数据比如把批处理中间结果塞进了静态集合。这时候配合 MATMemory Analyzer Tool或者 JProfiler 做堆转储分析查 GC Roots 引用链找出谁在持有这些对象。第三步结合 GC 日志里的 Tenuring Distribution 做交叉判断。如果发现 age 小的对象在晋升后大量成年老年代占用那说明淘汰策略有问题如果晋升的是 age 已经很高的对象且长期不释放那才是真正的内存泄漏洞。不要把这两者混为一谈我见过很多人一看到老年代涨就说内存泄露结果调了半天参数没用最后发现是一批永不释放的缓存对象该改代码的跑去调参数纯属南辕北辙。5. 相关参数速查与调优避坑指南5.1 晋升相关参数一览表把文章里涉及到的参数整理成一张速查表方便大家收藏对照参数作用默认值注意事项-XX:MaxTenuringThreshold对象年龄晋升阈值上限15CMS 默认 6最大不能超过 15因为对象头年龄字段只有 4 bit-XX:TargetSurvivorRatio期望 Minor GC 后 Survivor 占用率50与动态年龄判定直接相关值越小晋升越激进-XX:SurvivorRatioEden 与 Survivor 的比例8值越大 Eden 越大Survivor 越小要配合存活对象量级设置-XX:PretenureSizeThreshold大对象直接进老年代的阈值0不启用仅对 Serial 和 ParNew 生效Parallel 和 G1 无效-XX:PrintTenuringDistributionGC 日志打印各年龄对象分布关闭强烈建议开启是分析晋升的钥匙5.2 调优顺序和思路很多人调 JVM 参数喜欢东一榔头西一棒子今天我给大家一个我实测多年比较靠谱的调优顺序第一步先抓 GC 日志至少线上跑一天拿到基线数据。看 YGC 频率、FGC 频率、停顿时间这是判断问题的起点。第二步分析晋升是否健康。看 Tenuring Distribution 日志确认new threshold是否频繁变动age 1 的对象是否大量挤占 Survivor以及晋升对象最终去向。第三步优先调整内存布局而不是急着调晋升阈值。也就是说先确认堆大小、新生代大小、SurvivorRatio 是否匹配业务存活对象的量级。很多晋升问题是空间不够挤出来的不是你阈值设错了。第四步最后才是微调晋升策略调MaxTenuringThreshold、TargetSurvivorRatio。这时候每改一个参数要单独观察一次只改一个改完至少跑半天以上不要上午改下午就下结论。说一个我个人的经验改参数之前先留好 GC 日志基线改完对比 YGC 和 FGC 的次数以及停顿时间的 p99而不是看平均时间。平均会掩盖长停顿的问题。5.3 最后分享一个计算 Survivor 空间的小技巧很多人不知道 Survivor 到底该设多大我给个实际可操作的估算方法在高峰期用 jstat 观察连续两次 Minor GC 之间 Survivor 的峰值占用然后把这个峰值乘以 2 到 3作为 Survivor 的目标大小。为什么乘以 2 到 3因为 Minor GC 时 From 和 To 两块 Survivor 会互相交换你要保证高峰期存活的对象放得下同时还有余量容纳下一轮 Minor GC 存活下来的对象。举个例子业务高峰时 jstat 显示 Survivor 峰值占用 80MB那每块 Survivor 设计为 160MB 到 240MB 比较稳妥。然后反推堆结构如果 SurvivorRatio 想保持 8那 Eden 8 * 200MB 1.6GB新生代 Eden 2 * Survivor 2GB再根据老年代的需求确定总堆大小。这样算出来的参数是有业务数据支撑的而不是拍脑袋随便填的。对象进入老年代的时机说白了就是这四个机制的综合作用。你光记住“15 岁晋升”是没用的线上表现才是唯一的裁判。每次看到 GC 日志里的new threshold都要多想一步这个值是动态判定算出来的还是年龄到点顶上去的如果是前者Survivor 是不是该加了如果是后者对象是不是真的该熬这么久了。想明白这个JVM 内存调优你就已经出师了一半。