如果有人问我“JVM常用的调优参数有哪些”我一般不会直接报参数而是先反问三个问题你的JDK是几机器多大跑的是什么业务前两天有位朋友面试回来吐槽说网上那张“最全JVM参数清单”他背了两遍结果面试官一句“你的-Xmx为什么取这个值”直接把他问住了。这个故事我听了太多次背后的问题其实很一致参数表是死的背下来容易难的是把参数和JVM的内存模型、垃圾回收行为、业务形态连起来想。这篇文章我就按“内存模型 → 参数拆解 → 部署场景 → 问题排查 → 面试组织”这条线把JVM调优参数这件事讲透。你会看到参数为什么这样写、每个值怎么定、Tomcat和容器里参数放在哪里才生效以及线上出OOM或GC异常时参数如何帮你定位。适合准备JVM面试的开发者也适合正在做线上性能优化、每天跟GC日志打交道的同行。1. 先建立一张参数与内存区域的映射表再谈调优1.1 运行时数据区与参数的对应关系JVM调优的第一步不是背参数而是知道每个参数到底在控制JVM的哪一块内存。HotSpot把运行时内存分成堆、元空间、线程栈、直接内存等区域几乎每个常用调优参数都对应着一块区域的行为。我把最核心的映射关系整理成了一张表运行时区域核心参数默认值要点主要职责堆总大小-Xms/-Xmx默认取物理内存的1/4存放几乎所有的对象实例新生代-Xmn/-XX:NewRatio常见默认新生代约为堆的1/3存放短命对象频繁触发Young GC幸存区比例-XX:SurvivorRatio默认8控制Eden与Survivor的比例元空间-XX:MetaspaceSize/-XX:MaxMetaspaceSize默认无上限存放类元数据、方法信息线程栈-Xss64位Linux约1MB每个线程私有的方法调用栈直接内存-XX:MaxDirectMemorySize默认约等于堆大小NIO等使用的堆外内存这张表的价值在于当你看到一份启动参数时能条件反射地知道它在影响谁。比如只调-Xmx而不看元空间类加载一多照样可能把容器打爆只调堆不调栈高并发线程一多就可能出现线程创建失败。我一直觉得调优参数本质上是“把对内存模型的理解翻译成启动脚本上的数字”所以这一节跳过去后面的参数拆解很容易变成机械记忆。1.2 用PrintFlagsFinal看默认值比听别人背参数可靠很多文章会直接告诉你“这个参数应该配多少”但很少有人提醒不同版本的默认值差异很大。最稳妥的办法是直接问你当前的JDK要什么默认值。在服务器上执行这条命令java -XX:PrintFlagsFinal -version输出会列出几百个可调参数及其默认值。比如MaxHeapSize会显示为4294967296这类字节数字除以1024再除以1024就能换算成GBMetaspaceSize、MaxGCPauseMillis、SurvivorRatio都能一眼看到。我每次给新项目写启动参数前都会先跑一遍这条命令确认当前JDK的默认水位。这样做的好处是你知道自己改动的是哪个方向的偏差而不是拿着别人的配置盲目抄。1.3 版本是关键变量JDK8、JDK9、JDK17的参数选择完全不同版本差异直接影响参数选择。JDK8默认使用Parallel Scavenge加Parallel Old吞吐优先堆内存模型比较经典JDK9开始默认垃圾收集器换成了G1很多JDK8时代“调优经验”直接失效CMS从JDK9开始被标记废弃到JDK14正式移除JDK17、JDK21继续以G1为默认ZGC也逐渐转正但默认并不启用。这里有一个常见误区有人拿着一套“JDK8调优秘籍”往JDK17上套结果有些参数直接不识别有些参数行为已变。比如-Xmn在Parallel收集器下能直接固定年轻代大小但在G1作为默认收集器时-Xmn仍能指定年轻代大小但G1内部有大量自适应逻辑强行固定年轻代反而可能让它失去弹性不如通过-XX:G1NewSizePercent这类G1专用参数控制。所以我建议你先确认“我的JDK是什么版本”再决定参数组合后面遇到每一个参数时也要带着版本意识去理解。2. 一套常见启动参数逐个拆解值怎么取为什么这么取2.1 -Xms等于-Xmx启动时慢一点运行期省掉扩容停顿堆内存的两个参数必须放在一起看。-Xms是堆的初始大小-Xmx是堆的最大大小。如果两者不相等JVM会在运行期间根据GC策略动态扩容或缩容这个动作本质上是“在业务运行中调整堆结构”很可能带来一次额外的Full GC或者较长的停顿。线上服务最怕这种不确定性所以我一般建议-Xms和-Xmx设成同一个值。问题是这个值怎么定不是拍脑袋而是先压测。拿你的业务做一次完整的压测观察稳定运行时的堆占用曲线取“峰值水位”再增加30%到50%的余量。比如压测时堆稳定在2.5G那-Xmx至少给4G比较安全。如果容器总内存是8G留出给元空间、线程栈、直接内存的空间后堆给4G到5G通常是比较常见的分配比例。这里有一个容易踩的坑堆设得太大比如8G容器给7G堆留给堆外内存和元空间的空间不够反而会频繁触发GC甚至OOM看起来是堆没调好其实是堆给多了。2.2 新生代大小GC频率、晋升压力与SurvivorRatio的三角关系新生代直接影响Young GC的频率和对象晋升老年代的速度。在Parallel收集器下-Xmn可以直接指定年轻代大小如果只设-XX:NewRatio2表示老年代和新生代比例为2:1新生代约占堆的1/3。年轻代越大Young GC触发的频率越低短命对象能在里面多待一会儿但年轻代过大会挤占老年代空间老年代一旦满了就会触发Full GC反而更伤。这里重点说SurvivorRatio。默认8表示Eden区与单个Survivor区的比例是8:1也就是Eden占新生代的80%。如果业务里有大量“存活速度适中”的对象它们从Eden被Young GC扫过之后还有一部分是有用的需要放进Survivor区。Survivor太小装不下的对象就会提前晋升到老年代老年代增长过快后续Full GC频率就会上来。我在实际项目里的调整思路是先保持SurvivorRatio8跑一个业务周期用jstat -gcutil盯住老年代增长曲线。如果发现每次Young GC后老年代涨得特别快优先把SurvivorRatio调成6或5扩大Survivor的沉淀能力而不是急着调大整个新生代。G1环境下稍微不同-Xmn的优先级会被G1的自适应策略削弱更多时候要用-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent来给年轻代设定上下限让G1在区间内自己判断。2.3 元空间和线程栈两个容易拖垮容器的“小参数”元空间存放类元数据JDK8之后从永久代搬到这里。MetaspaceSize不是上限它更像一个水位线达到这个值会触发类元数据的卸载扫描真正限制上限的是MaxMetaspaceSize如果不设置它默认没有上限只受物理内存约束。容器场景下这是隐患动态代理、反射、热部署加载大量类时元空间可能一路涨上去直到把容器内存耗尽触发native memory层面的OOM。所以我给容器应用配置时通常会设-XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m对绝大多数Spring Boot应用和常规Web服务都够用不够时会从日志里看到频繁的Full GC提示再按需调整。-Xss控制线程栈大小64位Linux默认约1MB。一个典型问题是高并发场景下线程一多默认栈大小会白白吃掉大量内存。假设你开500个线程1MB一个就是500MB很多线程实际用不了这么多栈。对普通Web请求的处理线程把-Xss设为256k或512k通常就够了。但要注意如果你的系统里有深度递归或复杂调用链栈缩小后有概率出现StackOverflowError所以这里建议先做一轮链路测试再调小。2.4 GC选型与辅助开关G1不是万能的DisableExplicitGC要慎用JDK8时代如果业务追求吞吐量、堆内存不大、停顿不敏感Parallel是最省心的如果追求响应时间、堆内对象多且复杂会显式打开CMS但现在CMS已经过时。JDK9之后默认G1能满足大多数场景只有超大堆或对停顿有极致要求时才会考虑ZGC。我的建议是没有非常特殊的理由不要手动在JDK17里强行指定收集器默认的G1已经调得很好。几个辅助参数值得记住。-XX:AlwaysPreTouch在启动时把堆内存全部预触碰物理内存一次性分配到位避免运行期首次访问才分配内存带来的卡顿代价是启动变慢、启动即占满-Xmx内存适合对启动时间不敏感、但对运行期稳定要求高的服务。-XX:UseStringDeduplication可以对G1场景下大量重复字符串做去重对某些业务效果明显但要注意额外开销。还有-XX:DisableExplicitGC这个参数我劝你别随便开它禁止了显式System.gc()确实能挡住一些框架里的主动回收调用但也会屏蔽掉RMI、NIO等组件依赖显式GC完成的清理逻辑开了之后可能引发堆外内存或本地内存OOM。看到网上有人“一键复制”这个参数我向来不建议照搬。综合起来我经常给一个JDK17、4C8G的常规服务写这样的启动配置先作为基线再根据压测调整java -Xms4g -Xmx4g \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m \ -XX:UseG1GC -XX:MaxGCPauseMillis100 \ -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heap.hprof \ -Xlog:gc*:/data/logs/gc.log:time,uptime,level注意JDK8用户需要把最后一行换成老式写法-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.log。这里面的每个值都能在上面的逻辑里找到依据而不是“别人都这么配”。3. Tomcat和容器场景下JVM参数到底写在哪个文件里3.1 catalina.sh、setenv.sh与JAVA_OPTS改了没生效的常见原因参数值定好了接下来是写入位置。Tomcat最常见的失误是直接改catalina.sh跑到一半发现被覆盖或者升级后丢失。Tomcat官方推荐的姿势是使用setenv.shcatalina.sh启动时会自动加载同目录下的setenv.sh没有这个文件就自己新建一个把参数放进去保持catalina.sh原封不动。export JAVA_OPTS-Xms4g -Xmx4g -XX:MetaspaceSize256m -XX:UseG1GC这一步看似简单实际有大量“改了没生效”的翻车案例。常见原因包括setenv.sh没有执行权限同时存在多个Tomcat实例改的是A的配置启动的是B或者你直接改的是~/.bashrc里的JAVA_OPTS而Tomcat的启动脚本并不读取那个环境变量。另外如果你通过systemd启动Tomcatsetenv.sh会照常执行但如果通过脚本启动要注意脚本里是否自己覆盖了JAVA_OPTS。每次改完配置我建议都顺手执行一下tomcat/bin/version.sh或看启动日志里的Using CATALINA_OPTS确认加载的是自己预期的值。3.2 容器里的JVM参数MaxRAMPercentage才是主角如果说Tomcat场景是“参数写在哪”的问题容器场景就是“参数不能怎么设”的问题。JDK8u191之前的版本不会自动感知cgroup的内存限制-Xmx按宿主机物理内存的1/4计算很可能在容器里直接超出限额被杀。升级到较新的JDK之后推荐使用比例参数java -XX:MaxRAMPercentage75.0 -XX:InitialRAMPercentage75.0 -XX:MinRAMPercentage75.0 \ -XX:MaxMetaspaceSize256m -Xss512k -jar app.jar这里的逻辑是容器内存总量由JVM自动识别堆最大占用容器内存的75%剩下的留给元空间、线程栈、直接内存和JVM自身。相比写死-Xmx比例参数在容器调整内存限额时更灵活不用改配置重启。不过要注意MinRAMPercentage指的是“物理内存很小”场景下的兜底值常规部署不必过度纠结主要盯住MaxRAMPercentage就够了。如果你还在用老的JDK8版本又无法升级那就老老实实把-Xmx限制到容器内存的一半以下这是最笨但最安全的方式。3.3 用jinfo和启动日志确认参数真的生效了参数写好了怎么确认它真的进去了先用jps查进程号再用jinfo -flags pid查看当前进程的JVM参数jps -l jinfo -flags 12345这能看到进程实际生效的非默认参数包括-Xmx对应的MaxHeapSize、-XX:MetaspaceSize这些。另外启动日志和ps -ef也能辅助确认。我曾经遇到过一次“catalina.sh里明明写了-Xmx4gjinfo看到的却是默认值”的情况查了半天发现是环境变量JAVA_OPTS在别处被覆盖这个排查过程几乎是必踩的坑。现在我的习惯是每轮改完参数后启动服务后第一件事就是jinfo -flags看一眼确认无误再放流量进来。4. 参数不只在启动脚本里OOM和GC排查时它们一样是主力武器4.1 先学会读GC日志JDK8和JDK9的日志参数差异调参效果好不好不看网上的经验贴要看自己服务里的GC日志。JDK8下经典配置是-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.logJDK9开始统一用-Xlog-Xlog:gc*:/data/logs/gc.log:time,uptime,levelGC日志里最需要关注的是三类信息Young GC发生的频率和耗时、Full GC发生的频率和耗时、每次GC后各区域容量变化。举个判断逻辑如果Young GC每隔几秒就触发一次说明新生代偏小或者Eden区填充太快如果Full GC频繁且老年代回收效果很差说明对象晋升过快或堆本身不够。参数的对错日志会第一时间告诉你而不是等业务报警了才察觉。4.2 留下事故现场HeapDumpOnOutOfMemoryError的参数组合线上最怕没有日志、没有快照的OOM。所以我把-XX:HeapDumpOnOutOfMemoryError当作必配项再配合-XX:HeapDumpPath指定堆转储文件目录OOM发生时自动留下当时的快照-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heap.hprof在用容器编排平台时我还会加上-XX:ExitOnOutOfMemoryError让JVM在第一次OOM时直接退出交给上层平台重新拉起避免半死不活的状态。这个参数组合能保证事故发生后你能拿到一份当时的堆快照用MAT或VisualVM分析谁占用了大量内存。我处理过不少线上OOM绝大多数情况下参数只是“开关”和“约束”真正要分析的对象是业务代码里的集合缓存、线程池、大数组。没有快照的话再懂参数也只能靠猜。4.3 动态观察jstat、jmap怎么跟参数配合GC日志是事后分析jstat是实时体检。一条非常实用的命令jstat -gcutil 12345 1000每秒输出一次各区域使用比例。重点看EEden、OOld、MMetaspace三列和FGCTFull GC累计耗时。如果E区每轮都快速填满并触发Young GC而O区稳步上涨、涨幅不明显说明新生代配置基本合理如果O区每次Young GC后明显跳动说明大量对象在向老年代迁移这时候就要回头检查SurvivorRatio、-Xmn或者业务代码里的大对象。需要导出对象分布时用jmap -dump:live,formatb,fileheap.hprof pid拿到快照离线分析。注意执行jmap的时机线上Full GC频繁时执行-dump:live本身会触发一次完整GC要评估是否会造成现网停顿谨慎操作。我的习惯是能提前配置HeapDumpOnOutOfMemoryError的就提前配避免事后在正在崩溃的进程上冒险执行jmap。5. 被问“JVM调优参数有哪些”时我会这样组织回答5.1 先给前提再谈参数面试也好团队评审也好听到“JVM调优参数有哪些”这个问题最忌讳直接报菜名。我会先立一个靶子“我以JDK17、4C8G的常规Spring Boot服务为例堆以外再留足元空间、线程栈和直接内存的余量然后配置如下。”这个前提一给后面每个参数都有了解释的上下文面试官也能跟着你的思路走而不是听你零散地念参数名。5.2 一个可以直接套用的口头回答框架我一般会按这五层来答第一层说堆-Xms4g -Xmx4g相等避免运行期扩容数值来自压测峰值水位加余量。第二层说元空间和栈-XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m防止类元数据吃满容器内存-Xss512k减少高并发下的线程内存耗费。第三层说GCJDK17默认G1-XX:MaxGCPauseMillis100是停顿目标按业务容忍度调整不追求极限。第四层说日志和快照-Xlog:gc*记录GC日志-XX:HeapDumpOnOutOfMemoryError配合-XX:HeapDumpPath保留事故现场。第五层说验证调整完通过jstat -gcutil观察老年代增长和GC频率用一个业务周期对比参数调整前后的GC耗时、业务RT和CPU。这个框架的好处是每一层都讲清楚了“是什么”“为什么”“怎么验证”面试官追问哪一层你都有话可接。这是从“背参数表”升级到“思考调优”的分水岭。5.3 几个高频追问回答不好容易露馅高频追问之一是“MaxGCPauseMillis是不是越小越好”。当然不是。G1的MaxGCPauseMillis只是一个软目标设成20ms会让G1频繁调整回收策略、更积极地开启Mixed GCGC次数上去了吞吐量反而下降。默认200ms对大多数服务足够我一般只在有明确RT要求时才压到100ms或更低。高频追问之二是“参数调完如何判断有效”。回答思路是不能只看启动后前几分钟的CPU和内存而是看同一业务周期内GC次数、GC总耗时、平均停顿时间、Full GC频率这些指标是否变好。尤其要警惕“参数调了一大堆业务指标没有任何变化”说明问题根本不在JVM参数而在代码或架构。高频追问之三是“你调优过程中实际碰到过什么坑”。这个问题我特别推荐你准备一两个真实案例。比如G1在超大堆场景下可能因为RSet过大导致本地内存占用高或者因为Region回收不及时出现Frequent Mixed GC再比如把年轻代调得过大反而让Survivor区周转效率降低导致更多对象晋升老年代。案例不一定要多复杂但一定是自己真实验证过的这比一百个参数名都有说服力。最后分享一个我自己的例子。有段时间负责的一个批处理服务Full GC频繁我第一反应是新生代太小直接把-Xmn从1G调大到3G。结果一周后再看Full GC次数不降反升。后来用jstat -gcutil配合GC日志分析才发现那批业务里有很多“半衰期偏长”的对象之前Survivor区刚好够用调大Eden后每次Young GC反而把更多对象推进了老年代老年代压力暴增。把Eden调回去、把SurvivorRatio从8调成5之后Full GC才明显减少。这件事给我的体会是JVM参数是业务的影子。业务要是不摸清楚调参就成了一场靠运气的赌局。你如果也在做调优建议先把“谁在占用老年代”“谁在反复进入Survivor”这两个问题搞清楚再动手改任何参数方向对了参数才有意义。