JVM调优实战指南：从内存模型到GC参数与排查工具

做后端的时间一长，"JVM调优"这四个字就绕不过去了。你可能会在某个深夜收到告警，发现服务频繁GC导致接口超时；也可能是在准备面试时被人追问"JVM内存模型画一下""垃圾回收器怎么选"；还有可能只是单纯想知道Tomcat启动时那一堆"-Xmx、-XX:+UseG1GC"到底该怎么设置。这篇文章我打算用一次真实的排查和调优过程，把JVM调优的完整脉络串起来：从内存模型的基本盘，到参数体系的逐个击破，再到jstat、jstack、jmap等工具的实战配合，最后附上我踩过的坑和常用排查套路。如果你正在学JVM、准备面试，或者手上有个服务时不时卡一下，这篇文章应该能帮你少走不少弯路。

1. 调优之前，先把JVM的内存地图刻在脑子里

1.1 运行时数据区：堆、栈、方法区到底怎么分工

先解决一个最基础的问题：搞清楚JVM把内存分成了哪几块，因为后面90%的调优动作都是在和这几块内存打交道。JVM的运行时数据区，我习惯叫它内存地图，主要分五块：

• 堆（Heap）：所有线程共享，几乎所有的对象实例都在这里分配。堆内部又分为新生代（Eden区、两个Survivor区S0/S1）和老年代（Old）。GC的主要战场就在堆上。
• 虚拟机栈（VM Stack）：线程私有，每个方法调用都会压入一个栈帧，里面保存局部变量表、操作数栈、动态链接、方法出口。栈的深度不够就抛StackOverflowError。
• 本地方法栈（Native Method Stack）：给native方法用的，一般调优很少碰它。
• 方法区/元空间（Metaspace）：JDK8之后彻底抛弃了永久代，改用元空间，存储类元数据、常量、静态变量等，直接使用本地内存，默认不设上限，这也是一个隐患来源。
• 程序计数器（PC Register）：记录当前线程执行到哪一行，很小的一块，忽略不计。

你可以把堆想象成一个共享仓库，所有线程都在往里面放东西、取东西；把栈想象成每个线程手里的独立工作台，把自己的局部变量摊在工作台上。仓库空间不足就会OOM（OutOfMemoryError），工作台堆太多东西就会StackOverflowError。为什么要先记这张地图？因为调优的本质就是：要么让对象更早地被回收，要么把内存区域设置得更合理。你连对象在哪个区域分配、什么时候晋升都不知道，调参数就只能算是瞎调。

还有一个容易被忽略的点：除了堆，元空间和栈的大小也经常是事故源头。我接过一个服务，代码里有大量动态生成类，结果元空间不断膨胀，最终把服务器的本地内存吃满。所以调优时不能只盯着堆。

1.2 垃圾回收的分代假设与收集器演进

GC（Garbage Collection）是JVM调优绕不开的核心。要理解GC为什么按代来回收，先要接受一个统计结论：绝大多数对象"朝生夕灭"，存活几分钟甚至几毫秒后就不再被引用；只有少数对象能活过几轮GC。基于这个假设，JVM把堆分成新生代和老年代：

• 新生代：优先用复制算法，将Eden和Survivor中存活的对象复制到另一块Survivor，一次性清理掉大部分废弃对象。GC停顿时间短，但吞吐量有一定代价。
• 老年代：对象经过多次Minor GC仍存活，或者大对象直接进入。老年代空间大，GC频率低但耗时长，通常使用标记-清除或标记-整理算法。

收集器这边，演进路线大致是：Serial -> Parallel -> CMS -> G1 -> ZGC。JDK8默认用的是Parallel Scavenge + Parallel Old，JDK9之后默认切换到了G1，CMS则在JDK14被正式移除。你如果还在JDK8上跑服务，需要自己指定GC收集器。G1成为默认的原因是它把整个堆按大小划分为许多Region，可以设置停顿时间目标，让GC停顿可控；ZGC更进一步，靠染色指针和读屏障把停顿压到亚毫秒级。但选型要结合业务，响应式服务优先低停顿，批处理任务优先吞吐量，没有一个收集器是万能的。

