1. 一次线上事故逼我系统啃完了 JVM去年春天我们一个核心服务在凌晨 3 点 12 分突然 OOM监控告警瞬间刷了满屏。当时我还在睡梦中被值班电话叫醒打开电脑一看GC 日志里 Full GC 几乎每秒一次堆内存直接打满服务彻底卡死用户请求全部超时。那次事故持续了 40 多分钟业务损失不小。事后复盘时我发现问题根源其实早就有征兆年轻代一直在疯狂晋升对象老年代持续增长但我从来没认真看过 GC 日志更没做过系统的 JVM 参数分析。那次之后我花了两周时间把线上服务从 OOM 排查到 GC 优化完整走了一遍顺手把另外几个服务的隐患也一起处理了。这套方案上线后系统稳定运行了一年多再没出过内存问题。这篇文章就是我当时实战过程的完整记录整理成 5 个真实案例有 OOM 现场排查、有 GC 频率异常分析、有参数调优前后的对比数据也有我踩过的坑。如果你也在维护 Java 服务希望这篇能帮你少走点弯路。2. 案例一一次典型 OOM我用 4 步定位真凶2.1 事故现场的初步判断那天接到告警后我做的第一件事不是看代码而是先看服务器上还在不在的现场。很多人遇到 OOM 第一反应就是重启服务——这确实能最快恢复业务但代价是丢掉了最宝贵的排查线索。堆转储文件、GC 日志、线程栈这些是判断根因的核心证据一旦重启就全没了。我当时运气还算好JVM 在 OOM 前自动生成了java_pid12345.hprof文件GC 日志也完整保留着。我先用jstat -gcutil pid看了一眼当时的 GC 情况发现老年代使用率已经 99%Full GC 次数在几分钟内从几十次飙升到上千次。这是个非常典型的信号堆基本被占满了每次 Full GC 已经无法回收任何有效空间。接着我用jmap -dump:formatb,fileheap.hprof pid手动补了一份堆转储然后去分析这份 dump。这里有个细节如果服务还能响应 jmap 命令就优先手动 dump因为 JVM 自动生成的 hprof 有时会因为内存耗尽而内容不完整。2.2 内存分析工具的选择与使用堆转储文件拿到手后我用的是 Eclipse MATMemory Analyzer来分析。打开文件后我习惯先看Dominator Tree支配树它能直观地展示哪个对象占用了最多的保留堆内存。当时结果非常明显一个ArrayList实例占了堆内存的 76%里面有 300 多万个对象。顺着引用链往下追我发现这个 List 挂在某个定时任务的数据缓存字段上。定时任务每小时跑一次把数据库里全量用户数据查出来塞进这个 List再配合一个线程池并发处理。问题在于数据量早就不像上线时那么小了——从最初几万条涨到了百万级而缓存没有做上限控制处理速度又跟不上写入速度积压越来越严重最终把堆打爆。这里有个重要的排查思路不要一上来就怀疑代码写得有问题先确认是谁占了内存再确认为什么它占了这么多。MAT 的 Leak Suspects泄漏嫌疑报告能自动帮你算个大概方向但最终还是要看支配树和引用链确认。提示MAT 分析大堆转储文件会比较吃内存一般建议给 MAT 本身加大-Xmx参数。比如分析 8GB 的 hprofMAT 至少要 6GB 堆否则分析过程中直接就 OOM 了。2.3 防止同类问题再次发生的两个改动定位到内存泄漏点后我做了两个改动都不复杂但很有效给缓存加容量上限用Guava Cache代替原来的ArrayList配置maximumSize(50000)和基于访问时间的过期策略避免无界增长。优化批量处理逻辑原来是一次性全量加载再处理改成分批拉取每批处理 1000 条就提交一次避免数据长时间驻留在堆里。这两个改动上线后老年代使用率从 99% 降到了稳定在 45%~55% 之间Full GC 从每小时上百次降到了每几小时一两次的程度。内存问题算是解决了但这只是开始——我意识到 GC 本身还有很大的优化空间。3. 案例二GC 日志里的门道G1 和 CMS 该怎么选3.1 GC 日志怎么看才高效排查 OOM 之后我养成了一个习惯所有核心服务的启动参数里必须显式开启 GC 日志。这一步太重要了因为很多问题是慢慢积累的等你发现的时候已经来不及找现场了。以 JDK 8 为例我当时用的参数是-Xloggc:/data/logs/gc-%t.log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps如果是 JDK 11建议直接用统一的日志模式-Xlog:gc*:/data/logs/gc-%t.log:time,uptime,level,tags拿到 GC 日志后我先不急着看某一行的具体内容而是先整体扫一眼几个关键指标Young GC 频率如果每秒甚至每几百毫秒就触发一次说明年轻代太小或者分配速率过高。晋升对象大小日志里会标注desired survivor size和每次 GC 后存活对象的大小如果每次都有大量对象进入老年代说明 survivor 区配置不合理或者对象确实是大对象。Full GC 停顿时间CMS 的 Full GC 如果超过 1 秒G1 的 Mixed GC 如果超过几百毫秒都要重点关注。3.2 CMS 与 G1 的取舍思路我们团队当时有两个服务一个用 CMS一个用 G1我正好做了对比。CMS 的优点是停顿时间相对可控且短缺点是会产生内存碎片老年代碎片化严重时 JVM 会退化成 Serial Old GC停顿时间反而会爆炸。G1 的优势是把堆划分为 Region可以预测停顿时间通过-XX:MaxGCPauseMillis设置而且能并行处理适合大堆场景。如果你有一个 16GB 堆的服务用 CMS 在遭遇碎片化退化之后一次 Full GC 可能停顿十几秒甚至更久而 G1 配合合理的MaxGCPauseMillis通常能把单次 GC 停顿控制在 200ms 以内。这不是说 CMS 一无是处对小堆比如 4GB 以下、低延迟场景CMS 调好了依然很能打。我当时给那个核心服务的最终配置是这样的-Xms8g -Xmx8g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:ParallelGCThreads8 -XX:ConcGCThreads4 -XX:InitiatingHeapOccupancyPercent45 -XX:G1NewSizePercent10 -XX:G1HeapRegionSize4m注意-Xms和-Xmx建议设为相同值避免运行时频繁扩容和缩容带来的系统调用和内存震荡。这是很基础但很多人忽略的点。4. 案例三一个 Full GC 频繁的服务用 Mat 定位到线程池问题4.1 现象Full GC 每 3 分钟一次服务还能跑但越来越慢第二个案例是一个支付回调服务现象不像 OOM 那么猛烈但很折磨人。Full GC 每 3 分钟左右就来一次每次停顿 1~2 秒服务勉强能响应但接口耗时不断上涨超时率慢慢攀升到 10% 以上。我先用jstat -gcutil pid追踪了几个数据点发现一个可疑规律每次 Full GC 之后老年代空出来的空间很快又被填满。这说明有大量生命周期很长的对象在持续产生——不是临时的缓存而是某种结构性泄漏。然后我看了线程栈。这个操作很关键我连续抓了 3 次线程快照间隔 5 秒用jstack -l pid thread_$(date %s).txt保存下来然后用top -Hp pid找到 CPU 占用高的线程号转成十六进制后在线程栈里反查。4.2 定位到线程池里吃完不吐的对象几次线程快照让我发现一个业务线程池的活跃线程几乎全部卡在某个数据库查询方法上。查询方法会构造一个大型的结果集对象这个对象被存储在 ThreadLocal 里而 ThreadLocal 没有在任务结束后清理。如果只是 ThreadLocal 泄漏那对象会随着线程池线程的存活而一直留在堆里。当你用jmap -histo:live pid看对象存活分布时会发现某个业务对象比如PaymentResultVO的存活数量和一个线程池里的线程数保持一致而且只增不减。我当时的修复方案很直接在任务结束时显式调用ThreadLocal.remove()清理当前线程的上下文数据。排查了连接池和 HTTP 客户端池给所有池化资源设置了空闲回收时间避免池中的对象长期霸占内存。修改之后我观察了 48 小时Full GC 频率从每 3 分钟一次降到了每 30 分钟一次接口 P99 耗时从 800ms 降到了 300ms 以内。4.3 排查线程池问题的一个小技巧线程池配合 ThreadLocal 是 Java 服务端非常经典的内存问题场景因为线程池里的线程是复用的ThreadLocal 里的值不会随任务结束自动清空。写代码时养成一个习惯只要是线程池里跑的任务要么不用 ThreadLocal要么在 finally 块里 remove。5. 案例四参数调优不是玄学我做了三轮对比实验5.1 调优前的数据基线与目标设定很多人调 JVM 参数是听说哪个参数好就加上没有基线也没有目标。这种做法最大的问题是你不知道自己改完是变好还是变坏。我在实际调优时非常重视控制变量和数据对比。调优前我记录了这些基线数据Young GC 平均间隔约 2 秒一次Young GC 平均耗时约 50msFull GC 频率每 10~15 分钟一次Full GC 平均停顿约 1.8 秒接口 P99 耗时600ms堆内存总用量8GB 中常驻 6GB 左右目标在保证业务稳定和不加机器的情况下把 Full GC 频率降低到每小时 1 次以内P99 降到 300ms 以内。5.2 三轮优化过程与参数对比第一轮调整堆大小和年轻代比例。原来是-Xmx4g我改成了-Xms8g -Xmx8g然后把-XX:NewRatio从默认的 2 调整为 3即年轻代占堆的 1/3。这轮的效果很明显Young GC 间隔从 2 秒拉长到了 7 秒左右因为年轻代大了对象能多活一会儿晋升老年代的频率也降低了。第二轮调整 G1 相关的触发时机。我把-XX:InitiatingHeapOccupancyPercent从默认的 45 调整为 35让 G1 更早地开始并发标记提前准备混合回收。很多人不敢改这个参数怕频繁触发 GC。实际测试下来对于对象分配速率较快的服务提前触发反而能减少 Full GC 退化的概率因为并发标记有充足时间跑完。第三轮调整 Surivivor 区和晋升阈值。我把-XX:MaxTenuringThreshold从默认的 15 调整为 8并搭配-XX:SurvivorRatio6。这轮的逻辑是让大部分短期对象在年轻代就被回收只有真正长命的对象才进入老年代。调整后存活对象进入老年代的量明显减少老年代增长率稳定下来。三轮调整后的数据对比如下指标调优前调优后Young GC 频率2 秒/次10~12 秒/次Full GC 频率10~15 分钟/次约 1 次/小时Full GC 平均停顿1.8 秒300ms 左右接口 P99600ms280ms5.3 调优时最重要的一条原则每次只改一个参数改完观察至少 24 小时再动下一个。你一次性改五六个参数出问题了根本分不清是谁的锅。我当时就是严格按照这个原则每轮只出一版配置跑一天线上观察记录数据再进入下一轮。6. 案例五运行一年后复盘我把这套方法论沉淀成了清单系统稳定运行一年多之后我回头复盘发现真正有价值的不是某一次参数调整而是整套排查流程和指标体系。我把它们整理成了一份检查清单现在每次接手新服务或做性能评估时都会用它。6.1 OOM 排查清单是否开启了 GC 日志保留策略日志文件能保留多久是否配置了-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPathOOM 发生后是否有自动告警和通知机制堆转储文件是否定期清理占用磁盘空间是否可控是否有定期的人工或自动化堆内存分析计划6.2 GC 优化清单是否明确知道当前服务的 Young GC 和 Full GC 频率基线是否清楚老年代增长的主要来源大对象、ThreadLocal、缓存是否给 JVM 设置了堆大小上下限一致G1 的 RegionSize 是否和存活对象大小匹配是否设置了合理的MaxGCPauseMillis目标是否有针对大对象的专门排查策略比如直接看分配大小超过 Region 一半的对象有一条我现在特别强调的经验是把监控粒度细化到线程池和数据库连接池级别。很多 OOM 和 GC 问题表面上像是 JVM 的事实际上是代码里某个阻塞或泄漏拖垮了 JVM。线上监控不仅要看 JVM 指标还要看线程池队列深度、连接池活跃数、数据库慢查询数量。6.3 我强烈建议你做的三件小事给自己保留一个 7 天的 GC 日志滚动窗口用loggc的%t时间戳命名配合日志轮转脚本。每个月挑一天用jstat看一次服务的 GC 曲线10 分钟就能发现潜在风险。新服务上线前先压一轮内存分配速率的测试摸清这个服务的内存吞吐量上限这样后面调参数时心里有底。7. 写在最后JVM 调优的两个常见误区我在这一年里见过不少团队在处理 JVM 问题时陷入两个极端。第一个极端是把 JVM 参数当成万能药。遇到 OOM 就加内存遇到 Full GC 频繁就调 G1 参数结果内存加到 32GB 照样 Full GC。原因很简单你的问题根本不在 JVM 参数而在于代码不停地在制造垃圾。参数调优只是锦上添花代码质量才是核心。第二个极端是只看结果指标不看过程指标。有些人看到 Full GC 少了就觉得调好了却不知道停顿时间是涨了还是降了。我建议你把GC 次数和GC 总停顿时间一起看用GC 总停顿时间 / 运行时长来衡量 JVM 性能而不是只看单一指标。最后分享一个小小的实操心得调 JVM 参数之前先把jstat -gcutil的结果存成文件哪怕只是间隔 10 秒取一次、持续取 30 分钟这个数据就是你判断优化效果的最硬依据。做技术优化数据和现场永远比感觉可靠。