先说点实在的很多学JVM的人卡在“听懂了原理一到调优就懵”。原因很简单原理讲的是“JVM怎么设计”调优讲的是“你的应用到底在什么场景下怎么死”。这两者之间隔着一层东西就是GC参数和运行时数据区里那些容易被人忽略的区域。这篇文章把这块补上重点聊GC常用参数、Method Area方法区的实际行为以及一个完整的调优案例怎么一步步拆出来。1. GC参数别背参数列表先搞清三类问题网上各种GC参数大全一搜一大把但说实话真到排查问题的时候你根本用不上那么多。我自己的经验是把GC参数按用途分成三类记思路会清晰很多一类是设置堆和分代大小的一类是选择GC算法和触发时机的一类是输出GC日志用来排查的。这三类各司其职混在一起记只会越记越乱。1.1 堆大小参数为什么-Xms和-Xmx要设成一样先看最基础的一组-Xms初始堆大小 -Xmx最大堆大小 -XX:NewSize新生代初始大小 -XX:MaxNewSize新生代最大大小 -XX:NewRatio老年代与新生代的比值默认2即老年代:新生代 2:1 -XX:SurvivorRatioEden区与一个Survivor区的比值默认8即Eden:Survivor 8:1很多新手上来就问“-Xms和-Xmx到底要不要设成一样”我刚入行时也觉得设成一样浪费后来在某个项目里吃了亏才明白。那个项目-Xms设了512M-Xmx设了4G看起来“给JVM留了弹性空间”结果是每次GC完堆缩回去过一会儿又要扩频繁触发堆扩容和收缩。堆扩容是要向操作系统申请内存的这个过程涉及系统调用代价一点不低。更麻烦的是堆扩缩会导致GC时的停顿时间忽高忽低用监控工具看就是一条锯齿线你根本没法判断这个JVM到底稳不稳定。后来我把两个值设成一样GC停顿立刻平稳了。道理其实很朴素堆大小确定后JVM就不用反复跟操作系统讨内存GC的行为会更可预测。生产环境没有特殊理由一律-Xms等于-Xmx这是很多大厂内部规范里明文要求的一条。1.2 日志参数的组合用法线上排查全靠它日志参数是排查问题的眼睛少配一个都可能让你事后抓瞎。我常用的组合是这样的-Xlog:gc*:file/data/logs/gc-%t.log:time,uptime,level,tags:filecount10,filesize50m这行命令在JDK 11里是标准写法。老一点的JDK 8则用-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/data/logs/gc.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize50M其中%t会在日志文件名里带上JVM启动时间避免多个应用实例日志互相覆盖。filecount10和filesize50m控制日志轮转防止磁盘被GC日志撑爆。这一套配下来即使线上出了问题也能靠日志回放当时的GC节奏而不是靠猜。我自己踩过的坑是只配了-Xloggc忘了配轮转结果某个高并发服务运行两个星期后GC日志文件涨到了20多G把磁盘直接写满。那次事故之后我养成了一个习惯任何生产环境JVM必须同时确认GC日志路径和日志轮转策略缺一不可。2. GC算法参数选型从Serial到ZGC每个选择都有代价GC算法的选型不是越新越好也不是“默认就是最好”而是要看你的应用场景到底能不能承受某种停顿。垃圾收集器适用场景关键参数典型停顿Serial GC单核小应用、客户端程序-XX:UseSerialGC秒级甚至更高Parallel GC吞吐量优先、后台任务-XX:UseParallelGC秒级但吞吐高CMS低延迟、互联网Web应用-XX:UseConcMarkSweepGC平均几十毫秒到百毫秒级G1大堆、低延迟与吞吐兼顾-XX:UseG1GC目标可配置一般几十毫秒ZGC超大堆、极低延迟-XX:UseZGC平均低于1ms2.1 Parallel GC的典型配置与适用场景Parallel GC的核心思路是“多线程并行回收换高吞吐”。它适合那种不在乎单次停顿时间只在乎单位时间里能干多少活的场景典型就是离线计算、批量任务、大数据的MapReduce作业。一个典型的配置-Xms8g -Xmx8g -XX:UseParallelGC -XX:ParallelGCThreads8 -XX:SurvivorRatio8ParallelGCThreads在CPU核数为N时默认值是当N小于等于8时等于N大于8时等于3 (5 * N / 8)。这个公式是有讲究的因为GC线程太多反而会因为线程切换和争抢导致效率下降。如果你的机器是16核默认值大概是13但如果你的业务线程本身就吃满CPU那13个GC线程会让业务线程卡得很难受这时候手动压到8可能是更合理的选择。2.2 G1的内存模型差异为什么它的停顿可控G1和传统的分代收集器有一个本质区别它不再要求物理上的连续Eden、Survivor、老年代区域而是把整个堆划分为若干大小相等的Region。每个Region在逻辑上可以扮演Eden、Survivor或Old区这一设计让G1可以用“增量回收”的方式控制停顿。G1的核心参数-XX:UseG1GC -XX:MaxGCPauseMillis100 -XX:G1HeapRegionSize4m -XX:InitiatingHeapOccupancyPercent45MaxGCPauseMillis只是目标值不是硬保证。G1会通过调整回收的Region数量来尽量把停顿压到目标值以内但如果你把目标定得太低G1回收速度跟不上分配速度反而会导致FULL GC更频繁。InitiatingHeapOccupancyPercent45表示老年代占用达到堆的45%时启动并发标记周期。这个值不是越大越好调大了可以减少标记频率但调太高会让并发标记启动过晚最终老年代堆积到不得不FULL GC。2.3 ZGC低延迟但要付出的代价ZGC把STW时间压缩到了1ms以内原理是染色指针读屏障GC过程中大部分工作与应用线程并发执行。听起来很完美但代价是CPU占用率明显上升因为读屏障在每个对象访问路径上都加了一层判断。如果你的应用是那种对延迟极其敏感、堆又很大的在线服务比如某些交易系统ZGC值得试。但如果你的机器CPU资源已经吃紧ZGC的额外开销可能会让你得不偿失。选型时永远记住没有最好的收集器只有最适合当前场景的收集器。3. Method Area最容易产生误解的一段内存方法区这个名字从《Java虚拟机规范》的角度和从HotSpot实现的角度理解上是两回事。不少人把这两者混为一谈排查问题时就容易走弯路。3.1 规范里的方法区 vs HotSpot的元空间《Java虚拟机规范》里规定JVM要有方法区它存放类信息、常量、静态变量、即时编译器编译后的代码缓存等数据。但规范没规定方法区具体怎么实现。HotSpot对方法区的实现经历过几个阶段JDK版本实现方式大小控制参数JDK 6及以前永久代PermGen-XX:PermSize/-XX:MaxPermSizeJDK 7永久代但逐步移除字符串常量池同上JDK 8元空间Metaspace-XX:MetaspaceSize/-XX:MaxMetaspaceSizeJDK 8把永久代彻底移除改用元空间最核心的变化是元空间使用本地内存不再占用JVM堆内存。也就是说类的元数据不再受堆大小限制而是受操作系统可用内存限制。这个改动解决了一个长期痛点以前永久代不够用会抛OutOfMemoryError: PermGen space现在只要物理内存够类可以随便加载。3.2 方法区溢出怎么排查两个真实场景场景一某个系统频繁动态生成代理类。有一次某开发者遇到OutOfMemoryError: Metaspace第一反应是堆不够于是不停调大-Xmx结果毫无缓解。后来看了日志才发现是代码里有个循环在用Proxy.newProxyInstance创建代理类而且类加载器没有复用导致每次迭代都生成新的类元数据进元空间。解决方式是改用缓存的类加载器并在代码级别复用代理类。场景二某个Web应用不断热部署每次重新部署WAR都会创建新的类加载器旧的类加载器没有被回收。理论上类加载器不可达后它加载的类元数据也应该从元空间释放但实际中如果存在ThreadLocal、静态集合等隐式引用旧的类加载器永远不会被回收元空间就持续上涨。这种情况下-XX:MaxMetaspaceSize只能当兜底真正要解决的是代码里对类加载器的引用泄漏。3.3 这个案例能学到什么方法区溢出很少是单纯的“内存不够”绝大多数是类加载器泄漏或动态生成类失控。所以排查方法区问题时第一件事不是调参数而是用jmap -clstats pid看类加载器数量和每个加载器加载的类数量找到异常的类加载器再顺着代码找是谁在创建它、谁持有它。4. 一个真实调优案例从日均多次FullGC到稳定运行前面讲了不少参数但参数只有落到实际问题上才有意义。下面分享一个我参与过的真实案例完整还原排查和调优过程虽然经过了脱敏处理但思路可以原样复用。4.1 现象接口偶尔超时监控显示老年代持续上涨某业务系统高峰期QPS在两千左右主要接口的P99延迟时有恶化监控平台显示老年代使用量持续上涨每天会出现多次Full GC每次Full GC停顿最长达数秒。用户反馈是“系统偶尔卡一下过几秒自己恢复”。这其实就是典型的老年代持续增长导致Full GC频繁的形态。当时服务的启动参数是这样的-Xms4g -Xmx4g -XX:UseConcMarkSweepGC -XX:NewRatio2 -XX:SurvivorRatio8表面看没什么问题堆4G老年代约2.7G新生代约1.3GCMS收集器适合低延迟场景。4.2 排查链路先看日志再看对象最后定位代码第一步看GC日志。日志里能看到老年代从2G左右开始随着运行时间线性增长直到触发CMS并发标记但并发标记后老年代没有明显下降。这个信号说明有大量对象在老年代不断累积而且这些对象多数是活着的否则CMS并发回收后老年代使用量应该回落。第二步用jmap -histo:live pid看存活对象分布。结果Top对象里有大量byte[]和某个内部缓存类的实例。byte[]在Java内存分析里是最常见的“背锅侠”因为它确实可能是业务数据也可能是序列化缓存也可能是日志框架的buffer必须结合业务代码判断。第三步用jmap -dump:live,formatb,file/tmp/heap.hprof pid导出堆快照用MAT分析。这里有个关键细节-dump:live会先触发一次Full GC所以导出来的堆里只剩下存活对象这正好符合我们需要分析“谁一直活着占据老年代”的需求。MAT分析结果指向了一个静态Map这个Map是一个全局缓存key是用户IDvalue是最近一个月该用户的订单列表快照。代码逻辑是每次查询订单时先查缓存缓存没有再去数据库查并放入Map。看起来是标准缓存方案问题在于这个Map没有过期时间和容量上限而缓存的值是“某个用户一个月的全部订单”包含完整的商品明细、地址、发票信息一条记录可能几十KB。一个月活跃用户往上积累这个Map就以每天几百MB的速度增长。4.3 修复方案缓存加容量限制和时间过期修复不复杂但需要对业务有一定理解。最终方案是三管齐下引入Caffeine本地缓存配置最大条目数5000写入后30分钟过期针对大对象字段做裁剪列表接口只返回概要字段明细字段按需单独查询调整GC参数老年代与新生代比例从NewRatio2调整为NewRatio3。第三步很多人不理解我解释一下。原来的场景里新生代偏大对象在新生代里活了比较久才进入老年代但问题恰恰是很多长生命周期对象被当成了短生命周期对象。调整为NewRatio3后新生代变小短期对象更快被回收长生命周期对象更快进入老年代由CMS统一管理反而减少了新生代到老年代的晋升波动。当然这一步只起辅助作用真正的收益来自前两步。4.4 调优结果与复盘调整后观察三天Full GC从每天多次降为零老年代使用量稳定在1G以内P99延迟从偶尔数秒恢复到几十毫秒。复盘时几个关键认知值得记住监控图上老年代持续上涨第一反应应该是“有对象泄漏或缓存失控”而不是“堆不够大”。堆调大只是推迟问题爆发不是解决问题。byte[]占据堆内存Top不代表问题出在byte[]本身要顺着引用链找到是谁创建了它。调优参数只是手术刀真正病灶往往在业务代码里。参数调得再漂亮缓存无限增长的问题依旧存在。5. 调优路上的几个共识与反共识做了一段时间JVM调优我自己的体会是有些道理看似是共识实际换到不同场景就要重新审视。挑了三个最容易让人钻牛角尖的点聊聊。5.1 “FULL GC一定有害”是个误解Full GC停顿时间长没人喜欢但它不完全是坏事。CMS的Remark阶段和G1的并发标记周期都需要特定触发条件Full GC往往是在这些机制来不及回收时的兜底手段。如果你的系统偶尔一次Full GC后明显释放了大量内存而且之后很长一段时间不再出现那么这次Full GC更像是一次“成功的大扫除”不一定是坏事。真正要警惕的是两种形态Full GC频繁比如一分钟一次或者Full GC后老年代使用量不下降说明有大量对象是“死不了、又活不长”的这种对象最折磨GC。5.2 调优参数不是越多越好见过不少团队启动参数拉了几十行从-XX:PrintGCDetails到-XX:MaxGCPauseMillis到-XX:HeapDumpOnOutOfMemoryError看起来专业但其中一半是互相冲突的。比如同时开CMS和G1的参数JVM只会认最后一个再比如-XX:MaxGCPauseMillis调得很低但堆开得特别大那G1只能频繁启动并发标记周期CPU狂飙停顿反而没降下来。我的建议是先保证基础参数正确再针对具体问题加参数。基础参数就是我前面提到的堆大小、GC算法、日志输出这三样配好已经能覆盖80%的日常需求。等真遇到问题再根据监控数据针对性新增参数每次只改一个观察效果后决定是否继续调。5.3 监控优先于调优很多人在调优前根本没建立监控这是本末倒置。没有监控数据你不知道老年代是怎么涨的、对象是怎么分配的、停顿是什么时候发生的调优就只能靠猜。一套最轻量但足够用的监控方案是GC日志做轮转落盘定期抓取堆使用量和GC次数汇总加上jstat -gcutil pid 1000观察实时变化。这三样配合起来已经足够定位绝大多数JVM问题。先把监控搭起来再谈调优顺序不能反。6. 调优案例的另一种走向内存泄漏的定位思路上一节的案例是缓存失控属于“对象本不该长期存活却因为被引用一直活着”严格说属于逻辑层面的内存增长。但还有一种更隐蔽的情况是真正的内存泄漏对象已经没有任何业务意义却被某个静态引用链死死拽住。这种问题用同样的排查链路定位方法稍有不同。6.1 如何确认是泄漏还是增长判断泄漏还是增长看GC后老年代趋势如果每次Full GC后老年代使用量都能降到一个稳定低点那就是普通增长如果Full GC后使用量虽然下降但下一次增长到更高水平再触发Full GC低点也在缓慢抬高那基本就是泄漏。这个区别决定了调优方向普通增长优先查缓存策略和对象生命周期设计泄漏优先查引用链和类加载器。6.2 常用工具链jstat实时看GC状态快速判断当前JVM是否健康。jmap -dump导出堆快照配合MAT分析引用链。jcmdJDK自带诊断命令可以查看系统属性、堆信息还能触发GC。MAT的Dominator Tree找出“如果回收这个对象能释放多少内存”的大对象先看这些事半功倍。我用MAT有一个习惯拿到hprof文件后不是先看Leak Suspects报告而是先看Dominator Tree找到最占内存的几个对象右键-Path to GC Roots-exclude weak references。这一步能直接告诉你这个对象到底是被谁强引用着、为什么一直回收不掉。如果是通过WeakReference或者SoftReference引用的先排除掉剩下的强引用链才是真正要查的。6.3 定位到代码后的修改思路假设你通过Path to GC Roots找到一条链ThreadLocal - 某个Context对象 - 大的业务对象。修复思路通常是检查ThreadLocal是否被正确remove。使用线程池时尤其要注意因为线程池里的线程是复用的ThreadLocal值不会被自动清理必须在使用完的finally块里调用remove()。如果对象是经过某个框架或工具类持久的引用考虑改用弱引用或软引用容器。修改后跑一轮长时间压力测试确认老年代低点不再持续抬高。这一步特别容易犯的错是“改完代码觉得好了”实际上一次Spring容器重启后ThreadLocal又被重建了问题藏得更深。要彻底验证必须压测到原来的问题规模再往上走一截观察至少24小时的GC曲线。7. 给新手的调优路径建议最后这部分写给刚开始接触JVM调优的读者。我踩过的坑不想让你再踩一遍按下面这条路走能少走不少弯路。7.1 第一步把日志和监控先做好不要一上来就调参。先确认GC日志完整输出、日志轮转开启、堆转储参数配置好-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis100 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump.hprof -Xlog:gc*:file/data/logs/gc-%t.log:time,uptime,level,tags:filecount10,filesize50m这套配置同时开了堆转储和GC日志已经能应对绝大多数排查需求。然后配合监控平台任意开源的或商业的都可定期记录堆使用量、GC次数、GC耗时坚持观察一周你就能摸清应用的GC节奏。7.2 第二步带着问题调参而不是为了调参而调参每次调参都要有明确假设。比如“我觉得老年代涨得太快所以把SurvivorRatio调大让对象在新生代多待一会”这就是一个可以验证的假设。改完参数跑一段时间观察GC日志和监控看看假设是否成立。如果假设不成立不要继续叠加参数先回退再看数据。这是很多人没做到的调参失败了也不回退参数越堆越多最后根本不知道是哪个参数起了作用。7.3 第三步学会从监控曲线反推问题看GC曲线时养成从图形反推状态的思维。比如老年代使用量是一条平缓向上的线说明有对象持续进入老年代且无法回收如果是一条阶梯线说明每次GC都能回收一部分但总有残留如果是一条锯齿线说明GC频繁且回收能力不足。不同的曲线形态对应的排查方向完全不同。看到图形的那一刻你就应该能说出接下来该打开jmap还是该看代码。我个人的经验是调优的终点不是把某个参数调到完美而是对应用的GC行为形成稳定的预期。当你看到一条GC曲线能大致说出这个应用正在干什么、接下来会发生什么你就已经通过了JVM调优这一关。后面即使遇到更复杂的场景只要排查链路清晰、监控数据完整就不会慌。