顺便说一句，如果对类加载和字节码有兴趣，你会注意到JVM还允许通过Instrumentation API在运行时修改类字节码，这也是Java Agent这类技术的基础。现在很多人用Kotlin快速写一个Agent在JVM上跑起来，本质就是在类加载过程中插入增强逻辑。把分代回收和类加载这两件事搞懂，你再去看各种Java Agent、字节码框架就不会觉得玄乎了。

2. 调优第一步：看懂参数，才会调参数

2.1 JVM参数体系的三个层级

JVM参数分三类，很多人一上来就被一堆"-XX"参数搞晕，其实规律很简单：

• 标准参数：以单个"-"开头，比如-version、-help，所有JVM实现都必须支持。
• 非标准参数：以"-X"开头，比如-Xms、-Xmx、-Xmn、-Xss。注意，-X参数是HotSpot特有的，不保证在其他JVM上可用，但是实际生产里大家基本都用HotSpot，所以放心用。
• 高级参数：以"-XX"开头，分为布尔型和键值型。布尔型如-XX:+UseG1GC、-XX:+HeapDumpOnOutOfMemoryError，加号开启、减号关闭；键值型如-XX:MaxMetaspaceSize=512m、-XX:MaxGCPauseMillis=200。

常用堆参数我列一下：

这些参数彼此之间是有联动的。比如设置了-Xmn新生代大小，实际上就间接影响了老年代大小；设置了-XX:MaxGCPauseMillis，G1会动态调整新生代大小来逼近这个目标。调参的时候不能单看一个参数，要把它放到整张内存地图里来理解。

2.2 Tomcat启动时设置JVM参数的正确姿势

Tomcat启动设置JVM参数，这个问题太常碰到了，基本是"猫"系服务的日常操作。网上很多教程让你直接改bin/catalina.sh，往里塞JAVA_OPTS，这能跑，但不优雅，也不安全。更推荐的做法是在bin目录下新建setenv.sh（Windows就是setenv.bat），Tomcat启动时会自动加载这个文件。为什么推荐setenv.sh？因为升级Tomcat版本时，catalina.sh可能被覆盖，而setenv.sh不会。

我再强调一个细节：调优参数应该放到CATALINA_OPTS而不是JAVA_OPTS。原因在于Tomcat的启动和停止都会使用JAVA_OPTS，而CATALINA_OPTS只传给Tomcat主进程。如果你把堆大小参数放进JAVA_OPTS，停止脚本里的Java进程也会带上这些参数，容易引发一些莫名其妙的启动/停止问题。

一个实际可用的配置示例：

参数设置完后怎么验证是否生效？我一般用三个命令：jps -l拿到Tomcat进程的PID；jcmd VM.flags查看所有JVM Flag；jinfo -flags 查看当前生效参数。如果你发现jinfo显示的值和setenv.sh里写的不一致，优先检查是否有别的配置文件（比如setclasspath.sh）覆盖了你的设置。

2.3 JRE和JVM的关系：先别把运行时环境搞混

JRE和JVM的关系，属于那种"一到面试就卡壳"的基础题。很多人分不清，其实一句话就能说清：JVM是Java虚拟机，是实现规范的那个"引擎"；JRE是Java运行环境，等于JVM加上Java核心类库（java.lang、java.util这些）和其他运行组件；JDK又是在JRE基础上再叠加javac、jdb等开发工具。打个比方，JVM就像发动机，JRE是装配好的整辆车，JDK是带全套维修工具和诊断设备的4S店。你平时写代码、编译用的是JDK，但线上跑程序只需要JRE，而真正执行的其实是JVM。

