1. 先搞清楚-Xmn到底在管哪块内存很多人一上来就问-xmn怎么设置好像只要能填个数字就行。但如果你不清楚它在JVM内存布局里的确切位置填出来的数字往往不是太小就是太大运行一段时间就会出幺蛾子。所以我建议先花三分钟把堆内存结构过一遍再决定参数值。1.1 JVM堆内存里的“年轻人”和“老年人”JVM的堆内存Heap不是一整块平地它内部划分成了两个逻辑区域新生代Young Generation和老年代Old Generation。新生代又被进一步拆成三个小块Eden区、Survivor区一般有两个S0和S1。-Xmn这个参数控制的就是整个新生代的容量也就是Eden S0 S1三块区域加起来的最大值。这个值和堆总量之间没有绝对的百分比限制但通常我们会人为地让新生代占堆的三分之一到二分之一左右具体比例要看业务对象创建和存活的特征。为什么新生代要单独拎出来设置因为JVM在分配对象时有一条默认策略绝大多数对象先往新生代里放。新生代的特点是“来一批、死一批”存活时间很短的对象比如方法内部的临时变量、循环里的中间结果会在新生代里被频繁清理。JVM为新生代设计了专门的垃圾回收算法——复制算法虽然会浪费一部分空间但对“朝生夕灭”的对象来说效率极高。1.2 新生代为什么值得单独设置你可以把新生代想象成一家公司的“新员工区”老年代则是“骨干区”。新员工入职多、流动快经常被优化掉骨干员工经验多、留得久轻易不动他们。JVM在做垃圾回收时也是这个思路新生代优先频繁清理因为清理成本低老年代不轻易做Full GC因为成本高、停顿久。-Xmn的值决定了新生代能容纳多少对象也就直接影响了Minor GC新生代垃圾回收发生的频率。新生代设得太小几分钟就塞满一次Minor GC频繁触发虽然单次快但累积的停顿时间也很可观还容易导致部分本来可以存活下来的对象过早进入老年代。新生代设得太大Minor GC的次数会下降但每次回收时要复制和清理的区域也变大单次停顿时间变长甚至把老年代挤得太小搞不好直接引发Full GC那就得不偿失了。所以设置-Xmn本质上是找一个平衡点让Minor GC频率和单次GC停顿时间都处于可接受范围同时保证老年代有足够的空间容纳长期存活的对象。2. 怎么把-Xmn设成一个合理的值2.1 三条硬约束GC频率、停顿时间和晋升率我调过不少内存溢出的案例也踩过-Xmn设错的坑。总结下来合理设置-Xmn必须同时满足三个条件第一个条件是GC频率。如果日志里Minor GC每隔一两秒就来一次说明新生代太小了对象一进来很快就把Eden区塞满还没来得及被回收就被迫腾位置。这时候要么增大-Xmn要么从代码层面减少临时对象的创建。第二个条件是单次停顿时间。有些应用对延迟特别敏感比如在线交易、实时推荐哪怕STWStop The World只有几十毫秒在高峰期也会造成明显影响。新生代越大单次Minor GC需要处理和复制的对象越多停顿时间往往越长。这时候宁可让GC频率高一点也要把单次停顿压下去。第三个条件是晋升率。对象在新生代熬过若干次回收后会晋升到老年代。如果-Xmn太小很多对象在Survivor区里没熬到足够次数就被迫提前晋升老年代很快就满了紧接着就是Full GC。而Full GC一般比Minor GC慢一个数量级那才是真正的性能杀手。2.2 参考配比与实战参数组合从经验值来看新生代占堆总大小的三分之一到二分之一是比较稳妥的起步区间。举个例子如果堆大小-Xms和-Xmx是4GB那么-Xmn可以设置在1.5GB到2GB之间。但这里的“稳妥”不是万能公式还要看对象的存活率。我见过一个典型场景某服务大量创建中间对象但这些对象存活时间极短90%以上活不过第一次Minor GC。这种情况下-Xmn可以设得偏小比如只占堆的四分之一因为大部分对象很快就被清理了没必要占着堆空间等它们“寿终正寝”。反过来如果服务里有一些会话级别、请求级别的对象存活时间相对较长那新生代就得大一点让对象尽量在自己区域内被回收别往老年代推。还有一个实用组合把-Xmn和Survivor区比例参数一起调。默认情况下SurvivorRatio8也就是Eden占新生代的8/10两个Survivor各占1/10。我可以给你一个参考配置-Xms4096m -Xmx4096m -Xmn2048m -XX:SurvivorRatio6 -XX:UseG1GC这里SurvivorRatio6意味着Eden占比降低Survivor区相对变大适合那些有一定比例对象能存活几轮回收的负载。如果是G1收集器-Xmn的优先级要低于G1自己维护的年轻代比例但显式设置以后G1会优先参考这个值来初始化年轻代大小。2.3 区分几个容易混淆的参数不少人在配参数时把NewSize、MaxNewSize和-Xmn搞混。简单说NewSize是新生代初始大小MaxNewSize是新生代最大大小-Xmn则相当于同时把这两个值设成同一个数即“新生代固定为这么大”。如果你只设了NewSize而没有设置MaxNewSize那么新生代后续可能根据JVM的反馈自动扩容最终大小不确定不利于排查问题。所以我建议直接使用-Xmn来固定新生代让它在运行时保持不变简单可控。还有个参数叫NewRatio它定义的是老年代和新生代的比例。NewRatio2表示老年代是新生代的2倍相当于新生代占堆的三分之一。如果用了NewRatio再同时设置-Xmn两者会冲突JVM实际取值以-Xmn为准。调优时选定一套方案就好别混着用。3. 实操从查看默认值到调整-Xmn3.1 先摸清现状怎么确认当前新生代大小很多人在生产环境里没加参数之前根本不知道自己JVM的新生代有多大全靠“感觉”。其实有个很简单的命令就能看到运行时实际值java -XX:PrintFlagsFinal -version | grep -E NewSize|MaxNewSize|SurvivorRatio在JDK 8及以上版本你还能用jcmd pid VM.flags | grep -E NewSize|MaxNewSize|UseG1GC这里 替换成实际JVM进程编号。输出结果里能看到InitialHeapSize、MaxHeapSize、InitialNewSize、MaxNewSize、SurvivorRatio等参数。如果-XX:InitialNewSize和-XX:MaxNewSize不等说明新生代是动态伸缩的这时候显式加上-Xmn反而能减少JVM在运行时调整带来的不可控因素。我个人的工作习惯是拿到一个性能不达标的Java服务第一件事不是改业务代码而是先看GC日志和这些运行时参数。曾经遇到一个服务-Xmx设了8GB但是新生代因为没设置就一直只有几百MBMinor GC每秒钟触发上百次CPU全耗在GC线程上了。后来加上-Xmn 3GB之后GC次数直接降了两个数量级接口耗时也恢复正常。这种问题如果不看运行时实际值光盯着-Xmx永远找不到根因。3.2 用GC日志判断该不该动它要确认-Xmn是否合适最直接的方法是开GC日志观察Minor GC的真实间隔和单次耗时。比较通用的打印参数组合是这样-Xlog:gc*:file/app/logs/gc.log:time,uptime,levelJDK 9以上的写法是这样JDK 8及以下用-XX:PrintGCDetails -XX:PrintGCDateStamps。启动后运行一段负载接着去gc.log里数一下相邻两次Minor GC的时间间隔。如果高频GC次数过多且单次GC时间都不长优先考虑调大-Xmn而不是改代码。如果单次GC时间已经很长了再调大-Xmn只会更糟这时候要考虑的是减少对象分配量。打个比方GC日志就像体检报告。你要看的指标不只是“有没有GC”而是“GC的频率、单次耗时、回收前后堆内存的变化”。有一次我发现GC日志里Minor GC明明很频繁但每次回收后Eden区的使用率很快又满了说明这个业务的临时对象分配量是刚需单纯调大-Xmn只能延迟问题爆发不能解决问题本质最后还是在代码层做了对象池化才见效。3.3 一个完整的调整落地步骤下面是我在项目里比较常用的调整流程你可以直接照着走第一步观察现状。先不加任何-Xmn参数跑一段时间记录GC频率、GC耗时和接口响应时间。第二步估算合适的新生代大小。根据堆总量取三分之一到二分之一作为初始值如果你的业务临时对象多就偏向三分之一如果对象存活时间偏长就偏向二分之一。第三步在JVM启动参数里加上-Xmn同时固定-Xms和-Xmx让JVM没有动态调整的空间java -Xms4096m -Xmx4096m -Xmn2048m -XX:UseG1GC -Xlog:gc*:file/app/logs/gc.log:time,uptime,level -jar my-service.jar第四步运行后对比GC日志里的Minor GC次数和单次GC耗时。如果Minor GC频率下降明显且接口延迟没有恶化说明调整有效如果频率没怎么变但单次GC时间变长说明新生代偏大了回头再调小一点。第五步如果条件允许可以在压测环境里多做几组对比-Xmn分别设为堆的1/4、1/3、1/2用压测工具跑同样的流量对比GC指标和响应时间选出最优值。别指望一次调对调优本身就是一个迭代过程。4. 常见问题与排查技巧实录4.1 设置了-Xmn但jstat显示没生效这个问题我见过不止一次。有人在启动脚本里加了-Xmn1024m结果用jstat一看新生代空间完全不是那么回事。排查之后发现启动脚本里-Xmn写在了java命令参数的后面但又覆盖了或者被-Xx:MaxNewSize这样的参数覆盖。尤其要注意的是如果配置里同时存在-Xmn和-XX:MaxNewSizeJVM在处理时会有优先级差异显式的-XX:MaxNewSize有时会覆盖-Xmn的数学关系。解决方法是不要在多处重复配置同一个参数最好统一放在一个启动脚本或配置中心里。修改后重启前用前面提到的jcmd命令核对一下实际生效参数别等上了线才发现问题。还有一种情况是JDK版本不同导致的默认值差异。比如某些版本在未指定SurvivorRatio时默认行为可能与你想的不同结果实际新生代大小和-Xmn目标值之间出现偏差。遇到这类问题建议多看Java手册确认版本差异但我们的原则仍然是既然用了-Xmn就顺手把SurvivorRatio也显式指定杜绝默认值带来的不确定性。4.2 Survivor区太小导致对象“早晋升”这是-Xmn设置里最隐蔽的一个问题。你可以把Eden区设得很大气势恢宏但如果你忽略了Survivor区的大小会出现一个尴尬局面Eden区里的对象在Minor GC后需要转移到Survivor区可是Survivor区装不下JVM只好把这些对象直接晋升到老年代。一次两次没什么但日积月累老年代会被这些“本不该晋升”的对象填满Full GC提前到来服务出现周期性卡顿。要判断是不是这个原因GC日志里会有一个线索晋升失败或者老年代使用率突然飙升。这类问题适合用SurvivorRatio参数来修正比如把-XX:SurvivorRatio从默认的8改成3或4扩大Survivor区的比例让“转正”过程有充足缓冲空间。直觉上很多人会认为Eden越大越好但实际并非完全如此。Eden越大意味着每次Minor GC之间积累的垃圾越多单次回收需要清理的对象越多STW时间就越长。而Survivor太小则导致上面说的早晋升。所以新生代的三个分区之间也要平衡不能只盯着总量。4.3 -Xmn对吞吐量型任务的影响如果服务是离线计算、批处理这类对吞吐量敏感、对延迟不敏感的任务-Xmn的设置逻辑就完全不同了。这类任务往往没有什么外部用户等待停顿几百毫秒也可以接受目标是把任务尽快跑完。在这种情况下我倾向于把新生代设得相对大一点把Minor GC次数尽可能降下来宁可每次GC慢一点也不让GC频繁打断CPU计算。曾经跑一个数据清洗任务堆给了16GB-Xmn设了8GBMinor GC几分钟才一次整体处理时间比默认配置快了差不多一倍。但这个思路千万不要直接套到在线接口服务上否则接口会时不时卡一下用户体验会很差。另外如果应用对象本身生命周期极短、也没有太多活对象需要晋升那么-Xmn大一点不会对老年代造成压力因为大多数对象在新生代内就被回收了真正晋升到老年代的很少。4.4 动态晋升阈值和TLAB的连带影响还有一个细节容易被忽略-Xmn改变后对象在新生代的晋升阈值即对象经历Minor GC的次数阈值也可能受影响。JVM会根据Survivor区的占用情况动态调整这个阈值而不是一成不变。当Survivor区变小时动态阈值会自动调低让更多对象提前进入老年代当Survivor区变大时阈值会升高对象留在新生代的时间更长。这其实是JVM的自我保护逻辑但有时候会导致一个诡异的现象你以为把-Xmn调大是好事结果老年代增长得更快了。原因就是动态阈值降低、晋升变快了。遇到这种情况可以通过-XX:TargetSurvivorRatio来设定Survivor区期望占比比如设为60%让JVM尽量等到Survivor区用掉60%后再考虑晋升减少“被迫晋升”的频率。另外对象分配还有一个叫TLABThread Local Allocation Buffer的机制每个线程在自己的缓冲区里分配对象避免竞争锁。TLAB的大小默认由JVM根据堆大小自动计算。-Xmn调整后TLAB的默认大小也会变化如果发现线程分配对象时频繁发生TLAB重分配或慢分配可以适当调整-XX:TLABSize的值但这属于更细一层的调优了一般只有当你已经确认-Xmn、SurvivorRatio都设对了但分配性能仍不理想时再考虑。5. 一些实际操作中的个人体会调了这么多年JVM参数我最大的体会是不要神话任何单个参数。-Xmn再合理也只是给JVM一个更好的起点它不能代替代码层面的优化。如果你业务代码里到处都是大循环、大量new对象、重复创建集合那设置再精细的内存参数也只是在延缓问题而不是解决问题。反过来如果你的代码本身对象生命周期控制得很好那么即使-Xmn设置不是最优整体表现也不会差到哪里去。调优的正确姿势是先分析代码和业务模型再用GC日志和数据说话最后用-Xmn这些参数作为锦上添花的工具而不是包治百病的药。如果你刚开始接触JVM调优建议先养成一个习惯任何参数调整前先记录现状改完后做对比调整一次只改变一个维度。这样踩过的坑都能成为你的经验库而不是把一堆参数一次性改完出问题都不知道从哪查起。Java的内存管理虽然复杂但只要你愿意花时间把日志和指标读透它其实非常有规律完全能把它的脾气摸清楚。