<think>
我们正在处理关于
线上环境
CPU飙高
排查方法的问题。根据引用内容，已经有一些
排查方法的提示，如使用top、jstack、Arthas等工具。我们需要系统地总结这些方法，并补充其他可能的
排查步骤。
主要
排查步骤：
1. 定位高
CPU进程：使用top命令，按
CPU排序，找到占用
CPU最高的进程ID（PID）。
2. 定位高
CPU线程：在top中按`H`（或者使用`top -Hp <pid>`）查看该进程下的
线程，记录占用高的
线程ID（TID）。
3.
线程ID转换：将TID转换为16进制（因为jstack输出的
线程信息是16进制）。
4. 使用jstack获取
线程堆栈：`jstack -l <pid> > thread_dump.txt`，然后在堆栈文件中查找对应16进制TID的
线程，查看其堆栈信息。
5. 使用Arthas工具：如果环境允许，可以使用Arthas工具，其提供了更便捷的命令，如`dashboard`可以查看整体情况，`thread`命令可以查看
线程
CPU使用情况，`thread -n 3`展示最忙的3个
线程，`thread <tid>`查看指定
线程的堆栈。
另外，引用[3]提到了使用StopWatch来记录每一步的耗时，这可以在代码级别定位耗时操作，但通常是在开发阶段使用，
线上环境可能需要通过日志或者监控来定位。
我们还需要考虑其他可能导致
CPU飙高的原因以及
排查工具：
- 频繁Full GC：使用`jstat -gcutil <pid> <interval> <count>`来查看GC情况，如果发现Full GC次数多且频繁，可能是
内存问题导致GC
线程占用
CPU高。
- 死循环或无限递归：通过
线程堆栈查看是否在某个方法中循环。
- 锁竞争激烈：查看
线程堆栈中是否有大量
线程处于BLOCKED状态。
- 其他系统问题：如系统
负载高，使用`vmstat`、`sar`等命令查看系统整体情况。
因此，我们可以将步骤总结为：
一、系统层面定位
1. 使用`top`命令找到高
CPU进程。
2. 使用`top -Hp <pid>`或`ps -T -p <pid> -o tid,p
cpu,time`找到高
CPU线程。
3. 将
线程ID转为16进制（`printf "
%x" <tid>`）。
二、JVM层面
分析
4. 使用`jstack`获取
线程堆栈，并查找对应
线程的堆栈信息，
分析代码。
5. 或者使用Arthas工具（如果已安装）：
- 启动Arthas：`java -jar arthas-boot.jar`
- 使用`dashboard`查看整体情况
- 使用`thread`命令查看
线程
CPU使用情况
- 使用`thread <tid>`查看具体
线程堆栈
三、其他可能原因
排查
6. 检查GC活动：`jstat -gcutil <pid> 1000 5`（每1秒一次，共5次）
7. 检查
内存使用：`jmap -heap <pid>`或`jcmd <pid> GC.heap_info`
四、代码层面
分析
8. 结合堆栈信息
分析代码，看是否有死循环、频繁执行的方法等。
9. 如果有条件，可以查看应用日志中是否有相关错误或警告。
五、持续监控
10. 使用监控工具（如Prometheus+Grafana）设置
告警，提前发现问题。
注意：在生成
线程堆栈时，为了确保堆栈的准确性，建议多次dump堆栈，然后对比
分析。
下面我们按照要求生成回答，包括相关问题。
</think>
###
线上环境
CPU飙高
排查方法详解
#### 一、快速定位问题进程/
线程
```mermaid
graph TD
A[top命令] --> B[定位高
CPU进程]
B --> C[top -Hp <pid>]
C --> D[记录
线程ID]
D --> E[printf '
%x' <tid>]
E --> F[转换为16进制
线程ID]
```
1. **系统级定位**
- `top` 命令查看系统
负载：
```bash
top -c # 按P按
CPU排序，记录PID
```
- 定位问题
线程：
```bash
top -Hp <PID> # 查看指定进程的
线程
CPU占用
ps -T -p <PID> -o tid,p
cpu,time #
线程级
CPU监控
```
2. **
线程ID转换**
将十进制
线程ID转为16进制（jstack
分析必需）：
```bash
printf "
%x" <
线程ID> # 得到16进制tid
```
#### 二、JVM层
分析工具
1. **jstack
线程
分析**
```bash
jstack -l <PID> > thread_dump.txt # 获取
线程快照
```
在thread_dump.txt中搜索转换后的16进制tid，查看
线程堆栈
2. **Arthas 实时诊断**[^2]
```bash
# 启动Arthas
java -jar arthas-boot.jar
dashboard # 实时监控面板
thread -n 3 # 显示最忙的3个
线程
thread <16进制TID> # 查看指定
线程堆栈
profiler start # 启动
CPU性能
分析
```
3. **JProfiler/VisualVM**
远程连接生产环境（需开启JMX）：
```bash
-Dcom.sun.management.jmxremote.port=9010
-Dcom.sun.management.jmxremote.ssl=false
```
#### 三、代码层问题定位
1. **常见问题模式**
|
线程状态 | 可能原因 | 解决方案 |
|----------------|-------------------------|------------------------|
| `RUNNABLE` | 死循环/大计算量 | 算法优化 |
| `BLOCKED` | 锁竞争 | 减少同步范围 |
| `WAITING` | 资源等待 | 超时机制 |
2. **StopWatch 耗时
分析**[^3]
```java
StopWatch stopWatch = new StopWatch();
stopWatch.start("criticalSection");
// 关键业务代码
stopWatch.stop();
log.info("耗时
分析: {}", stopWatch.prettyPrint());
```
#### 四、典型场景解决方案
1. **死循环问题**
- 检查递归调用终止条件
- 避免在循环中执行重型操作（如JSON解析）
- 使用`Thread.sleep`释放
CPU
2. **锁竞争优化**
```java
// 优化前
synchronized(this) { /* 大段代码 */ }
// 优化后
private final Object lock = new Object();
synchronized(lock) { /* 最小同步范围 */ }
```
3. **GC导致
CPU飙高**
```bash
jstat -gcutil <PID> 1000 5 # 监控GC活动
```
- 特征：`gc`
线程
CPU占用高
- 解决：调整`-Xmx/-Xms`，优化GC策略
#### 五、预防与监控
1. **持续监控方案**
- Prometheus + Grafana：设置
CPU阈值
告警
- Spring Boot Actuator：`/actuator/metrics/system.
cpu.usage`
2. **压测验证**
```bash
# 模拟高并发
wrk -t12 -c400 -d30s http://localhost:8080/api
```
---
###
本文介绍了在Java应用中遇到CPU过高告警时的排查方法，包括检查耗时进程、使用jstack查看线程快照、分析GC情况、识别内存泄漏。通过实例和工具如top、jstat、jmap等进行详细步骤说明。
扫一扫
497
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