调优时为什么关心这三者的关系？因为不同版本的JDK/JRE会带来完全不同的默认参数和GC行为。比如同样的启动脚本，在JDK8上默认是ParallelGC，在JDK17上默认变成了G1；再比如JDK9之后GC日志参数格式整个变了。所以调优之前一定要确认你的运行版本，否则从网上抄一段参数过来可能直接报错。

3. 实操：一套可复用的性能排查流程

3.1 先收集数据：jps、jstat、jmap、jstack怎么配合

理论聊完，进入实战。我最常用的排查流程不是一上来就改参数，而是先按"确认现象 -> 看内存/GC -> 看线程 -> 再定结论"的顺序走。

第一步，jps -l确认Java进程的PID。别用ps grep java，那样经常匹配到不相关的进程，jps是JVM自带的，最准确。

第二步，jstat看GC统计。命令是：

参数含义是每1000毫秒打印一次GC情况。重点关注几个列：YGC（Minor GC次数）、YGCT（Minor GC累计耗时）、FGC（Full GC次数）、FGCT（Full GC累计耗时）、OC（老年代当前容量）、OU（老年代使用量）。如果FGC很频繁、FGCT很长，问题大概率就出在老年代。

第三步，jmap看堆配置和堆转储。jmap -heap 能查看堆的分代大小和配置，适合确认参数是否生效；jmap -dump:live,format=b,file=/tmp/heap.hprof 能导出一份堆转储文件，用MAT或jhat分析大对象和内存泄漏。注意导出live堆会触发一次Full GC，会对线上有影响，建议在低峰期操作。

第四步，jstack看线程快照。这个工具结合CPU排查很有用，下面单独说。这四件套配合起来，基本上能定位绝大多数内存和线程问题。我还习惯用jcmd GC.heap_info看一眼堆各区域的即时状态，比jmap快，而且不需要额外进程。

3.2 从GC日志看出问题苗头

GC日志是调优最直接的依据，没有之一。很多线上问题，看日志比看监控曲线更早暴露。GC日志的开启方式，JDK8和JDK9+不一样。JDK8及以前用-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log；JDK9及以上用统一日志语法-Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags。

注意：JDK9及以上版本的GC日志开启方式已经变化，用旧的-XX:+PrintGCDetails会直接提示参数已废弃。统一用-Xlog:gc*:file=...这种格式。

拿到GC日志后看什么？我总结三个观察点：

• Minor GC频率：每分钟几次是正常的，每秒好几次就说明新生代太小或者对象产生太快。
• Full GC频率：最好几天甚至几周一次，一旦几分钟一次就要警惕，基本就是老年代空间不足或内存泄漏。
• GC停顿时间：看日志里的user、sys、real三个时间。real和user相差太大，说明GC有较长的Sys阶段，可能存在内核层面的问题或者机器资源竞争。

举个例子，我接过一个服务，日志里平均每5秒一次Minor GC，每分钟一次Full GC，一次Full GC耗时3秒。这种状态接口不超时才有鬼。后来用jmap dump下来一分析，发现是一个缓存工具类用了一层HashMap套List，存储了全量历史订单，典型的对象逃逸导致老年代暴涨。把缓存加上容量上限和过期策略之后，Full GC直接降到一天一次。这就是GC日志的价值：你不需要猜，看趋势就能判断问题方向。

3.3 线程与CPU排查：用jstack抓死循环和锁竞争

如果说GC日志解决的是内存问题，那CPU飙高和线程卡死就要靠jstack了。CPU飙高的标准排查流程：

1. top找到CPU占用最高的Java进程PID。
2. top -Hp 找到该进程内CPU占用最高的线程TID。
3. printf '%x\n' 把线程ID转成十六进制。
4. jstack | grep -A 20 '<十六进制线程id>'，看这个线程到底在干什么。

这个流程我用了无数次。有一次定位一个死循环，就是jstack后看到一个RUNNABLE线程一直卡在自己的业务代码里，下面跟着一整串业务调用栈，一眼就锁定了方法。

