1. 问题引入当你的Java服务突然“高烧不退”做后端开发的朋友尤其是负责线上服务稳定性的同学肯定对下面这个场景不陌生监控大盘突然告警某个核心服务的CPU使用率飙到了90%以上或者内存占用像坐了火箭一样直线上升眼看就要触发OOMOutOfMemoryError。这时候整个团队的气氛都会瞬间紧张起来业务方在催老板在问而你盯着满屏的日志和曲线图感觉无从下手。这种“高烧”状态我们称之为性能瓶颈或资源泄漏。它不像代码报错那样有明确的异常栈更像是一个隐形的杀手悄无声息地拖慢整个系统最终导致服务不可用。定位这类问题考验的不仅仅是编码能力更是一套系统的“诊疗”思路和工具使用技巧。很多人一上来就胡乱重启或者盲目加机器这只能暂时掩盖症状病根没找到迟早还会复发。今天我就结合自己多年在电商、金融等高压场景下处理这类问题的经验整理出一套从现象到根因的完整定位流程。这套方法不是死记硬背的命令集合而是一个有逻辑、分层次的“破案”指南。无论你是刚接触线上问题的初级工程师还是想梳理自己排查思路的资深开发者相信都能从中获得直接的帮助。我们会从最外部的监控指标入手像剥洋葱一样层层深入到JVM内部、线程堆栈乃至具体的代码行最终找到那个“罪魁祸首”。2. 整体排查思路建立系统化的诊断路径面对CPU或内存过高的问题最忌讳的就是毫无章法地东一榔头西一棒子。一个高效的排查过程应该像医生问诊一样有望、闻、问、切的步骤。我总结了一个四层递进的排查模型可以帮助你快速建立诊断路径。2.1 第一层现象确认与初步归因告警响了第一步不是马上登录服务器而是先花几分钟看清“战场”全貌。你需要确认几个关键问题是全局性问题还是局部问题查看监控是所有实例的CPU/内存都高了还是仅仅其中某一台或某几台如果是局部的很可能与那台机器上的特定请求或数据有关如果是全局的则要考虑最近是否有统一的变更比如发布新代码、更新配置、或流量突增。是瞬时尖峰还是持续高位观察监控曲线。如果是瞬间飙升然后回落可能是正常的流量脉冲或某个耗时任务如果是持续缓慢上升直到打满那极有可能是内存泄漏如果是持续高位震荡则可能是代码中存在低效循环或资源竞争。关联指标有何异常CPU高时观察接口的QPS每秒查询率和RT响应时间。如果QPS没变而RT增加可能是单个请求处理变慢如果QPS和CPU同步飙升可能是流量过大。内存高时观察GC垃圾回收频率和耗时。如果Full GC频繁但回收效果甚微基本可以断定是内存泄漏。这个阶段利用好公司的监控系统如Prometheus Grafana, Zabbix等是关键。初步判断能帮你决定排查的紧急程度和大致方向。2.2 第二层定位问题进程与线程确认了现象下一步就是登录到目标服务器找到具体的“病灶”。这里我们主要依赖操作系统层面的工具。对于CPU过高首先用top命令查看整体资源情况。按1可以显示每个CPU核心的利用率看是否是某个核心被打满。记住异常Java进程的PID进程ID。 然后使用top -Hp [PID]命令查看该Java进程内所有线程的CPU占用情况。你会看到一串线程IDTID和对应的CPU百分比。那个占用最高的线程就是我们要重点关注的“热点线程”。记下它的TID十进制数字。对于内存过高同样先用top命令但关注RES常驻内存集和%MEM内存使用百分比列。找到内存消耗最大的Java进程PID。 注意Linux的top看到的内存是进程占用的物理内存而JVM的内存管理更为复杂我们还需要结合JVM工具看内部各区域的使用情况这会在下一层进行。注意top中的内存信息有时会因共享内存等原因导致统计偏差。对于Java进程更准确的做法是使用jstat或jcmd来观察JVM堆内存。2.3 第三层深入JVM内部洞察这是定位Java应用问题的核心层。我们需要使用JDK自带的神兵利器。工具一jstack - 抓取线程快照jstack [PID] thread_dump.log这个命令可以将指定时刻Java进程内所有线程的运行状态、调用栈信息输出到文件。拿到第二层找到的高CPU线程的TID比如12345我们需要将其转换为十六进制0x3039然后在thread_dump.log文件中搜索这个十六进制值就能定位到该线程正在执行什么代码。如果它长时间停留在某个方法比如一个死循环或者一个锁等待调用栈会清晰地告诉你。工具二jmap jstat - 洞察内存奥秘jmap -heap [PID]查看堆内存的总体配置和使用情况包括各代Eden, Survivor, Old的容量、使用量、GC算法等。快速判断是否是堆空间设置不合理。jmap -histo:live [PID] | head -20查看堆内存中存活对象的数量和大小统计按总大小排序。排在前列的类很可能就是内存消耗的“大户”或泄漏的嫌疑犯。注意-histo:live会触发一次Full GC线上慎用非紧急情况可以用-histo不触发GC先看个大概。jstat -gcutil [PID] 1000 10每1秒1000毫秒输出一次GC统计信息共10次。动态观察各内存区域的使用率E, S0, S1, O, M分别代表Eden, Survivor0, Survivor1, Old, Metaspace、GC次数YGC, FGC和耗时YGCT, FGCT。如果看到Old区O使用率不断上升而FGCFull GC频繁但每次回收后O区使用率下降很少这就是典型的内存泄漏迹象。工具三jcmd - 多功能瑞士军刀jcmd是JDK 7之后推荐的综合工具功能强大且对进程影响相对较小。jcmd [PID] Thread.print等同于jstack获取线程转储。jcmd [PID] GC.heap_info查看堆信息。jcmd [PID] VM.native_memory查看JVM申请的本地内存堆外内存详情对于排查堆外内存泄漏如Netty的Direct Buffer至关重要。2.4 第四层代码级根因分析与验证通过前三层我们通常能锁定到可疑的线程栈和对象类。最后一层就是结合代码和业务逻辑进行验证。分析线程栈查看jstack输出的热点线程栈。如果栈顶是java.lang.Thread.run可能是个死循环的线程如果栈顶是sun.misc.Unsafe.park或java.util.concurrent.locks.LockSupport.park说明线程在等待锁可能是锁竞争激烈导致CPU空转虽然等待不消耗CPU但争抢锁的过程会如果栈顶是应用代码比如com.xxx.service.Impl.process()并且这个方法在栈里反复出现那很可能就是这个方法逻辑有性能问题。分析内存直方图查看jmap -histo输出中排名靠前的类。如果是业务相关的类如OrderDTO,UserSession且数量多得离谱就要去代码里找这些对象是在哪里创建、为什么没有被回收。结合jstack看是否有线程持有这些对象的巨大集合如HashMap、ArrayList的引用导致GC无法回收。代码审查与验证根据线索去翻代码。常见的内存泄漏场景包括静态集合类持续添加元素、未关闭的资源如数据库连接、文件流、HTTP连接、监听器或回调注册后未取消、使用ThreadLocal未及时清理等。常见的CPU热点场景包括低效的算法如多层嵌套循环、正则表达式误用、频繁的日志输出尤其是DEBUG级别、锁粒度不合理等。复现与修复如果可能在预发或测试环境尝试复现问题。可以尝试使用Arthas、Async-Profiler等更强大的在线诊断工具进行动态跟踪和采样分析精准定位热点方法。修复后必须通过压测验证效果。这套四层排查路径从宏观到微观从系统到代码形成了一个闭环。在实际操作中你可能需要在不同层次间来回跳跃验证但有了这个框架你的排查就不会迷失方向。3. CPU使用率过高问题深度定位CPU使用率居高不下意味着处理器一直在忙碌。对于Java应用这通常不是“计算过于复杂”而是“在不该忙碌的地方瞎忙”。下面我们拆解几种典型场景和对应的排查手术刀。3.1 场景一无限循环或低效算法这是最直接的原因。某个线程陷入了一个无法退出的循环或者一个算法的时间复杂度太高。排查手法使用top -Hp找到耗CPU的线程TID。jstack获取线程转储并转换TID为十六进制进行搜索。分析线程栈。如果你在栈顶看到类似下面的调用并且栈深度很浅反复循环那很可能就是问题所在Thread-0 #1 prio5 os_prio0 tid0x00007f4874000 nid0x3039 runnable [0x00007f48fe000] java.lang.Thread.State: RUNNABLE at com.example.BadService.infiniteLoop(BadService.java:20) // 卡在某个方法 at com.example.BadService.lambda$start$0(BadService.java:15) at com.example.BadService$$Lambda$1/0x0000000840060840.run(Unknown Source) at java.lang.Thread.run(Thread.java:748)使用Profiler工具进行热点方法采样。jstack是瞬态图如果问题不是持续占满CPU可能抓不到。这时可以用Arthas的profiler命令或者Async-Profiler对CPU进行一段时间比如30秒的采样它会生成一个火焰图。火焰图横向显示调用栈纵向显示深度最宽的那个“火苗”就是最耗CPU的方法。一眼就能看出系统的“热力”分布。实操心得不要忽视“日志轰炸”。在循环里打log.debug(...)如果日志框架配置不当例如异步队列满或者日志级别实际是INFO/ERROR但日志内容字符串拼接耗时也可能导致CPU升高。检查日志配置和日志语句。正则表达式尤其是复杂的、在循环中编译的Pattern.compile()是CPU杀手。确保Pattern对象被缓存复用。3.2 场景二激烈的锁竞争这是高并发场景下的典型问题。线程没有在执行业务计算而是在为了获取锁而“自旋”空转或者大量线程处于BLOCKED状态。排查手法分析jstack文件中的锁信息。搜索BLOCKED状态的线程。查看它们等待的锁是什么waiting to lock 0x000000076bf62200以及是哪个线程持有了这个锁locked 0x000000076bf62200。Thread-2 #3 prio5 os_prio0 tid0x00007f4874000 nid0x303b waiting for monitor entry [0x00007f48fd000] java.lang.Thread.State: BLOCKED (on object monitor) at com.example.ResourceService.consume(ResourceService.java:50) - waiting to lock 0x000000076bf62200 (a java.lang.Object) // 等待这个锁 at com.example.Worker.run(Worker.java:25) Thread-1 #2 prio5 os_prio0 tid0x00007f4874000 nid0x303a runnable [0x00007f48fe1000] java.lang.Thread.State: RUNNABLE at com.example.ResourceService.consume(ResourceService.java:55) - locked 0x000000076bf62200 (a java.lang.Object) // 正持有这个锁 at com.example.Worker.run(Worker.java:25)统计锁竞争热度。如果大量线程在等待同一个锁说明这个锁的粒度太粗成了性能瓶颈。可以使用Arthas的monitor命令监控某个方法的调用耗时和成功率或者使用thread -b命令直接找出当前阻塞其他线程最多的那个“罪魁祸首”线程。解决方案缩小锁粒度将一个大锁拆分成多个小锁例如不用synchronized锁整个方法而是锁一个更小的对象。使用并发容器用ConcurrentHashMap代替Collections.synchronizedMap(new HashMap())。使用读写锁对于读多写少的场景使用ReentrantReadWriteLock。尝试无锁编程考虑使用Atomic变量或LongAdder。检查死锁jstack输出最后一部分通常会做死锁检测如果发现会明确提示Found one Java-level deadlock:。3.3 场景三频繁的GC活动这是一个容易被忽略的间接原因。当应用程序产生大量短命对象或者存在内存压力时垃圾回收器尤其是Young GC会频繁启动。虽然单次GC停顿时间不长但极高的频率会累积消耗大量CPU时间。排查手法使用jstat -gcutil [PID] 1000动态观察。重点看YGCYoung GC次数和YGCTYoung GC总时间这两列。如果YGC在短时间内比如1分钟疯狂上涨几十、上百次并且YGCT累积时间很长说明GC是CPU消耗大户。结合top观察。此时top看到的CPU高可能不是业务线程而是JVM的GC线程如G1 Main Marker,GC Thread等。解决方案优化对象创建减少不必要的对象创建特别是在循环和高频调用路径上。重用对象使用对象池需谨慎避免引入复杂性。调整堆和代大小如果Survivor区太小会导致对象过早进入老年代可能引发更耗时的Mixed GC或Full GC。适当调大年轻代-Xmn可能有助于减少晋升。选择合适的GC器对于高吞吐量应用Parallel GC可能更合适对于低延迟要求G1或ZGC是更好的选择。但这需要根据应用特性和性能测试来决定。4. 内存使用率过高问题深度定位内存问题比CPU问题更具潜伏性往往在积累到一定程度后才突然爆发。其核心矛盾是创建的对象速度 垃圾回收的速度。4.1 场景一堆内内存泄漏这是最常见的Java内存问题。对象因为被错误的引用持有而无法被GC回收随着时间推移这些“垃圾”对象占满整个堆最终触发OOM。排查手法标准流程监控观察通过jstat -gcutil观察老年代O使用率是否随时间持续上升且Full GCFGC后回收效果很差使用率下降不明显。生成堆转储文件这是内存分析最关键的证据。在内存占用较高时使用命令生成堆转储Heap Dump文件。jmap -dump:live,formatb,fileheap.hprof [PID]触发一次Full GC后转储存活对象文件较小但会干扰线上服务。推荐JDK自带jcmd [PID] GC.heap_dump /path/to/heap.hprof影响相对较小。推荐安全在JVM启动参数中添加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path/to/dump让JVM在发生OOM时自动生成转储最安全且能捕获到“案发现场”。使用MAT或JVisualVM分析堆转储MAT (Eclipse Memory Analyzer)功能极其强大。打开heap.hprof文件后首先看Leak Suspects Report泄漏嫌疑报告它会自动分析可能的内存泄漏点。使用Histogram直方图视图按类或类加载器统计对象数量和占用内存。与jmap -histo类似但更直观。最关键的一步找到疑似泄漏的大对象比如一个巨大的HashMap右键选择Path To GC Roots - exclude weak/soft references。这个功能会显示从GC根节点如静态变量、活动线程栈到这个对象的完整引用链。这条链就是阻止该对象被回收的“罪证”通常你会发现某个静态的Map或List在持续添加业务对象却从未清理。JVisualVMJDK自带比较轻量。加载堆转储后查看“类”视图同样可以按大小排序并查看实例的引用关系。常见泄漏点静态集合类如public static Map CACHE new HashMap();是最经典的泄漏源。连接池、线程池未正确配置连接或线程创建后不释放。监听器和回调注册后没有注销。ThreadLocal使用不当在线程池场景下线程复用导致前一个任务的ThreadLocal变量未被清除从而随着线程存活一直累积。内部类持有外部类引用非静态内部类会隐式持有外部类实例的引用如果这个内部类对象被长生命周期对象引用会导致外部类实例也无法释放。4.2 场景二堆外内存泄漏JVM的内存不止堆Heap还有堆外内存Native Memory也叫直接内存。像NIO的DirectByteBuffer、JNI调用、某些网络框架如Netty的池化内存管理都会使用堆外内存。这部分内存不受JVM垃圾回收管理需要手动释放或依赖框架的生命周期管理。排查手法现象识别top看到进程的RES内存持续增长但通过jstat或jmap看到的堆内存使用率却很正常甚至很低。这就是堆外内存泄漏的典型特征。使用jcmd查看详情jcmd [PID] VM.native_memory命令可以详细展示JVM内部各部分内存的使用情况包括Internal元数据、Arena分配器、Thread线程栈、CodeJIT代码缓存以及Direct直接缓冲区。关注Direct部分的committed内存是否异常高且持续增长。使用操作系统工具pmap -x [PID] | sort -k3 -n -r可以查看进程的内存映射找到那些巨大的匿名映射块anon它们可能对应着堆外内存区域。定位代码堆外内存泄漏定位更难。如果使用了Netty可以开启Netty的泄漏检测工具ResourceLeakDetector。对于DirectByteBuffer可以尝试在代码中跟踪其创建和释放或者使用Java Flight Recorder (JFR)来监控DirectByteBuffer的分配事件。解决方案确保DirectByteBuffer在使用后调用cleaner.clean()通常通过((DirectBuffer) buffer).cleaner().clean()或等待GC触发其Cleaner机制。但在高并发下最好池化复用。检查使用的第三方库尤其是网络库、序列化库是否有已知的堆外内存泄漏问题并升级到修复版本。4.3 场景三元空间Metaspace溢出Java 8之后永久代PermGen被元空间Metaspace取代。它主要存储类的元数据Klass结构、方法信息等。如果应用动态生成大量类例如大量使用CGLib、ASM进行字节码增强或者Groovy等脚本引擎频繁编译就可能导致元空间溢出错误为Metaspace。排查手法监控观察jstat -gcutil中的MMetaspace使用率是否接近100%。分析原因元空间溢出几乎总是和动态类加载有关。检查应用是否使用了大量的反射、动态代理、或者像Spring AOPCGLib代理在反复创建代理类。解决方案适当调大元空间大小-XX:MaxMetaspaceSize256m。更根本的是优化应用设计减少不必要的动态类生成。例如检查是否有循环里在反复创建代理对象。5. 高级工具与实战技巧除了JDK自带的基础工具掌握一些更强大的“武器”能让你在排查时事半功倍。5.1 Arthas阿里开源的在线诊断利器Arthas不需要修改代码、不需要重启服务就能动态跟踪问题是线上排查的“核武器”。常用命令场景dashboard实时仪表盘一眼看清线程、内存、GC、运行时信息。thread [PID]或thread -n 3查看所有线程状态或CPU占用率最高的前3个线程。比top -Hpjstack方便太多。thread -b一键找出当前阻塞其他线程最多的线程死锁或锁竞争瓶颈。jad com.example.BadService infiniteLoop反编译线上正在运行的类字节码直接看源码。当你怀疑代码版本不对时特别有用。watch com.example.Service methodName {params, returnObj, throwExp}动态观察方法调用的入参、返回值和异常。用于追踪数据流向。profiler start/profiler stop生成CPU或内存分配的火焰图图形化展示热点。heapdump在线生成堆转储文件功能同jmap -dump。实操心得Arthas的命令非常丰富刚开始不必全部掌握。记住dashboard、thread、jad、watch、profiler这几个最常用的就能解决80%的问题。使用前最好在测试环境熟悉一下避免对线上服务造成意外影响。5.2 性能剖析与火焰图火焰图是性能分析的“心电图”它能将复杂的调用栈和耗时情况可视化。CPU火焰图看最顶层的“平顶山”那里就是消耗CPU最多的调用链。内存分配火焰图看哪些方法在频繁地分配对象。生成方法使用Async-Profiler下载工具通过profiler.sh脚本附加到Java进程可以生成非常清晰的SVG格式火焰图。使用Arthas的profiler命令集成在Arthas中使用更方便profiler start开始采样profiler stop停止并生成火焰图文件。看图技巧X轴不代表时间而是采样数量宽度越宽表示被采样到的次数越多即越耗时。Y轴是调用栈深度从上到下是调用关系。鼠标悬浮可以看具体方法的采样百分比。寻找最宽且位于中下层的“火苗”那就是你要优化的热点方法。5.3 GC日志分析与优化建议GC日志是理解JVM内存行为的金钥匙。务必在启动参数中开启GC日志。推荐参数-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -Xloggc:/path/to/gc.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles5 -XX:GCLogFileSize10M对于JDK 9推荐使用更统一的日志框架-Xlog:gc*,gcagetrace,safepoint:file/path/to/gc.log:time,uptime,level,tags:filecount5,filesize10M分析要点Young GC频率和耗时如果频率过高如几秒一次考虑增大年轻代-Xmn。如果单次耗时过长检查是否有很多“大对象”直接进入了老年代参数-XX:PretenureSizeThreshold。Full GC频率和原因关注每次Full GC的触发原因如Allocation Failure,Metadata GC Threshold,System.gc()。如果是由Allocation Failure触发且频繁发生说明老年代空间不足可能需要增大堆-Xmx或优化程序减少内存占用。GC后内存回收效果看每次GC后各区域的使用量下降是否明显。如果老年代每次Full GC后使用率下降很少就是内存泄漏的铁证。优化思路首要目标避免或减少Full GC。核心策略让对象在年轻代就“死掉”。调整-Xmn年轻代大小、-XX:SurvivorRatioEden和Survivor比例让对象有足够的时间在Young GC中被回收。选择GC器吞吐量优先用Parallel GC低延迟优先用G1或ZGC。G1需要设置合理的-XX:MaxGCPauseMillis期望最大停顿时间如200msZGC则几乎全程并发停顿时间极短但吞吐量可能略有损耗。6. 常见问题排查清单与避坑指南这里将高频问题整理成表方便你快速对照排查。现象可能原因排查工具/命令关键证据/下一步动作CPU使用率持续100%1. 某个线程死循环2. 频繁的Young GC3. 锁竞争激烈自旋1.top -Hpjstack2.jstat -gcutil3.jstack看BLOCKED线程1. 找到热点线程栈定位代码。2. 观察YGC次数是否暴增。3. 找到被大量线程等待的锁。CPU使用率间歇性飙升1. 定时任务触发2. 外部调用超时/重试风暴3. 缓存失效导致的雪崩查询1. 关联监控时间点与任务日志。2. 检查依赖服务状态和超时配置。3. 分析调用链查看数据库/缓存慢查询。1. 检查调度中心日志。2. 使用Arthastrace命令追踪调用链耗时。3. 查看DB监控和慢SQL日志。堆内存缓慢增长直至OOM内存泄漏对象无法回收1.jstat -gcutil观察O区趋势。2.jmap -histo或jcmd GC.heap_info3. 生成堆转储用MAT分析。1. O区使用率只升不降FGC无效。2. 发现某个业务类实例数异常多。3. MAT中找到该对象的GC Roots引用链。物理内存高但堆内存使用正常堆外内存泄漏Direct Buffer等1.top看RESjstat看堆。2.jcmd VM.native_memory3.pmap -x查看进程内存映射。1. RES高堆内存使用率低。2. Native Memory的Committed持续增长。3. 存在巨大的匿名内存映射块。服务卡顿但CPU不高1. 外部依赖DB、Redis、RPC慢2. 锁竞争导致线程大量WAITING3. 频繁的Full GC导致“世界暂停”1. 链路追踪SkyWalking, Zipkin。2.jstack统计线程状态比例。3. 分析GC日志看Full GC频率和耗时。1. 发现某个下游调用耗时极长。2. 大量线程处于WAITING (parking)。3. GC日志中出现长停顿的Full GC记录。Metaspace溢出动态类加载过多CGLib代理等1.jstat -gcutil看M区。2. 检查是否大量使用反射、动态代理。1. M区使用率100%。2. 错误信息为Metaspace。增加-XX:MaxMetaspaceSize并优化代码。避坑指南与心得预防大于治疗在编码阶段就建立良好的习惯。避免在循环中创建大量临时对象、谨慎使用静态集合、及时关闭资源用try-with-resources、合理设计缓存失效策略。监控与告警先行务必搭建完善的应用性能监控APM体系。监控核心指标CPU使用率、堆内存使用率、GC频率与耗时、接口QPS/RT、错误率。设置合理的告警阈值能在问题萌芽阶段就发现。保留现场遇到线上问题条件允许的话先保留现场如线程Dump、堆Dump再重启。重启会丢失一切线索。可以设置JVM参数-XX:HeapDumpOnOutOfMemoryError自动留证。理解工具原理不要死记命令。理解jstack是看线程瞬间的快照jstat是看JVM内部的趋势jmap是看内存的静态分布。根据不同场景选择合适的工具。保持怀疑交叉验证工具给出的信息有时会有误导。比如top看到的CPU高不一定是Java业务代码可能是GC。需要用jstat和线程栈交叉验证。MAT分析出的“泄漏点”也要回到代码逻辑中确认是否合理。性能优化要有数据支撑不要凭感觉优化。优化前用工具Arthas profiler, JMH基准测试定位真正的瓶颈优化后用同样的工具和数据对比验证效果。
