一、问题定位：从全局视角锁定异常进程

当系统出现卡顿或响应延迟时，首先需通过系统级监控工具确认是否为CPU过载问题。推荐使用以下命令组合：

top -c                  # 实时查看进程级资源占用
vmstat 1 5             # 观察系统整体负载趋势
mpstat -P ALL 1 3      # 分析各CPU核心利用率

重点关注top输出中的%CPU列，当发现某个进程的CPU占用持续超过90%时，需立即记录其PID（进程ID）。此时应同步检查系统负载（load average）是否与CPU核心数匹配，若负载值远高于核心数，则说明存在严重的资源竞争。

二、线程级分析：定位具体消耗源

确定异常进程后，需进一步分析其内部线程的资源占用情况。使用以下命令获取线程级数据：

top -H -p <PID>        # 查看目标进程的所有线程
ps -eLf | grep <PID>   # 交叉验证线程信息

此时需重点关注TIME+列（线程累计CPU时间）和%CPU列。对于Java等JVM应用，还需特别注意GC线程（通常命名为”G1 Main Worker”等）的异常行为。记录下占用最高的3-5个线程的TID（线程ID）。

三、ID转换：十六进制转换技巧

由于Java堆栈分析工具需要十六进制的线程ID，需进行格式转换：

printf "%x\n" <TID>    # 十进制转十六进制
# 示例：printf "%x\n" 12345 → 输出 3039

建议将转换结果保存到临时文件，避免后续操作出错。对于批量处理场景，可编写简单脚本：

for tid in $(top -H -b -n1 -p <PID> | awk 'NR>7 {print $1}'); do
    printf "%x\n" $tid >> tids.txt
done

四、堆栈分析：获取代码级定位

4.1 Java应用分析

对于Java进程，使用jstack工具获取线程堆栈：

jstack <PID> > stack.log

结合之前转换的十六进制TID进行过滤：

grep -A 30 "nid=0x<HEX_TID>" stack.log

重点关注以下堆栈特征：

频繁出现的类/方法名（可能存在死循环）
锁等待（WAITING ON或BLOCKED状态）
频繁的GC操作（GC task thread相关）

4.2 Native进程分析

对于C/C++等原生程序，需使用perf或strace工具：

perf top -p <PID>      # 实时函数调用分析
strace -p <PID> -c     # 系统调用统计

特别关注__libc_开头的库函数调用，这些往往是性能问题的热点。

五、高级诊断技巧

5.1 火焰图生成

通过perf script和FlameGraph工具链可生成可视化火焰图：

perf record -F 99 -p <PID> -g -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

火焰图能直观展示函数调用关系和耗时占比，特别适合分析复杂调用链。

5.2 动态追踪技术

使用bpftrace或eBPF进行无侵入式监控：

bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }'

这种技术适合生产环境诊断，无需重启应用即可获取详细调用信息。

六、问题根因分类与解决方案

6.1 计算密集型问题

特征：特定线程持续高CPU占用，堆栈显示在固定方法循环
解决方案：

优化算法复杂度（如将O(n²)改为O(n log n)）
引入并发控制（如限流、批处理）
考虑使用硬件加速（如SIMD指令集）

6.2 I/O等待型问题

特征：CPU占用呈波浪形，伴随高磁盘/网络I/O
解决方案：

增加异步处理机制
优化缓冲区大小
使用更高效的数据序列化格式（如Protocol Buffers替代JSON）

6.3 锁竞争问题

特征：多个线程阻塞在同步块，堆栈显示BLOCKED状态
解决方案：

减少锁粒度（如分段锁）
使用无锁数据结构
考虑读写锁（ReadWriteLock）替代互斥锁

七、预防性措施

监控告警：设置CPU阈值告警（如持续5分钟>80%）
压力测试：在预发布环境进行全链路压测
代码审查：重点关注循环、递归、同步块等风险代码
资源隔离：使用容器或命名空间限制单个应用的资源使用

八、典型案例分析

某电商系统在促销期间出现CPU 100%问题，排查发现：

通过top定位到Java进程异常
jstack分析发现大量线程阻塞在Redis连接池获取连接
根本原因是连接池配置过小（maxTotal=10），而并发请求量达2000+
解决方案：将连接池大小调整为200，并引入Hystrix进行熔断

通过系统化的排查方法，该问题在30分钟内完成定位和修复，避免了数万元的潜在损失。这种诊断能力应成为每个开发团队的基础技能储备。

CPU 100%问题排查全攻略：从定位到根因分析