摘要：凌晨三点，手机突然震动，监控平台弹出一条刺眼的报警信息：“服务器CPU使用率超过90%”。作为开发者，这种场景或许并不陌生。线上CPU飙高是Java项目中最常见的性能问题之一，它可能导致服务响应变慢、接口超时甚至系统崩溃。但如何快速定位问题根源并高效解决？本文
凌晨三点，手机突然震动，监控平台弹出一条刺眼的报警信息：“服务器CPU使用率超过90%”。作为开发者，这种场景或许并不陌生。线上CPU飙高是Java项目中最常见的性能问题之一，它可能导致服务响应变慢、接口超时甚至系统崩溃。但如何快速定位问题根源并高效解决？本文将结合实战经验，用最接地气的方式，手把手带你走完CPU飙高排查的全流程。
在深入排查前，先明确问题可能的方向。根据实际案例统计，CPU飙高的原因主要分为以下几类：
代码逻辑问题：死循环：例如未正确退出的循环、递归调用失控。高并发下的锁竞争：如不合理的synchronized或ReentrantLock使用导致线程阻塞。算法复杂度高：如大数据量的嵌套循环（O(n²)时间复杂度）。资源争用问题：频繁GC：内存泄漏导致Full GC频繁触发，CPU资源被大量消耗。线程池配置不合理：核心线程数过多或任务队列堆积。外部依赖问题：数据库慢查询：未优化的SQL导致大量CPU时间消耗在IO等待。网络请求阻塞：第三方接口响应慢，线程长时间挂起。工欲善其事，必先利其器。以下工具是排查CPU问题的“瑞士军刀”：
基础工具：top命令：快速定位CPU占用最高的进程。top -Hp [PID]：查看进程内各线程的CPU使用率。jstack：生成线程堆栈快照，分析线程状态。jstat：监控JVM内存和GC情况。高级工具：Arthas：动态诊断工具，支持实时查看线程堆栈和热点方法。VisualVM/MAT：分析内存快照，定位内存泄漏。通过top命令快速锁定目标：
Bashtop -c # 显示完整命令按P键按CPU使用率排序，找到占用最高的Java进程，记录其PID。
通过top -Hp [PID]查看线程级CPU占用：
Bashtop -Hp 8632 # 显示进程内线程按P排序后，记录高CPU线程的十进制ID。
使用printf命令转换：
Bashprintf "%x\n" 31876 # 输出7c94生成线程堆栈文件：
Bashjstack 8632 > 8632.tdump # 导出堆栈在堆栈文件中搜索十六进制线程ID（如nid=0x7c94），定位具体代码位置。
若线程堆栈显示频繁GC，需检查JVM内存使用情况：
Bashjstat -gcutil 8632 1000 # 每秒打印GC统计关注FGC（Full GC次数）和FGCT（Full GC耗时）。若FGC持续增长且耗时高，可能存在内存泄漏。
导出内存快照并分析：
Bashjmap -dump:live,format=b,file=heap.hprof 8632 # 生成堆快照使用MAT工具分析大对象，定位代码中的内存分配问题。
现象：某接口调用后CPU瞬间飙高。
通过jstack发现某线程持续处于RUNNABLE状态，堆栈显示循环调用某方法。现象：CPU周期性飙高，伴随服务卡顿。
jstat显示FGC每分钟触发数十次，堆快照发现大量未释放的缓存对象。现象：高并发下CPU持续高位，接口响应慢。
排查：
jstack显示大量线程处于WAITING状态，线程池任务队列堆积。解决：调整线程池参数（如corePoolSize和maxPoolSize），改用有界队列并设置拒绝策略。
避免锁粒度过大：缩小同步代码块范围。使用线程池替代裸线程：合理设置线程数（参考IO密集型与CPU密集型场景）。调整堆内存参数：如-Xms和-Xmx设置相同，避免动态扩容。选择合适GC算法：高吞吐场景用Parallel GC，低延迟场景用G1或ZGC。接入APM工具：如Prometheus+Grafana监控CPU、内存、线程池状态。设置阈值告警：如CPU持续>80%时触发通知。CPU飙高排查是一场“逻辑推理+工具运用”的双重挑战。从紧急报警到问题修复，每一步都需要冷静分析和精准操作。希望本文的实战指南能成为你应对线上危机的“武功秘籍”。预防胜于治疗——通过代码审查、压测和持续监控，让系统在风平浪静中稳健运行。
来源：电脑技术汇