如何排查服务器 CPU 飙高
服务器 CPU 飙高（CPU 使用率持续超过 80% 甚至接近 100%）是典型的性能瓶颈问题，可能由应用逻辑缺陷、资源竞争、外部压力或硬件/系统异常引起。以下是系统化的排查步骤，覆盖从现象确认到根因定位的全流程。
一、确认 CPU 飙高的现象与范围
首先需明确 CPU 高负载的具体表现和影响范围，避免误判：
1. 区分用户态（User）与内核态（System）CPU
通过 top 或 htop 查看 CPU 使用率细分：
- 用户态（User）：应用程序代码执行占用的 CPU（如业务逻辑、计算）。
- 内核态（System）：操作系统内核执行占用的 CPU（如 I/O 调度、网络协议栈、进程调度）。
关键结论：
- 若用户态 CPU 高：问题通常在应用程序（如死循环、频繁计算）。
- 若内核态 CPU 高：问题可能在 I/O 阻塞、网络流量过大或系统调用频繁。
2. 确认是持续高负载还是间歇性高负载
- 持续高负载：可能是应用逻辑缺陷（如死循环）、内存泄漏导致频繁 GC，或外部持续压力（如 DDoS 攻击）。
- 间歇性高负载：可能是批量任务（如定时任务）、突发流量（如秒杀活动）或资源竞争（如锁争用）。
3. 定位高负载的进程/线程
使用工具锁定具体是哪个进程或线程占用了大量 CPU：
(1) 系统级工具：top/htop
top命令：按P键按 CPU 使用率排序，找到占用最高的进程（PID）。top -c # 显示完整命令行htop（更友好的交互式工具）：支持树形查看进程关系，按F6选择排序方式（如 CPU 占用）。
(2) 进程级工具：pidstat
通过 pidstat 查看进程的 CPU 使用细节（需安装 sysstat 包）：
pidstat -u 1 5 # 每 1 秒输出一次，共 5 次，显示进程的 CPU 使用率
(3) 线程级工具：top -H 或 jstack（Java 应用）
- 非 Java 应用：通过
top -H -p查看进程内的线程 CPU 占用（-H显示线程）。 - Java 应用：使用
jstack生成线程转储，结合grep过滤阻塞或运行中的线程：jstack| grep -A 20 "java.lang.Thread.State: RUNNABLE" # 查看运行中的线程
二、分析高 CPU 进程的具体原因
锁定高 CPU 进程后，需深入分析其内部逻辑或外部交互，常见原因及排查方法如下：
1. 应用程序逻辑缺陷（用户态 CPU 高）
典型场景：死循环、递归未终止、频繁计算（如加密/压缩）、错误的分页查询（全表扫描）。
(1) Java 应用：检查线程状态与调用栈
-
死循环/无限递归：线程转储中若大量线程处于
RUNNABLE状态，且调用栈显示重复方法（如while(true)循环），可能是死循环。
示例（死循环）："http-nio-8080-exec-1" #12 prio=5 os_prio=0 tid=0x00007f8e3c0b8000 nid=0x4567 runnable [0x00007f8e2c1fe000] java.lang.Thread.State: RUNNABLE at com.example.DeadlockDemo.infiniteLoop(DeadlockDemo.java:20) # 重复调用自身 ... -
频繁 GC：通过
jstat -gcutil查看 GC 频率（FGC频繁且GCT占比高），可能是内存泄漏或大对象分配导致。
(2) 非 Java 应用：检查进程调用栈
使用 strace（Linux）跟踪进程的系统调用，定位耗时操作：
strace -p -c # 统计系统调用耗时（-c 显示统计）
若发现大量 read()、write() 或 poll() 调用，可能是 I/O 阻塞或网络流量过大。
2. I/O 阻塞导致内核态 CPU 高
典型场景：磁盘 I/O 慢（如机械盘 vs SSD）、网络 I/O 阻塞（如大量未完成的 Socket 连接）、文件描述符耗尽。
(1) 磁盘 I/O 问题
- 使用
iostat查看磁盘 I/O 利用率（%util接近 100% 表示磁盘满负荷）：iostat -d 1 5 # 每 1 秒输出一次磁盘 I/O 统计 - 若
%util高且await（平均 I/O 等待时间）大，可能是磁盘性能不足或存在大量随机读写（如数据库日志写入）。
(2) 网络 I/O 问题
- 使用
netstat或ss查看网络连接状态（如大量TIME_WAIT或ESTABLISHED连接）：ss -ant | grep ESTAB # 查看已建立的 TCP 连接数 - 若连接数过多（如超过
ulimit -n限制），可能导致进程阻塞在accept()或connect()，间接推高内核态 CPU。
3. 锁竞争与线程争用
典型场景：多个线程竞争同一把锁（如 synchronized、ReentrantLock），导致线程频繁阻塞/唤醒。
(1) Java 应用：检查锁竞争
- 使用
jstack查看线程的锁持有与等待关系（locked和waiting to lock字段）：
此片段表明线程"Thread-1": waiting to lock <0x000000076b45a2c0> (a java.lang.Object) which is held by "Thread-0" "Thread-0": locked <0x000000076b45a2c0> (a java.lang.Object) waiting to lock <0x000000076b45a290> (a java.lang.Object)Thread-0和Thread-1互相等待对方持有的锁，形成锁竞争。
(2) 非 Java 应用：使用 perf 分析
Linux 下使用 perf 工具分析锁竞争（需 root 权限）：
perf top -p # 实时查看进程的热点函数（如锁获取/释放）
4. 外部压力：突发流量或恶意请求
典型场景：DDoS 攻击、批量任务（如定时任务并发执行）、爬虫高频访问。
(1) 检查网络流量
- 使用
iftop或nload查看网络带宽占用（如某个 IP 发送大量请求）：iftop -i eth0 # 实时显示网络接口流量
(2) 检查应用日志
- 查看 Web 服务器（如 Nginx、Tomcat）的访问日志，统计高频请求的 URL 或 IP：
grep "GET /api" access.log | awk '{print $1}' | sort | uniq -c | sort -nr # 统计 IP 访问次数
5. 硬件或系统异常
典型场景：CPU 本身故障（如过热降频）、BIOS 配置错误、内核模块冲突。
(1) 检查 CPU 温度与风扇
- 使用
sensors工具（需安装lm-sensors包）查看 CPU 温度：
若温度过高（超过 90°C），可能是散热不良导致 CPU 降频（性能下降但功耗高）。sensors # 显示 CPU 核心温度（如 Core 0: +85°C）
(2) 检查内核日志
查看 /var/log/syslog 或 /var/log/kern.log，寻找硬件错误或异常：
dmesg | grep -i "error|warning" # 显示内核错误/警告信息
三、总结：排查流程与工具链
| 步骤 | 目标 | 关键工具/命令 |
|---|---|---|
| 确认 CPU 飙高现象 | 区分用户态/内核态，定位进程/线程 | top、htop、pidstat |
| 分析高负载进程 | 锁定具体应用或服务 | jstack（Java）、strace（非 Java） |
| 排查应用逻辑缺陷 | 死循环、频繁计算、GC 问题 | 线程转储、jstat -gcutil、代码审查 |
| 排查 I/O 阻塞 | 磁盘/网络 I/O 慢、连接数过多 | iostat、ss、netstat |
| 排查锁竞争与线程争用 | 线程互相等待锁 | jstack（锁持有/等待关系）、perf（非 Java） |
| 排查外部压力 | 突发流量、恶意请求 | iftop、nload、访问日志分析 |
| 检查硬件/系统异常 | CPU 故障、散热问题、内核错误 | sensors、dmesg、BIOS 配置检查 |
四、注意事项
- 生产环境谨慎操作：避免在业务高峰期重启进程或修改配置，优先通过监控工具（如 Prometheus+Grafana）实时观察。
- 日志与监控结合：通过日志（如应用日志、系统日志）和监控（CPU、内存、磁盘 I/O）交叉验证，避免误判。
- 逐步缩小范围：从系统→进程→线程→代码/配置，逐层定位根因，避免盲目修改。
通过以上步骤，可高效排查服务器 CPU 飙高的问题，最终定位到具体的应用逻辑缺陷、资源竞争或外部压力，并针对性优化。
