在生产环境运维中，CPU飙高、负载异常、线程阻塞是Java后端服务（SpringBoot、微服务、分布式项目）最常见的故障之一：接口响应超时、服务假死、FullGC频繁、线程死循环，归根结底大多是CPU资源瓶颈导致的。
核心适用场景：Java应用CPU 100%、系统负载过高、线程上下文切换频繁、CPU软中断/硬中断异常
======= 🌟 青柠来相伴，代码更简单。🌟 =======
📚 本文所有内容，我都整理在了博客合集里。👇
🎯 搜索关注【青柠代码录】，即可查看所有博客文章 ~
======= 🌟 ================ 🌟 =======
一、CPU性能核心指标
排查CPU问题前，必须明确核心指标阈值，避免误判。
贴合服务器（多核CPU）标准，关键指标如下：
- 系统平均负载（load average）：1/5/15分钟等待CPU的进程数总和，理想值≤CPU核心数，超过2倍核心数判定为高负载，需紧急排查
- 用户态CPU占比（us）：用户进程（Java应用）占用CPU，正常≤80%，过高说明业务代码存在性能瓶颈
- 内核态CPU占比（sy）：系统内核进程占用CPU，正常≤10%，过高说明系统调用频繁、线程切换过度
- I/O等待占比（wa）：CPU等待磁盘I/O的时间占比，正常≤5%，超过20%说明磁盘I/O拖慢CPU
- 空闲CPU占比（id）：剩余可用CPU资源，越低说明资源越紧张，低于20%需预警
- 上下文切换（cs）：CPU切换执行线程的次数，过高说明线程竞争激烈，资源损耗严重
- 运行队列（r）：等待CPU调度的进程数，超过CPU核心数说明CPU阻塞
二、CPU性能监控命令
1. top：实时全局CPU监控（排查入口命令）
命令定位：最基础、最常用的CPU监控命令，实时展示系统全局负载、CPU总使用率、进程级CPU占用，是排查CPU问题的第一步。
核心参数详解
| 参数 | 参数含义 | 生产使用建议 |
|---|---|---|
| -d N | 设置刷新间隔为N秒，默认3秒 | 推荐-d 2，2秒刷新一次，兼顾实时性与资源占用 |
| -c | 显示进程完整命令路径，便于定位Java服务 | 必加参数，快速区分多个Java进程 |
| -p PID | 仅监控指定PID的进程，精准定位目标服务 | 定位到Java进程PID后使用 |
| -1 | 显示所有CPU核心的使用率，而非总使用率 | 多核服务器必用，判断单核心满载还是全局满载 |
实战执行示例
# 基础监控（默认刷新，仅显示总CPU使用率）
top# 生产常用：2秒刷新+显示完整命令+多核展示（推荐）
top -d 2 -c -1# 精准监控指定Java进程（PID=1856）
top -p 1856 -d 2
关键输出解读（CPU专项）
# 头部核心行
top - 15:30:45 up 45 days, 2 users, load average: 3.86, 2.12, 1.68
# CPU总使用率行
%Cpu(s): 85.2 us, 8.1 sy, 0.0 ni, 4.5 id, 2.0 wa, 0.0 hi, 0.2 si, 0.0 st
- load average：3.86（1分钟）、2.12（5分钟）、1.68（15分钟），4核服务器下1分钟负载超8核，判定高负载
- us=85.2%：用户态CPU占比超标，确定是Java应用代码问题
- wa=2.0%：I/O等待正常，排除磁盘瓶颈
交互快捷键
- P：按CPU使用率降序排序，快速定位高CPU进程
- M：按内存使用率排序
- 1：切换多核/总CPU展示
- k：输入PID，直接杀死异常进程
2. mpstat：CPU核心级精细化监控
命令定位：查看每个CPU核心的使用率详情，区分单核心满载（线程绑定）和全局CPU过载，解决top无法查看单核性能的痛点。
依赖安装：CentOS/RHEL系统需安装sysstat工具包
yum install -y sysstat
核心参数详解
| 参数 | 参数含义 |
|---|---|
| -P ALL | 展示所有CPU核心数据，-P N展示指定核心（N为核心编号） |
| N | 刷新间隔秒数 |
| M | 刷新次数，不写则无限刷新 |
实战执行示例
# 每2秒刷新一次，展示所有CPU核心，无限监控
mpstat -P ALL 2# 每2秒刷新一次，共展示5次，便于截取数据
mpstat -P ALL 2 5
关键输出解读
Linux 3.10.0-1160.el7.x86_64 (localhost) 20/26 x86_64_ 4 CPU)15:35:20 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
15:35:22 all 82.37 0.00 7.52 1.25 0.00 0.12 0.00 0.00 0.00 8.74
15:35:22 0 98.50 0.00 1.50 0.00 0.00 0.00 0.00 0.00 0.00 0.00
15:35:22 1 75.25 0.00 8.00 2.00 0.00 0.25 0.00 0.00 0.00 14.50
15:35:22 2 76.00 0.00 9.25 1.75 0.00 0.10 0.00 0.00 0.00 12.90
15:35:22 3 79.75 0.00 6.30 1.25 0.00 0.15 0.00 0.00 0.00 12.55 ( _ 03/
- CPU 0核心%idle=0%，满载运行，说明存在线程绑定单核的问题
- 整体%usr占比过高，确认是用户态进程（Java）导致
3. pidstat：进程/线程级CPU定位（Java排查神器）
命令定位：精准定位进程级、线程级CPU占用，是排查Java死循环、线程泄露的核心命令，解决top只能看进程、无法看线程的短板。
核心参数详解
| 参数 | 参数含义 | Java排查用途 |
|---|---|---|
| -u | 监控CPU使用率（默认项） | 查看进程CPU占比 |
| -t | 展示进程下的所有线程详情 | 定位高CPU占用的Java线程 |
| -p PID | 指定目标进程PID | 锁定Java服务进程 |
| N | 刷新间隔秒数 | 持续监控线程变化 |
实战执行示例
# 1. 查看所有进程CPU占用，2秒刷新一次
pidstat -u 2# 2. 定位Java进程（PID=1856）的线程级CPU占用（核心排查命令）
pidstat -p 1856 -t 2# 3. 仅展示高CPU线程，过滤输出
pidstat -p 1856 -t 2 | grep -v '0.00%CPU'
关键输出解读
Linux 3.10.0-1160.el7.x86_64 (localhost) 03/20/26 _x86_64_ (4 CPU)15:40:10 UID PID TGID %usr %system %guest %CPU CPU Command
15:40:12 0 1856 - 84.50 7.20 0.00 91.70 0 java
15:40:12 0 - 1857 82.30 5.10 0.00 87.40 0 |__java
15:40:12 0 - 1858 0.20 0.10 0.00 0.30 1 |__java
- PID=1856为Java主进程，%CPU=91.70%，确认是该进程导致CPU飙高
- TGID=1857为Java子线程，%CPU=87.40%，定位到具体异常线程
4. vmstat：CPU上下文切换+运行队列监控
命令定位：综合监控CPU运行队列、上下文切换次数，判断是否存在线程竞争、调度异常问题，适用于CPU使用率不高但负载高的场景。
核心参数详解
| 参数 | 参数含义 |
|---|---|
| N | 刷新间隔秒数 |
| M | 刷新次数 |
实战执行示例
# 每2秒刷新一次，无限监控
vmstat 2# 每2秒刷新一次，共监控10次
vmstat 2 10
关键输出解读（CPU专项字段）
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st6 0 0 156320 53210 856230 0 0 0 0 102 3568 85 8 5 2 0
- r=6：运行队列进程数，4核服务器下远超核心数，CPU调度阻塞
- cs=3568：上下文切换次数过高，线程频繁切换，资源损耗大
- us+sy=93%：CPU总占用率极高，空闲资源不足
5. sar：历史CPU数据回溯（故障复盘神器）
命令定位：查看历史CPU使用率数据，适用于故障复盘、定位过去时间段的CPU异常，弥补实时命令无法回溯的缺陷。
核心参数详解
| 参数 | 参数含义 |
|---|---|
| -u | 监控CPU使用率 |
| -f /var/log/sa/saDD | 读取历史日志文件，DD为日期（如sa20代表20号） |
| -s HH:MM:SS -e HH:MM:SS | 指定查询时间段 |
实战执行示例
# 实时查看CPU使用率，2秒刷新一次
sar -u 2# 复盘今日14:00-15:00的CPU历史数据
sar -u -f /var/log/sa/sa20 -s 14:00:00 -e 15:00:00
三、实战：Java服务 CPU 100% 排查全流程
结合上述命令，落地Java后端服务CPU飙高标准化排查流程，每一步可直接执行：
Step1：全局定位，确认CPU瓶颈
# 执行top命令，查看负载、CPU占比
top -d 2 -c -1
判断：load average超标、us占比过高，确定是Java进程导致CPU飙高，记录Java进程PID（如1856）。
Step2：线程级定位，找到异常线程
# 监控Java进程线程CPU占用
pidstat -p 1856 -t 2
记录高CPU线程ID（如1857），将线程ID转为16进制（1857→0x749），用于jstack分析。
Step3：Java线程堆栈分析，定位代码行
# 导出Java进程堆栈日志
jstack 1856 > cpu_stack.log# 过滤16进制线程ID，定位异常代码
grep -A 20 0x749 cpu_stack.log
Step4：根因修复与验证
常见根因：死循环、递归溢出、线程池泄露、FullGC频繁、大量正则耗时操作。修复代码后，重新执行top/mpstat验证CPU使用率恢复正常。
本文由mdnice多平台发布