最近好几个做后端的朋友不约而同来问同一个问题内存xmn的设置到底怎么搞。扒开一问他们问的基本都是JVM的-Xmn参数也就是堆内存里新生代Young Generation这一块容量怎么定。这个参数看起来简单展开之后其实牵扯到Minor GC频率、Survivor空间水位、对象晋升速率、老年代压力甚至Full GC触发间隔一环扣一环。网上搜一圈答案要么是“设成堆大小的一半”要么是“不设也行默认挺好的”这两种说法我都觉得有点粗糙。新生代给太小对象频繁触发Minor GC青年对象不断被扫描复制CPU白耗新生代给太大老年代被压缩长期存活的对象稍微一多老年代就满了Full GC直接教做人。这篇文章我就把-Xmn的原理、估算路径、线上翻车场景和验证方法完整梳理一遍适合刚接触JVM调优的人也适合已经在看GC日志但不敢乱动参数的人。1. 先别急着抄参数-Xmn到底管的是哪块内存1.1 JVM堆内存里的“三驾马车”Java运行时的堆内存绝大部分人都知道用-Xms和-Xmx能限制初始堆大小和最大堆大小。因为两个参数长得像一对儿很多人就以为堆内存的配置到此为止。实际上在绝大多数垃圾回收器组合下堆里还横着一条分界线一边是新生代一边是老年代。新生代就是-Xmn管的地盘。这里补充一个很基础但经常被忽略的点堆内存并不等于新生代加老年代这两块在JDK8之后元空间Metaspace已经挪到了本地内存不再占用堆空间所以实际业务里说的堆调优核心还是在新生代和老年代之间做平衡。新生代内部又被分成三块一个Eden区和两个Survivor区通常叫S0和S1或者From和To。结构上可以理解成堆内存 新生代-Xmn 老年代默认剩下的堆空间 新生代 Eden S0 S1-Xmn设定的值是整个新生代的总容量不是单指Eden区。默认情况下Eden区占绝大部分两个Survivor区各占一小部分这个比例由-XX:SurvivorRatio控制默认值是8意思是Eden区和单个Survivor区的比例是8:1所以新生代内部就是Eden占80%S0和S1各占10%。1.2 为什么新生代值得单独拉出来设置如果完全不设置-XmnJVM不是不能跑而是会走一套自动策略。比如使用Parallel GC时JVM默认让新生代和老年代的比例跟随-XX:NewRatio走默认NewRatio2也就是老年代占2份、新生代占1份新生代约等于整个堆的1/3。那为什么还要手动设置-Xmn因为这块区域的大小直接决定了短期对象在内存里“周转”的速度。大多数业务系统里的对象都是朝生夕死的一个请求进来了从parse参数到组装返回值中间能产生几十上百个临时对象这些对象活不过几秒就要被回收。如果Eden区足够宽它们可以一直在新生代里产生、被回收、再产生、再回收始终不污染老年代如果Eden区太窄还没来得及被Minor GC清理对象就满出来了被挤压到老年代。老年代里堆一大堆短命鬼结果就是老年代很快满了触发Full GCSTW时间变得难看。用生活里的场景类比新生代像餐厅后厨的备菜台备菜台够大切出来没用的边角料可以快速扔进垃圾桶Minor GC不会影响到储藏室备菜台太小备好的菜没处放只能往储藏室塞储藏室一满整家店都要停下来大扫除一次。所以-Xmn单独设置本质上是给短期对象划定一块“隔离缓冲区”让它们在该消失的地方消失不要跑到老年代里去添乱。2. 对象从生到死的过程决定了-Xmn调大调小的所有后果2.1 一次Minor GC新生代内部发生了什么要理解-Xmn调大调小的后果得先把对象在新生代里的完整旅程走一遍。新对象基本都在Eden区分配少数超大对象会直接进老年代这个后面专门说。随着Eden区对象越积越多空间不够了JVM就会触发一次Minor GC。Minor GC发生时垃圾回收器标记Eden区和当前正在使用的那个Survivor区里的存活对象把这些存活对象复制到另一块空的Survivor区。复制一次对象的年龄加一默认年龄涨到15可通过-XX:MaxTenuringThreshold调整就会晋升到老年代。看着很简单但有个关键机制Minor GC只处理新生代不会去扫老年代。这意味着Minor GC的停顿时间主要取决于新生代里到底有多少存活对象要复制而不是新生代里总共有多少垃圾。垃圾越多反而清理得越快因为垃圾不需要复制。这就能解释为什么-Xmn不是越大越好。新生代扩大到2倍Eden区确实更宽Minor GC频率确实会下降但如果每次GC时存活对象比较多比如一批长生命周期对象恰好堆积在新生代里那活对象复制的总量也会变大单次Minor GC的停顿时间可能不降反升。2.2 -Xmn和-Xmx、-XX:NewRatio之间谁说了算这里有一个非常容易被绕晕的优先级问题同时设置了-Xmx和-Xmn并配置了-XX:NewRatio时谁生效结论是-Xmn优先。-Xmn这个参数等价于同时设置了-XX:NewSize和-XX:MaxNewSize并让它们保持一致属于显式指定。一旦显式指定了新生代的初始值和最大值-XX:NewRatio的自动比例调节就会在这个固定区间上失效。所以说如果你准备用-Xmn就别再去纠结-XX:NewRatio它俩在逻辑上是互斥的两种策略。举个例子java -Xms2g -Xmx2g -Xmn1g -XX:NewRatio2 -jar app.jar这种写法里-Xmn1g生效新生代固定1g老年代1g。-XX:NewRatio2不会再去把新生代调成堆的1/3。很多人在生产环境把这几个参数混在一起堆最后看监控数据发现新生代根本不是预想的那个值才想起来参数之间有优先级。2.3 为什么“新生代越大越好”是个伪命题把新生代撑得很大最直接的隐患是老年代被压缩得太小。假设总堆固定4g-Xmn从1g调到2.5g老年代就只剩下1.5g。如果一个服务里有比较多需要长期缓存或者长时间存活的对象比如定时任务里的状态对象、连接池里的底层对象、业务上跨会话的数据这些对象在老年代里慢慢积累1.5g老年代很容易就被撑爆。最后的结果就是Minor GC频率确实降下来了但老年代频繁触发Full GC每次Full GC都要扫描整个堆加清理压缩停顿直接飙到几百毫秒甚至几秒。对这种服务来说调大-Xmn等于拆东墙补西墙。我之前见过一个典型场景一个数据上报服务把-Xmn调到了总堆的70%Minor GC确实不怎么打了但老年代每十来分钟就满一次Full GC日志刷得很频繁。后来把-Xmn降回总堆的40%让老年代宽松一点Full GC间隔才拉长到小时级别。所以理性的做法是把-Xmn当作一个和业务对象生命周期强相关的旋钮而不是一个“越大越爽”的优化项。3. 给新生代定一个靠谱的初始值可落地的估算方法3.1 先量两个数对象分配速率和YGC间隔与其照搬别人的“标准答案”不如先用自己的服务量两个关键数字。这两个数字可以从jstat里拿。假设服务跑在Linux上先用jps找到JVM进程ID然后执行jstat -gcutil pid 1000 10能看到类似这样的输出S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 12.50 13.20 45.30 67.80 82.10 78.50 3856 12.345 8 0.678 13.023这里重点看三列EEden区当前使用率百分比YGCMinor GC发生次数YGCTMinor GC累计耗时。连续多采集几次再配合JVM启动时间可以算出平均YGC间隔。比如服务运行了2小时YGC次数是3856次那么平均每次YGC之间的间隔大概是7200秒除以3856约等于1.87秒一次。这个频率如果发生在高并发服务上还算常见但如果是一个平时流量不算大的服务1.87秒一次Minor GC就明显偏频。再观察Eden区从低位到触发GC的上涨速度就能估算出对象分配速率。举个例子假设两次YGC间隔是30秒Eden区这期间从10%涨到了95%Eden区最大容量是800m那么30秒内Eden区涨了约680m平均每秒分配约22.6m对象。3.2 用公式推Eden大小再反推-Xmn有了分配速率和目标YGC间隔就能根据一个很朴素的公式来估算新生代容量期望Eden区大小 ≈ 对象分配速率 × 期望YGC间隔 × 1.2~1.5余量系数这个余量系数是为了应对流量高峰避免因为一点波动就频繁触发GC。继续用上面的数字举例每秒分配约22.6m目标YGC间隔在60秒左右那Eden区至少要有约1356m。考虑到Eden只占整个新生代的80%SurvivorRatio8时反推-Xmn大概是1356除以0.8取整约1700m。落到实际配置里可以直接用2gjava -Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio8 -jar app.jar注意这一步只能算出“把YGC频率压到可接受范围”的下限。真实生产环境还需要把Survivor区的承接能力也考虑进来否则对象会在Survivor区溢出从另一条路径提前进入老年代这部分我在第4节重点讲。3.3 给常见场景一个可以当起点的参考表参数没有万能解但可以给一个“能从这开始试”的参考表。下面这些数值是我在实际调整中整理出来的不是标准答案适合作为第一组观察数据服务类型总堆参考新生代参考核心考量高并发无状态API/网关类4g1.5g~2g请求对象短期存活Eden要宽Survivor要能接住瞬间流量波动常规业务服务订单、用户中心等8g2g~3g新生代约占堆的1/3左右比较均衡老年代留足空间批处理、离线任务类8g2g左右部分中间结果生命周期长老年代容量需要优先保障新生代占1/4到1/3更稳缓存型服务 / 大对象居多8g1.5g左右长生命周期对象占比高新生代别贪大老年代才决定生死记住一个总原则第一组参数只是用来观察的不是用来直接上生产的。调整一次后至少跑24到48小时收集完GC日志再决定下一步怎么改。4. 线上调-Xmn最容易翻车的三类场景4.1 只设-Xmn没设-Xms堆扩容把计划全打乱很多应用原生配置就有-Xmx比较大但-Xms比较小的情况。比如-Xms512m -Xmx4gJVM启动时堆只有512m。这时候就算你设置了-Xmn1g也不会生效到“启动阶段”因为实际堆空间都还没有扩到这么多。在堆从512m逐步扩容到4g的过程中新生代会跟着堆的扩展不断调整-Xmn的固定值必须等堆空间超过新生代设定值后才能体现出来。这就导致启动初期GC行为看起来很奇怪YGC频繁Eden区使用率跳来跳去甚至出现了“为什么设置了Xmn但和没设一样”的错觉。解决方式非常粗暴线上服务如果允许把-Xms和-Xmx设成一致一次性把堆定型不让JVM在扩容上折腾。JVM扩堆和缩堆都要触发堆布局变更这个开销在业务高峰期非常不划算。java -Xms4g -Xmx4g -Xmn2g -XX:SurvivorRatio8 -jar app.jar尤其对延时敏感的服务我建议一律-Xms-Xmx让JVM启动时就把堆申请到位把扩容这种不确定因素彻底从参数组合里移除。4.2 Survivor区太小对象提前晋升老年代这是最隐蔽的一种翻车。表面上看YGC次数正常Eden使用率也健康但老年代占用率一直在缓慢爬坡每过一两个小时不得不来一次Full GC。很多人第一反应是“老年代太小”然后调大总堆结果没啥改善其实问题出在Survivor区。Survivor区的能力是有上限的。默认SurvivorRatio8时-Xmn2g意味着每个Survivor区只有200m。如果一次Minor GC触发时需要复制的存活对象超过了200m放不下的那部分对象就会直接晋升到老年代而不经过正常的年龄阈值判断。要定位这个问题GC日志里看几个数字Desired survivor size期望存活区大小、Actual survivor size实际存活区大小、allocation failure。如果日志反复出现存活对象大于Survivor容量的情况就要考虑三条路适当调大-Xmn让Survivor区跟着变大调大SurvivorRatio比如从8改成6让Survivor区在新生代里占更高比例把动态年龄判定关掉强制对象在Survivor区里至少周转几轮再晋升。第三种做法要谨慎我一般不推荐直接上除非已经确认某些长周期对象正在借助动态年龄判断快速溜进老年代。4.3 大对象根本不走新生代白调-Xmn还有一种更让人无语的情况你辛辛苦苦调完-XmnGC频率纹丝不动。这时候要想想业务里是不是有大量大对象。JVM里超过阈值的大对象会直接进入老年代这个阈值由-XX:PretenureSizeThreshold控制仅对Serial和ParNew等部分收集器生效Parallel GC默认不启用但可以用其他方式规避。另外超过TLAB大小的对象不会在TLAB里分配而是直接在Eden区分配某些特别大的对象也有绕过新生代直接进老年代的可能。比如一个服务每次请求都会构造一个几MB的报文对象这种对象基本不会在新生代里周转你依赖-Xmn去压YGC频率等于在用错工具。先去看GC日志里老年代分配和晋升的来源再决定是不是要调整对象分配策略比盲目加大新生代更有效。5. 改完参数不叫完事用GC日志和jstat做验证5.1 加上最小成本的GC日志调优和看病一样没有日志等于没有检验报告。不管用哪个收集器第一步都是在JVM启动参数里把GC日志打开。JDK8及以前可以用这组参数-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.logJDK9之后推荐用统一日志体系-Xlog:gc*:file/data/logs/gc.log:time,uptime,level日志文件会产生额外写入开销但对定位问题来说这部分开销完全值得。线上服务可以配合日志轮转策略比如限制文件大小和保留份数不要让它无限制涨下去。拿到GC日志后先花时间看懂一次Minor GC那一行都说了什么新生代GC前容量、GC后容量、总堆容量、耗时。看得多了对新生代“真实水位”会有感觉比只看监控图靠谱得多。5.2 三个必盯指标和它的健康区间-Xmn改完之后建议连续观察这几个指标变化指标判断标准说明YGC平均间隔比调整前拉长拉长说明Eden区更宽对象能在新生代里周转更久Minor GC平均停顿不出现明显增长如果停顿时间大幅上升说明存活对象复制成本变高可能需要缩小新生代老年代占用增速没有加速上涨老年代爬坡速度变缓说明晋升速率可控加速了就要警惕Survivor溢出Full GC间隔拉长或持平如果Full GC更频繁说明老年代被挤压新生代调过头了这四个指标最好一起看任何单独一个变好都不是胜利。观察方法很简单跑一下jstat -gcutil pid 5000 120每5秒采样一次连续采集10分钟基本就能画出一个趋势。再配合jstat -gccause看最近一次GC的原因能快速判断GC是被“分配失败”触发还是被“老年代空间不足”触发。5.3 一次只改一个变量用灰度确认效果这是我说了很多次但依然有人不听的原则一次只改一个参数。把-Xmn从2g调到2.5g同时又把SurvivorRatio从8改成6还把-Xms从4g改成了6g全改完之后如果GC表现变好了你根本不知道是谁的功劳如果变差了你也不知道该回滚哪一个。正确的操作是先选一台低流量实例只改-Xmn一个参数发布后观察48小时。期间把YGC间隔、Minor GC耗时、晋升速率、老年代增量记录成表格。确认整体趋势变好再扩大到更多实例。如果发现异常把参数改回去只需要一行变更损失很小。6. 最后说几句大实话调了那么多次新生代大小我最深的一个感受是-Xmn本身不是调优终点它服务的真正目标是“控制晋升速率”。对象可以在新生代里多熬几轮但最终会不会大批量涌进老年代才是决定Full GC频次的关键。所以你盯Eden使用率的同时一定要盯Survivor区和老年代的增长趋势。还有一个经常被忽略的点很多中小型服务如果用Parallel GC默认NewRatio2下新生代就是堆的1/3本身就是一个经过大量场景验证的合理值。如果你没有明显的问题真不建议为了“调优”而调优。只有当你从GC日志或者监控里明确看到了短周期对象导致YGC过密、或者对象在Survivor区反复溢出时再动手设置-Xmn那才是这个参数的正确用武之地。真到了要改的时候记得留一份调整前后的GC日志把每次改动的参数个数控制在一个。内存调优从来不是比谁参数设得大而是比谁更知道自己业务里的对象是怎么死的。