1. 问题引入当你的Java服务突然“高烧不退”做后端开发的朋友尤其是负责线上服务的估计都经历过这种心跳加速的时刻监控大盘上某个服务的CPU使用率曲线突然拉出一条陡峭的直线直奔90%甚至100%或者内存占用像坐了火箭一样持续攀升直至触发告警。这时候整个团队的气氛都会瞬间紧张起来因为这通常意味着服务响应变慢、接口超时甚至可能引发雪崩导致整个系统不可用。CPU或内存使用率过高是Java应用线上最常见的性能问题之一。它不像空指针异常那样有明确的错误堆栈更像是一种“亚健康”状态的表征背后可能隐藏着代码逻辑缺陷、资源泄漏、不合理的配置甚至是外部依赖的异常。很多新手面对这种问题会感到无从下手要么重启大法好治标不治本要么在浩如烟海的日志里大海捞针效率极低。今天我就结合自己多年处理这类问题的经验整理出一套从现象到根因的“临床诊断”流程。这不是一份简单的命令列表而是一套完整的排查思路和实战心法。我会带你像侦探一样从监控指标这个“案发现场”出发利用各种“刑侦工具”JDK自带命令、Arthas、Profiler等层层递进最终锁定并解决那个消耗资源的“元凶”。无论你是刚接触线上问题的初级工程师还是想系统化自己排查思路的资深开发者相信这套方法都能给你带来实实在在的帮助。2. 初步诊断建立问题画像与缩小排查范围当告警响起我们首先需要冷静下来快速建立一个清晰的问题画像。盲目地登录服务器一顿top、jstack乱敲往往事倍功半。2.1 区分问题类型CPU vs. 内存这是排查的第一步方向错了后续努力全白费。CPU使用率高的典型表现是系统负载Load Average飙升应用线程池活跃线程数打满接口响应时间RT变长但可能不会立即OOM。其根本原因通常是“计算密集型”任务比如死循环代码逻辑缺陷导致某个线程无法退出循环。频繁的GC特别是Full GC会“Stop The World”导致所有工作线程暂停CPU资源被GC线程大量占用。锁竞争激烈大量线程在等待锁如synchronized、ReentrantLock处于BLOCKED状态虽然不直接消耗CPU但会导致线程上下文切换频繁间接推高CPU。算法复杂度高某个业务逻辑使用了不合理的算法在处理特定数据时爆发。内存使用率高的典型表现是JVM堆内存使用率持续增长即使多次Full GC也无法有效回收最终触发OutOfMemoryError。其根本原因通常是“内存泄漏”或“内存溢出”内存泄漏对象被无意中如通过静态集合、缓存长期持有无法被GC回收随着时间推移累积最终耗尽内存。这是最常见、也最棘手的问题。内存溢出一次性申请过大的对象如大文件读入内存、不合理的堆内存设置-Xmx太小等。实操心得很多时候CPU和内存问题会相互诱发。例如内存泄漏导致频繁Full GC进而引起CPU飙升或者某个CPU密集型任务创建了大量临时对象加速了GC频率。所以要保持关联思考。2.2 收集关键现场信息在采取任何可能破坏现场的措施如重启之前尽可能多地收集信息。系统层面top -Hp java_pid查看该Java进程内各个线程的CPU占用情况。记住占用最高的那个线程IDPID将其转换为十六进制后面会用到。vmstat 2 5查看系统整体的CPU、内存、IO和上下文切换cs情况。如果cs值异常高可能暗示锁竞争。free -m查看系统整体内存使用情况确认是否是物理内存不足。JVM层面jstat -gcutil java_pid 1000 10每隔1秒输出一次GC统计共10次。重点观察FGCFull GC次数和FGCTFull GC总耗时是否在频繁增长。如果OU老年代使用率一直很高且Full GC后回收很少基本可以断定是老年代内存泄漏。jmap -heap java_pid快速查看堆内存各区域的配置和使用情况概览。通过以上信息你应该能对问题是偏CPU型还是内存型有一个初步判断并锁定几个可疑的高资源消耗线程。接下来我们就进入深度排查环节。3. 深度排查CPU使用率过高问题假设我们通过top -Hp发现某个Java线程假设系统PID为12345持续占用接近100%的CPU。我们的目标是找到这个线程在执行什么代码。3.1 使用 jstack 定位热点线程jstack是JDK自带的线程堆栈转储工具。我们需要将高CPU线程的系统PID十进制转换为十六进制。printf “%x\n” 12345得到十六进制线程ID0x3039。jstack java_pid jstack.log导出所有线程堆栈。在jstack.log文件中搜索nid0x3039。nid即Native Thread ID就是我们要找的线程。“Thread-1” #10 prio5 os_prio0 tid0x00007f48740e4800 nid0x3039 runnable [0x00007f486fefd000] java.lang.Thread.State: RUNNABLE at com.example.ExpensiveService.calculate(ExpensiveService.java:25) // 高CPU方法 at com.example.ExpensiveService.lambda$start$0(ExpensiveService.java:18) at com.example.ExpensiveService$$Lambda$1/2074407503.run(Unknown Source) at java.lang.Thread.run(Thread.java:748)找到它了堆栈显示这个线程正在执行com.example.ExpensiveService.calculate方法并且状态是RUNNABLE正在运行或等待CPU调度。这很可能就是热点代码。但是这里有一个巨大的坑jstack输出的是瞬间快照。如果这个高CPU线程正好在等待IO状态是RUNNABLE但实际在等系统调用返回或者你的jstack命令执行时它刚好没在计算你就可能抓不到真正的热点。因此单次jstack的结果可能具有偶然性。避坑指南务必多次如3-5次执行jstack并对比这几次的日志。如果同一个线程nid相同的堆栈顶部始终指向相同或相似的方法那么这就是铁证。如果每次堆栈都不同则可能是多个线程在交替消耗CPU或者问题不在于某个死循环而在于频繁的锁竞争或GC。3.2 使用 Arthas 进行动态诊断jstack是静态的而阿里开源的Arthas则是动态诊断的神器。它可以在不重启应用的情况下进行更细致的分析。启动Arthas并attach到目标进程java -jar arthas-boot.jar然后选择对应的Java进程编号。使用thread命令查看线程thread查看所有线程信息。thread -n 3查看最忙的3个线程。thread java_pid查看指定线程的堆栈。 Arthas会自动高亮显示CPU消耗高的线程比手动查jstack方便得多。使用profiler命令进行CPU采样分析终极武器 如果代码逻辑复杂单纯看线程堆栈可能难以定位到具体的代码行。这时可以使用CPU性能分析工具。profiler start开始采样。等待一段时间比如30秒让profiler收集足够的数据。profiler stop --format html停止采样并生成HTML格式的火焰图。 火焰图Flame Graph是可视化CPU调用栈的利器。y轴表示调用栈深度x轴表示采样到的次数即CPU时间。最顶层的哪个“平顶山”最宽哪个就是最消耗CPU的函数。你可以直观地看到从底层方法到顶层方法的完整调用链精准定位热点。3.3 排查其他常见CPU问题场景频繁GC导致的CPU高如果jstat显示FGC/FGCT增长很快那么CPU很可能被GC线程占用。此时需要结合内存排查方法见下一节重点分析是什么对象导致老年代无法回收。锁竞争导致的CPU高使用jstack查看大量线程状态是否为BLOCKED (on object monitor)并注意等待的锁对象。Arthas的monitor、watch命令可以监控方法调用和耗时帮助定位锁竞争点。无限循环/递归代码逻辑Bug。通过上述线程堆栈分析通常能找到源头检查循环条件或递归终止条件。4. 深度排查内存使用率过高问题内存问题的排查核心思路是分析堆内存里到底存了些什么对象是谁在引用它们导致GC无法回收。4.1 生成与分析堆转储文件Heap Dump堆转储是JVM堆内存在某一个时刻的完整快照。这是分析内存问题最直接、最有力的证据。生成Heap Dump的几种方式主动触发推荐jmap -dump:live,formatb,fileheap.hprof java_pid使用Arthasheapdump /tmp/heap.hprof在JVM启动参数中添加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump这样当发生OOM时会自动生成dump文件能捕获到“案发”瞬间的状态极其珍贵。重要提示jmap -dump命令在堆很大时几十GB可能会使JVM停顿STW数秒甚至更久对线上服务有影响。尽量在流量低峰期或测试环境操作。-dump:live参数表示只dump存活的对象能减小文件体积。分析Heap Dump的工具生成的hprof文件需要用专业工具打开分析。Eclipse MAT (Memory Analyzer Tool)功能最强大是首选。它能自动分析泄漏疑点Leak Suspects生成支配树Dominator Tree直观地展示哪些对象持有最大的内存。JVisualVM (JDK自带)轻量级查看类实例数和大小比较方便。JProfiler, YourKit商业工具功能全面分析体验更好。4.2 使用MAT进行实战分析假设我们已经拿到了一个heap.hprof文件并用MAT打开。查看概览与泄漏疑点报告打开后MAT通常会提供一个“Leak Suspects”报告。这个报告是MAT根据经验规则自动分析的经常能直接指出问题所在比如“一个java.lang.Thread实例通过局部变量保持着大量对象占用了98%的堆内存”。这个线索非常宝贵。分析支配树Dominator Tree这是MAT的核心功能。在支配树视图中对象A支配对象B意味着如果A被垃圾回收B也一定可以被回收。通常内存泄漏的根源就是那些支配了大量内存的“GC Root”对象。按“Retained Heap”支配的内存大小排序排在最前面的几个类就是重点怀疑对象。查看类直方图Histogram列出所有类的实例数量和总大小。重点关注char[],byte[],String, 以及你自己业务中可能大量创建的对象类。对比正常情况下的直方图如果某个类的实例数异常多就是突破口。追踪引用链Path to GC Roots右键点击可疑的类或对象实例选择“Merge Shortest Paths to GC Roots” - “exclude all phantom/weak/soft etc. references”。这个操作会显示从该对象到GC Roots如静态变量、活动线程栈、JNI引用等的完整引用链。内存泄漏的本质就是一条不该存在的、从GC Root出发的强引用链。通过这条链你就能找到是哪个全局的Map、List或者静态变量持有了这些本该回收的对象。4.3 使用 jmap 和 jhat 进行快速命令行分析如果不想打开图形化工具可以用命令行工具快速浏览。jmap -histo:live java_pid查看存活对象的直方图能快速看到哪个类的实例最多。注意这个命令也会触发Full GC。jhat heap.hprof启动一个简单的HTTP服务器来分析dump文件可以通过浏览器访问。功能比MAT弱但适合在无GUI的服务器上快速检查。4.4 常见内存泄漏模式静态集合类最经典的泄漏。例如一个static Map缓存了用户信息只加不删或者用对象本身做Key但重写了hashCode没重写equals导致无法正确取出和删除。连接未关闭数据库连接Connection、网络连接Socket、文件流FileInputStream等必须在使用后显式关闭或在try-with-resources中自动关闭否则它们持有的底层资源不会被释放。监听器与回调注册了监听器如事件监听器但未注销导致监听器对象一直被事件源持有。ThreadLocal使用不当ThreadLocal变量在线程池场景下是重灾区。线程池的核心线程会一直存活如果使用了ThreadLocal并且没有在任务结束后调用remove()清理那么ThreadLocal中存储的对象就会一直存在造成泄漏。内部类持有外部类引用非静态内部类会隐式持有外部类的引用。如果这个内部类的实例生命周期长于外部类比如被放入了全局缓存就会导致外部类实例也无法被回收。5. 进阶工具与预防策略除了上述“救火”工具我们还需要一些“防火”和“预警”的手段。5.1 使用JMC与飞行记录器进行持续 profilingJava Mission Control (JMC) 和 Java Flight Recorder (JFR) 是Oracle JDK及OpenJDK某些版本提供的强大性能监控和剖析工具对性能影响极小通常1%适合在生产环境长期开启。开启JFR在JVM启动参数中添加-XX:FlightRecorder -XX:StartFlightRecordingduration60s,filenamemyrecording.jfr可以录制一段时间内的JVM详细数据。使用JMC分析用JMC打开.jfr文件你可以看到方法热点精确到方法级别的CPU消耗排行。对象分配压力哪些方法在大量创建对象。锁竞争详情哪些锁被争用等待时间多长。GC活动详情每次GC的暂停时间、回收量等。 JFR提供的是一个时间窗口内的连续视图对于诊断间歇性、偶发性的性能问题比瞬间快照工具更有效。5.2 建立有效的监控与告警体系“防患于未然”远比“亡羊补牢”重要。核心指标监控JVM层面堆内存各区域使用率、GC频率与耗时、活跃线程数、死锁检测。系统层面宿主机的CPU、内存、磁盘IO、网络IO。应用层面关键接口的QPS、RT、错误率。 使用Prometheus Grafana 或 商业APM如SkyWalking, Pinpoint来收集和展示这些指标。设置合理的告警阈值不要只盯着100%。例如设置老年代使用率超过80%持续5分钟告警Full GC频率每分钟超过2次告警。这样可以在问题恶化到影响用户之前就介入处理。定期进行性能测试与压测在新功能上线前通过压测提前发现潜在的性能瓶颈和内存泄漏点。使用jconsole或visualvm在压测期间实时监控观察内存曲线是否呈“锯齿状”正常GC还是“阶梯状”内存泄漏。5.3 编码最佳实践与代码审查很多问题可以在代码层面避免。避免创建不必要的对象在循环内拼接字符串使用StringBuilder谨慎使用自动装箱Integervsint对于可复用的对象考虑使用对象池但需权衡GC与池化开销。及时释放资源使用try-with-resources语句确保Closeable资源被关闭。小心使用全局缓存为缓存设置合理的过期时间、大小限制LRU和内存淘汰策略。考虑使用弱引用WeakReference或软引用SoftReference的缓存框架如Guava Cache、Caffeine。审慎使用线程池和ThreadLocal确保线程池大小配置合理使用ThreadLocal后务必在finally块中调用remove()。在代码审查中关注性能将大对象创建、循环内的复杂计算、潜在的资源未关闭等问题作为代码审查的重点项。处理Java应用的CPU和内存问题是一个从宏观监控到微观代码的完整链条。掌握这套从“症状”到“病因”的诊断方法配合合适的工具链和预防措施你就能在面对线上服务的“高烧”时做到心中有数手中有术快速而优雅地解决问题。记住每一次线上问题的解决都是对你技术深度和排查能力的一次绝佳锤炼。