1. Linux系统CPU占用100%排查概述
遇到服务器CPU占用飙升至100%的情况，对任何运维工程师或开发者来说都是一场噩梦。这种紧急状况下，我们需要一套系统化的排查方法，快速定位问题根源。本文将分享我在生产环境中总结出的高效排查流程，从全局到局部层层深入，最终精确锁定问题代码。
CPU满载问题通常表现为系统响应缓慢、服务超时甚至完全无响应。根据多年经验，这类问题主要源于以下几种情况：
- 代码逻辑缺陷导致的死循环
- 不合理的线程同步引发的锁竞争
- 频繁的系统调用造成的内核态CPU消耗
- 内存管理不当引发的频繁GC或malloc/free
重要提示：排查过程中应尽量避免直接kill关键进程，特别是在生产环境。正确的做法是先降低进程优先级，获取足够诊断信息后再决定处理方案。
2. 全局定位高CPU进程
2.1 使用top命令进行初步诊断
top命令是Linux系统监控的瑞士军刀，它能实时显示系统中各个进程的资源占用情况。当CPU满载时，我通常这样使用：
bash复制top -c
关键操作要点：
- 观察%Cpu(s)行：us表示用户态CPU，sy表示内核态CPU。如果us接近100%，通常是应用代码问题；sy高则可能是系统调用过多
- 按下Shift+P：按CPU使用率排序，快速定位问题进程
- 注意NI(优先级)和PR(进程优先级)列：数值越大优先级越低
- -c参数显示完整命令：方便识别具体是哪个应用实例
2.2 使用pidstat获取更精确数据
当系统负载极高时，top本身的资源消耗可能会影响诊断。这时pidstat是更好的选择：
bash复制pidstat -u -p ALL 1 5
这个命令每1秒采样一次，共采样5次，输出所有进程的CPU使用情况。其中：
- %usr列显示用户态CPU占比
- %system列显示内核态CPU占比
- %guest列显示运行虚拟机CPU占比
- %wait列显示进程等待CPU的时间占比
经验分享：当%wait列数值较高时，通常说明系统存在CPU资源竞争，可能是进程/线程数过多导致的调度开销。
3. 深入分析问题进程
3.1 定位进程内的异常线程
找到高CPU进程后，需要进一步分析其线程情况。我常用的方法：
bash复制top -H -p [PID]
关键步骤：
- 记下高CPU线程的PID（实际是线程ID，十进制）
- 将线程ID转为十六进制（perf等工具需要）：
bash复制printf "%x\n" [TID] - 观察多个采样周期，确认是持续高CPU还是瞬时峰值
3.2 使用ps命令补充分析
bash复制ps -T -p [PID] -o tid,pcpu,comm
这个命令可以：
- 显示指定进程的所有线程(-T)
- 输出线程ID、CPU占用率和命令名称
- 比top更轻量，适合极高负载场景
4. 代码级问题定位
4.1 使用pstack快速获取线程堆栈
bash复制pstack [PID] > stack.log
分析要点：
- 找到对应线程的堆栈信息
- 关注栈顶函数，通常是CPU消耗的源头
- 对比多个时间点的堆栈，观察是否卡在相同位置
4.2 使用gdb进行交互式诊断
当pstack不可用时，gdb是强大的替代方案：
bash复制gdb -p [PID]
(gdb) thread apply all bt
注意事项：
- 附加到运行中进程会导致短暂停顿
- 生产环境慎用，最好在测试环境复现问题
- 操作完成后及时detach，不要直接退出
4.3 使用perf进行性能剖析
perf是Linux内核自带的性能分析工具，功能强大：
bash复制perf top -p [PID]
进阶用法：
bash复制# 记录30秒的性能数据
perf record -g -p [PID] sleep 30
# 生成报告
perf report -n --stdio
性能分析技巧：使用--sort=dso可以按模块统计CPU消耗，快速定位是哪个so或可执行文件的问题。
5. 常见问题场景分析
5.1 死循环问题特征
- 用户态CPU接近100%
- 堆栈显示停留在同一函数
- 通常不涉及系统调用
- 常见于数值计算、循环处理等场景
5.2 锁竞争问题特征
- 系统上下文切换(cs)指标飙升
- 大量线程处于D状态(不可中断睡眠)
- perf显示大量时间花费在futex等锁操作上
- 通常伴随少量CPU占用但性能极差
5.3 系统调用过多特征
- 内核态CPU(%sys)占比高
- strace显示频繁的read/write等调用
- 通常伴随少量的用户态CPU
- 常见于不合理的IO操作设计
6. 应急处理措施
6.1 调整进程优先级
bash复制renice +19 [PID]
这会将进程优先级降到最低，缓解CPU压力但保持进程运行，方便进一步诊断。
6.2 控制组(cgroup)限制
bash复制cgcreate -g cpu:/cpulimit
cgset -r cpu.cfs_quota_us=50000 cpulimit # 限制50%CPU
cgexec -g cpu:cpulimit [command]
这种方法比直接kill更优雅，可以精确控制CPU使用上限。
6.3 针对性线程控制
bash复制kill -STOP [TID] # 暂停问题线程
kill -CONT [TID] # 恢复线程
相比直接kill，这种方式更安全，可以在不影响整体服务的情况下控制问题线程。
7. 高级诊断技巧
7.1 火焰图生成与分析
火焰图能直观展示CPU时间消耗分布：
bash复制perf record -F 99 -g -p [PID] -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg
分析要点：
- 横向宽度表示时间占比
- 纵向表示调用栈深度
- 顶部通常是实际消耗CPU的函数
7.2 动态追踪技术
使用SystemTap或BPF进行高级诊断：
bash复制# 使用bpftrace跟踪某个函数的调用
bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'
这些工具可以：
- 跟踪特定函数的调用频率
- 统计系统调用耗时分布
- 分析锁竞争情况
- 跟踪内存分配模式
8. 预防与优化建议
8.1 代码层面
- 循环体内必须包含退出条件检查
- 避免在热路径上进行不必要的系统调用
- 合理使用缓存减少重复计算
- 多线程程序注意锁的粒度
8.2 系统层面
- 设置合理的进程资源限制(ulimit)
- 使用cgroup进行资源隔离
- 关键服务配置守护进程监控
- 建立性能基线，设置告警阈值
8.3 监控体系
- 部署Prometheus+Granfa监控系统
- 对关键指标设置告警：
- CPU使用率
- 负载均衡
- 上下文切换率
- 系统调用频率
- 定期进行压力测试
在实际工作中，我发现约70%的CPU满载问题源于代码逻辑缺陷，特别是缺乏边界条件检查的死循环。另外20%来自不合理的架构设计，如单线程处理队列等。剩下的10%才是真正的硬件资源不足问题。