除了死循环，jstack还能抓锁竞争。当大量线程处于BLOCKED状态，并且等待的锁指向同一个对象时，基本就是锁竞争太激烈。常见优化方向是缩小锁粒度、减少共享、用读写锁替换互斥锁。记住，jstack只是一个快照，一次采样有时候不够准确，可以用jstack > stack1.txt间隔几秒采两三次对比，看线程状态是否稳定。

4. 参数调优案例：从一个线上服务说起

4.1 初始堆和最大堆：该不该一样大

很多人的第一反应是问-Xms和-Xmx到底该设多少。我的建议：生产环境一律将两者设成相同值。理由很简单，堆扩展和缩容都有成本，而且-Xms小于-Xmx时，JVM在高峰加载期反复扩容，可能引发额外的GC和停顿。反正服务器内存通常固定，直接一步到位。

具体值怎么定？我的经验是：在平稳运行几天后，观察Full GC之后老年代的使用量，把这个值视为老年代的稳定底数，然后给堆留出30%-50%的缓冲。比如老年代稳定占用1.5G，新生代约1G，那整体堆设在3G到3.5G比较稳妥。不要拍脑袋直接设最大内存的75%，因为JVM还有元空间和线程栈要占本地内存。

有一个常见的坑：32位系统和64位系统的指针压缩问题。堆如果小于32G，可以开启-XX:+UseCompressedOops压缩对象指针，大幅节省内存。一旦堆大于32G，指针压缩失效，同样的对象数量内存要多消耗30%以上。所以如果不是真的需要超大堆，卡在32G以下常常更划算。

4.2 垃圾回收器选型：CMS退场之后用G1还是ZGC

垃圾回收器选型没有标准答案，只有适合你的业务场景。按照业务特点分三类：

• 吞吐优先的批处理任务：比如离线计算、日志清洗，选Parallel Scavenge + Parallel Old，把-XX:+UseParallelGC打开，追求单位时间处理更多任务。
• 响应优先的在线服务：比如Web API、交易系统，推荐G1。设置一个可接受的最大停顿时间目标：-XX:MaxGCPauseMillis=200。
• 超大堆、极低停顿要求：堆在几十G以上且对延迟极其敏感，可以考虑ZGC。ZGC可以做到几十毫秒甚至亚毫秒级停顿，但代价是有一定的吞吐量损耗，且JDK15之后才逐步产品化，版本太老就不能用。

不要迷信"最新就是最好"。我有一次把老服务从Parallel切到ZGC，停顿确实降了，但吞吐量降了5%，高峰期CPU直接打满。后来退回G1并优化了参数，效果比强行上ZGC好得多。

G1值得重点调的核心参数其实不多：

• -XX:MaxGCPauseMillis=200：目标停顿时间，不是硬性保证，但G1会尽量去逼近。
• -XX:G1HeapRegionSize：Region大小，默认根据堆自动计算，一般不用改；但如果堆特别大，可以手动设成16m或32m。
• -XX:+PrintAdaptiveSizePolicy：查看G1自适应调整的过程，适合诊断为什么停顿目标和实际偏差很大。

4.3 批量调优思路：多实例部署时如何统一管理

"批量调优"这个词经常出现在大促备战手册里。所谓批量，就是你的服务不止一个实例，而是几十台、几百台机器一起部署。调优参数如果不能统一管理，就会出现每个实例参数不一致、线上行为飘忽不定的情况。我的做法是三层管理：

第一层，把JVM参数抽成模板文件，比如jvm.options，按服务类型分"web服务""批处理服务""定时任务"三套基线。第二层，由发布脚本读取模板，自动生成setenv.sh或者直接拼接到启动命令里。这样机器即使重置，也能保证参数一致。第三层，关键参数沉淀到监控配置，比如GC次数、GC耗时、堆使用率，凡是偏离基线的实例自动告警。

