Linux排查CPU负载高需先确认是否真过载（load÷核数＞1），再据top中us/sy/wa/si定位瓶颈类型，最后用pidstat、jstack、perf等深入进程、线程及内核层验证根因。
Linux 中排查 CPU 负载居高不下，关键不是“找哪个进程占 CPU 多”，而是分清三件事：负载是不是真高、高在哪儿（用户态？内核态？等待？）、高得合不合理。很多卡顿现象表面是 CPU 高，实际是上下文切换太多、软中断压垮调度器，或者进程在等磁盘却堆在 run queue 里冒充“CPU 消耗”。下面按真实排障顺序说清楚。
先确认负载是否异常，别被单个数字带偏
运行 uptime 看 load average 三个值（1/5/15 分钟），然后立刻查 CPU 核数：lscpu | grep "CPU(s)"
如果 8 核机器 load 是 6，正常；2 核机器 load 是 4，就已严重过载。更要看趋势：1 分钟值远高于 15 分钟值，说明刚爆发；三值都持续高于核数，说明积压已久。此时再敲 top，注意顶部的 %Cpu(s) 行：
- %us（用户态）高 → 应用层计算密集，比如 Java 死循环、Python 脚本没加 sleep
- %sy（内核态）高 → 系统调用频繁，常见于大量小文件读写、锁竞争、线程创建销毁过多
- %wa（I/O 等待）高 → 不是 CPU 问题，是磁盘或存储响应慢，进程卡在不可中断睡眠（D 状态）
- %si（软中断）高 → 网络包处理不过来，比如 nginx 或 Kafka 承受突发流量、网卡收包队列溢出
定位到具体进程和线程，避免只看“整体”
top 按 P 键按 CPU 排序，找到 PID。但别急着 kill，先确认它干的是不是正经事：ps -p PID -o pid,ppid,user,%cpu,%mem,cmd
再用 pidstat 看它的动态表现：
-
pidstat -u 1 5：每秒采样 5 次，看 CPU 占用是否稳定波动还是突然尖峰 -
pidstat -t -p PID 1：展开该进程所有线程，按 %CPU 排序，找出真正吃资源的 TID
若发现某个 Java 进程 CPU 飙高，把高耗线程 TID 转成十六进制：printf "%x\n" TID
再用 jstack PID | grep -A 20 十六进制TID 查线程堆栈，看是 GC 频繁、正则回溯，还是无限重试连接。
深入内核层，揪出隐藏瓶颈
有些情况 top 显示 CPU 使用率不高，但系统就是卡——这时候要盯上下文切换和中断：
-
vmstat 1：重点看cs（每秒上下文切换次数）。正常服务器几百到几千；超过 5 万/秒，大概率有线程风暴或锁争用 -
mpstat -P ALL 1：看各 CPU 核是否均衡。若只有 core 0 一直 100%，其他全空闲，说明程序没做多线程优化或绑核不合理 -
cat /proc/interrupts：检查某块网卡或磁盘的中断是否集中在单个 CPU 上，可能引发软中断堆积 -
perf top -g（需安装 perf）：直接看到内核函数热点，比如tcp_v4_do_rcv或__alloc_pages_slowpath占比极高，就能判断是网络协议栈压力大还是内存回收拖累
验证根因，别靠猜
最后一步必须闭环：你怀疑是某 Java 线程死循环，就得看到它在 jstack 里反复执行同一行代码；你怀疑是软中断，就得用 ss -s 看 socket 队列长度、用 netstat -s | grep -i "retrans" 看重传激增。不要跳过日志佐证：dmesg -T | tail -30 查最近内核报错journalctl -u your-service --since "2 hours ago" | grep -i "error\|warn" 查服务自身异常
