1. 项目概述从“救火”到“治未病”的JVM调优观干了这么多年Java后端要说最让人头疼又最有成就感的恐怕就是处理线上JVM问题了。它不像业务逻辑Bug有清晰的堆栈和日志可循。JVM问题更像一个“黑盒”表象是服务卡顿、接口超时、甚至直接宕机但根因可能深埋在内存分配、垃圾回收或者线程调度的某个角落。我经历过无数次凌晨被报警电话叫醒盯着满屏的GC日志和监控曲线一点点抽丝剥茧的经历。今天我不打算讲那些教科书上的JVM内存模型虽然它很重要而是想结合我踩过的坑和积累的经验聊聊如何系统性地分析、定位并最终解决那些棘手的JVM性能问题比如频繁的Full GC、内存泄漏、乃至诡异的CPU飙高。我们的目标是从被动的“救火队员”转变为主动的“性能医生”建立一套可复用的“治未病”的调优方法论。2. 核心问题定位与监控体系建设2.1 构建多层次监控与告警感知在问题发生之前或者说在问题被用户感知之前我们就要能发现它。这依赖于一个立体的监控体系。首先基础的系统监控CPU、内存、磁盘I/O、网络是底线任何JVM层面的严重问题最终都会反映在这里。其次是应用层的监控比如应用的QPS、响应时间RT、错误率。最后才是JVM自身的监控这是最直接的。我习惯部署的监控组合是Prometheus Grafana 用于收集和展示系统及JVM指标通过JMX Exporter暴露JVM数据再配合APM工具如SkyWalking、Arthas的在线诊断能力进行更细粒度的链路追踪和方法级耗时分析。关键是要设置合理的告警阈值。比如Old Gen老年代使用率持续超过80%就告警而不是等到95%以上Young GC年轻代GC频率突然从每分钟几次飙升到每分钟几十次即使RT还没明显变化也值得立即关注。这种“前兆性”告警能为我们争取宝贵的分析时间。2.2 问题现象与根因的初步关联当告警响起我们首先需要根据现象快速归类。这里有个简单的速查表问题现象可能根因方向首要排查工具/命令CPU使用率持续100%1. 频繁GC特别是Full GC2. 代码中存在死循环或低效算法3. 大量线程竞争锁锁膨胀top -Hp [pid]查看线程CPUjstack [pid]抓取线程栈服务响应变慢但CPU和内存不高1. 外部依赖DB、Redis、下游服务慢2. 应用内部锁竞争如synchronized、ReentrantLock导致线程等待3. 过多的日志打印尤其是同步日志且级别为INFO/DEBUG阻塞业务线程链路追踪(APM)、jstack分析线程状态重点关注BLOCKED,WAITING内存使用率持续攀升最终OOM1.内存泄漏对象被意外引用无法回收2. 内存分配不足或GC参数不合理如Survivor区过小导致对象过早进入老年代3. 加载了过量数据到内存如一次性查询全表jmap -histo:live [pid]查看对象直方图jmap -dump生成堆转储文件用MAT分析频繁Full GC1. 老年代空间不足可能是内存泄漏也可能是Young GC后存活对象过多2. 显示调用System.gc()3. Metaspace元空间或直接内存不足jstat -gcutil [pid] 1000动态观察GC各分区使用率查看GC日志注意这个关联表只是一个起点真实情况往往更复杂可能是多个原因交织。比如一个内存泄漏会导致老年代慢慢被填满进而触发越来越频繁的Full GC而频繁的Full GC会疯狂消耗CPU最终表现为CPU飙高和服务卡顿。所以我们需要顺着线索链往下挖。3. 内存问题深度分析与工具实战内存问题是JVM调优的重中之重其核心矛盾是在有限的物理内存内平衡对象分配速度、垃圾回收效率和停顿时间STW。3.1 堆内存泄漏的排查“三板斧”怀疑内存泄漏时我通常会按以下顺序操作这套流程在多数场景下都有效第一板斧实时观察与初步定位使用jmap -histo:live pid命令。这个命令会触发一次Full GC然后统计存活对象的数量和大小。多次执行比如间隔10分钟观察哪些类的实例数instances和总大小bytes在持续增长且不符合业务逻辑预期。增长最快的类往往是嫌疑犯。但要注意-histo:live会触发STW对线上服务有影响需谨慎。第二板斧离线堆转储分析如果通过jmap -histo找到了可疑类或者问题需要更精确的引用链分析就需要生成堆转储文件Heap Dump。命令是jmap -dump:live,formatb,fileheap.hprof pid。这个文件通常很大需要下载到本地用专业工具分析。 我主要用Eclipse Memory Analyzer Tool (MAT)。导入dump文件后有几个关键动作Leak Suspects ReportMAT会自动生成泄漏嫌疑报告非常直观经常能直接指出问题。Dominator Tree支配树视图。这里列出了占用内存最大的对象以及谁“支配”着它们即谁在引用它们导致它们无法被回收。右键对象选择Path To GC Roots-exclude weak/soft references可以查看阻止该对象被回收的强引用链。这是定位内存泄漏根源的杀手锏。OQLObject Query Language类似于SQL可以编写查询语句来查找特定模式的对象非常灵活。第三板斧结合代码与业务逻辑工具给出的线索必须结合代码来验证。常见的泄漏模式有静态集合类滥用如static Map缓存了用户会话数据只放不删。线程局部变量ThreadLocal未清理特别是在使用线程池时线程是复用的ThreadLocal里的数据会一直累积。监听器或回调未注销注册了监听器但在对象销毁时忘记移除。内部类持有外部类引用非静态内部类会隐式持有外部类实例如果这个内部类对象被长生命周期对象引用就会导致外部类也无法释放。实操心得分析堆dump时不要只看最大的单个对象更要关注“积累型”的对象集合。比如一个HashMap本身不大但它里面存了100万个String键值对这才是内存消耗的主体。在MAT的支配树里这个HashMap就是“支配者”。3.2 非堆内存与直接内存问题除了堆内存Metaspace存放类元信息和直接内存Direct Buffer常用于NIO也会出问题。Metaspace OOM通常是因为动态生成了大量类如大量使用CGLib、ASM进行字节码增强的框架或者Groovy等脚本引擎或者部署了多个不同版本的同类应用导致类加载器冲突。排查时可以用jmap -clstats pid查看类加载器统计或者通过-XX:NativeMemoryTrackingdetail参数开启NMT来追踪。直接内存溢出症状可能是堆内存还很充裕但进程却因为OutOfMemoryError崩溃且错误信息可能指向Direct buffer memory。排查起来比较麻烦因为标准的堆dump不包含这部分。可以借助NMT或者使用jcmd pid VM.native_memory summary命令来查看。常见原因是使用了Netty等NIO框架分配了直接内存但未正确释放或者-XX:MaxDirectMemorySize参数设置过小。4. GC性能调优与参数实战调优GC不是简单地套用“最优参数”而是根据应用特点吞吐量优先还是低延迟优先和硬件资源做权衡和适配。4.1 GC日志一切分析的起点没有GC日志的调优就是盲人摸象。务必在启动参数中加上日志输出-Xlog:gc*,gcheapdebug,gcagetrace:filegc.log:time,uptime,level,tags:filecount10,filesize100M这是JDK 9的Unified Logging格式。如果是JDK 8可以使用-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:gc.log关键信息要看GC类型Young GC/Full GC、触发原因Allocation Failure/Metadata GC Threshold等、GC前后各分区大小、GC耗时、用户耗时/系统耗时。4.2 分代大小与关键参数调整以最常用的G1 GCJDK 9默认和CMS GCJDK 8及以前常用为例讲几个核心参数的调整思路1. 堆总大小-Xms, -Xmx必须设置成一样避免运行时堆伸缩带来的性能损耗。通常设置为物理内存的50%-70%留出空间给操作系统、线程栈、直接内存等。2. 年轻代大小这是GC发生最频繁的区域。G1G1不再固定年轻代大小而是通过-XX:MaxGCPauseMillis目标最大停顿时间如200ms和-XX:G1NewSizePercent/-XX:G1MaxNewSizePercent年轻代占比范围默认5%-60%来动态调整。如果Young GC太频繁可以适当提高-XX:G1NewSizePercent的初始值。CMS需要手动设置-Xmn或-XX:NewRatio。一个经验公式年轻代大小应能容纳应用在峰值流量下1-1.5秒内创建的所有对象。可以通过观察GC日志中Young GC的频率来反推。3. Survivor区与晋升阈值 对象在年轻代的Eden区分配经过一次Young GC后存活的对象会移到Survivor区S0/S1。每经历一次Young GC对象的年龄就加1当年龄超过阈值-XX:MaxTenuringThreshold默认15时晋升到老年代。问题如果Survivor区空间太小会导致一些“朝生夕死”的对象还没熬过几次GC就被迫提前晋升到老年代加速老年代填满触发Full GC。调整使用-XX:PrintTenuringDistribution查看年龄分布。如果发现有很多年龄很小比如1或2的对象就晋升了说明Survivor区可能不足或晋升阈值太低。可以尝试增大Survivor区比例-XX:SurvivorRatio默认8表示Eden:Survivor8:1:1减小这个值会增大Survivor或适当提高MaxTenuringThreshold。4. 针对Full GC的优化CMSCMS的并发收集失败是Full GC的主因之一。确保有足够的堆空间并给CMS的并发标记阶段留足时间。关注-XX:CMSInitiatingOccupancyFraction老年代使用率触发CMS的阈值如75%设置过高可能导致并发模式失败过低则CMS过于频繁。G1G1的Full GCSerial GC是单线程的灾难性的。要极力避免。核心是避免疏散失败和大对象分配失败。确保-XX:G1ReservePercent默认为10%有足够空间作为疏散时的备用区域。对于大对象可以使用-XX:G1HeapRegionSize调整Region大小如设置为16M并避免分配超过Region一半大小的对象。踩坑记录有一次线上服务频繁Full GCGC日志显示是“Metadata GC Threshold”触发的。这不是堆内存问题而是Metaspace。检查发现是某个组件动态生成了大量代理类。临时解决方案是增大-XX:MaxMetaspaceSize之前没设置默认是无限大但会受限于物理内存长期方案是修复该组件的使用方式避免类爆炸。5. 高CPU与死锁问题排查实战5.1 CPU 100%问题排查流程定位高CPU线程top -Hp java_pid找到消耗CPU最高的线程ID十进制。线程ID转换将十进制线程ID转为十六进制printf “%x\n” tid。分析线程栈jstack java_pid thread_dump.txt在生成的dump文件中用十六进制的线程ID搜索找到对应的线程栈信息。解读栈信息如果栈顶是GC task thread说明是垃圾回收线程在忙碌根源还是内存或GC问题。如果栈顶是应用代码且停留在某个循环或复杂计算那就是代码逻辑问题。如果线程状态是RUNNABLE且持有锁同时其他很多线程状态是BLOCKED等待同一把锁那很可能发生了锁竞争或死锁。5.2 死锁检测与分析方法死锁不一定导致CPU高但必然导致相关线程停滞影响吞吐量。jstack命令的输出末尾会自动检测并报告发现的死锁。例如Found one Java-level deadlock: ... Thread-1 waiting to lock monitor 0x00007f0c4800a2b8 (object 0x000000076acf3e58, a java.lang.Object), which is held by Thread-0 Thread-0 waiting to lock monitor 0x00007f0c4800a2b8 (object 0x000000076acf3e60, a java.lang.Object), which is held by Thread-1这清晰地展示了两个线程Thread-0和Thread-1互相等待对方持有的锁形成了环路等待。解决方法就是审视代码中的锁获取顺序确保所有线程都以全局一致的顺序获取锁这是打破死锁必要条件“循环等待”的最有效方法。对于更复杂的锁竞争非死锁但性能差可以使用jstack多抓取几次线程快照比如间隔5秒抓3次然后分析线程状态的变化。如果大量线程长时间处于BLOCKED状态说明锁的粒度太粗或竞争太激烈需要考虑锁细化、改用并发集合如ConcurrentHashMap、或使用无锁编程范式。6. 线上问题排查工具箱与技巧除了上面提到的jmap,jstack,jstat还有一些强大的工具和技巧Arthas阿尔萨斯阿里开源的在线诊断工具堪称神器。它不需要修改代码或重启服务。常用命令dashboard实时仪表盘一览系统状态。thread -n 3查看最忙的3个线程。watch com.example.ClassName methodName {params,returnObj,throwExp} -x 3动态观察方法入参、返回值和异常。ognl执行OGNL表达式动态查看或修改静态变量慎用。jad反编译线上代码确认实际运行的版本。 它的强大之处在于能让你像在本地调试一样观察线上运行中的程序。jcmdJDK自带的多功能命令。jcmd pid help可以查看所有支持的命令。比如jcmd pid GC.heap_info查看堆信息jcmd pid VM.flags查看所有JVM参数。持续Profiling对于间歇性的、难以复现的性能问题可以引入持续性能剖析工具如Async-Profiler。它可以以极低的开销通常2%持续采集CPU、内存分配、锁竞争的火焰图Flame Graph。火焰图能直观地告诉你CPU时间都花在了哪个方法上是定位“热点”代码的终极武器。最后分享一个排查心法面对复杂的JVM问题一定要有“分治”和“假设-验证”的思路。先通过监控和日志将问题范围缩小到内存、GC、CPU、线程中的某一个或几个领域。然后提出最可能的假设比如“是内存泄漏导致老年代满进而触发Full GC”再使用对应的工具jmap,jstat去验证这个假设。如果验证不通过就修正假设继续排查。保持耐心数据日志、dump文件永远比直觉更可靠。每一次成功的线上问题排查都是对系统理解的一次深刻升级。