这里有一个注意点：多实例部署时，往往每台机器上有多个Java进程，模板里-Xmx这类参数应该按每个进程的内存需求来定，而不是拍脑袋"越大越好"。如果一台机器上跑着Tomcat、消息消费者、定时任务三个进程，每个都设最大堆4G，机器只有16G内存，结果就是频繁使用Swap，整个机器变卡。我习惯按进程重要性分配：核心Web进程给50%，次要进程各给20%，剩下10%留给操作系统和元空间。

5. 常见问题与排查技巧实录

5.1 面试官常问的JVM问题怎么答

JVM面试题在技术面试里出现率极高，而且非常容易暴露水平。我整理几个高频方向和回答思路，按照"先背结论、再讲原理、最后落到实际"三层来准备就不会慌。

• JVM内存模型：画出运行时数据区五块结构，说明堆、栈、元空间各存什么，顺带提一个例子，比如方法递归太深抛StackOverflowError，就是栈帧过多。
• 类加载机制和双亲委派：讲清楚启动类加载器、扩展类加载器、应用类加载器的父子关系，以及双亲委派为什么能避免核心类库被重复加载甚至被篡改。
• 如何判断对象可回收：引用计数法和可达性分析，重点说可达性分析为什么不会被循环引用误伤，顺带提GCRoots都包含哪些。
• GC算法对比：复制、标记-清除、标记-整理三种，分别对应新生代和老年代。面试官往往会追问为什么不统一用一种，答案就是没有一种算法能在内存利用率和回收效率上同时最优。
• 内存泄漏和内存溢出区别：内存泄漏是对象不再使用却仍被引用，内存溢出是可用内存不足。两者经常叠加出现，排查时用jmap dump看对象分布，哪些对象异常多是重点嫌疑。
• 调优案例：建议准备一个真实案例，哪怕是开发环境复现的，讲清楚现象、排查命令、结论、调整参数、验证效果五步，比背一百个参数更有说服力。

5.2 常见线上问题速查表

把问题、可能原因、排查手段做成一张表格，放到团队文档里当速查表非常有用：

这个表里的每一行我都踩过不止一次。尤其是"内存溢出OOM"这一行，很多人拿到OOM就只盯着堆大小，实际上OOM有几十种类型，最常见的包括Java heap space、GC overhead limit exceeded、Metaspace和Unable to create new native thread。一定要先看异常类型再决定怎么调整。

5.3 几条真实的调优心得

最后分享几条来自实操复盘的心得，你可以当成避坑清单：

调优之前先确认这是不是JVM的问题。我见过很多"JVM调优"请求，最后发现是连接池漏配、数据库慢查询、代码里打大量日志导致的。GC频繁只是表象，根因根本不在JVM。调优别急着动参数，先把CPU、IO、网络、日志这些外部因素排除掉再回来。

每次只改一个参数。这是调优的基本原则。同时改-Xmx、GC收集器、MaxGCPauseMillis三个值，出问题了根本分不清是哪个造成的。每改一个，都要记录改前改后的GC日志和压测指标，才算一次有效调整。

线上的参数改动一定要留观察期和回滚方案。JVM参数不像代码，出了Bug可以立刻改代码发版，参数一改可能要在高峰期运行一阵才暴露问题。我习惯把参数改动规范化成一个变更记录，写明原因、改动项、验证指标、观察周期，最少观察三天。

关于JVM调优，我在实际项目里最大的体会是：它不是一个独立的操作，而是一套"观察现象、理解内存、定位根因、精准调整、再验证"的闭环。很多人拿一个参数模板到处套，效果差，本质就是因为跳过了观察和定位这两步。如果你手上正好有服务在频繁Full GC，先别急着抄别人的-Xmx和GC参数，按我上面这套流程把现场数据收集齐，你会发现答案大概率自己就浮出来了。最后再送一个小技巧：把常用的排查命令做成别名或者脚本，比如我这里的jstatgc脚本每次自动打印YGC/FGC/Old Gen占用，排查效率能提高不少。