top是必须立即执行的首个命令，用于判断CPU占用类型（us/sy/wa/id）、定位高负载进程及线程、结合strace/perf/py-spy等工具深入分析，并需结合业务场景判断是否真异常。
top 是你第一个该敲的命令，不是“可能有用”，而是必须立刻执行。它能直接告诉你当前谁在吃 CPU、吃的是用户态还是内核态、有没有大量 I/O 等待——这些信息决定了后续排查方向，跳过这步等于蒙眼修车。
怎么看 top 输出里的关键指标
启动后别急着扫进程列表，先盯住顶部那行 %Cpu(s)：us、sy、wa、id 这几个值才是诊断起点。
-
us高（比如 >70%）且wa很低 → 问题大概率在你自己跑的程序里，比如 Python 脚本死循环、Java 应用某方法卡住 -
wa高（比如 >20%）而us和sy都很低 → CPU 其实在干等磁盘，不是真忙，得切到iostat -x 1看%util和await -
sy高（比如 >30%）→ 内核调用太频繁，可能是大量小文件读写、频繁fork、或驱动异常，用perf top -g -p <pid></pid>看内核栈 -
id接近 100% 但负载（load average）却很高 → 注意看有没有大量D状态进程（不可中断睡眠），这是磁盘卡死的典型信号，ps aux | awk '$8 ~ /D/ {print}'可快速过滤
定位具体进程和线程的实操顺序
别一上来就 kill -9，先确认是不是真要杀。重点是快速锁定“最烫的那个点”：
- 在
top里按P（大写）按 CPU 使用率降序，记下第一行的PID - 再执行
top -Hp <pid></pid>，同样按P，找线程级的“罪魁”——注意列名还是PID，但这是线程 ID - 把线程 ID 转成十六进制：
printf "%x\n"，结果用于下一步堆栈匹配 - Java 进程：直接
jstack <pid> | grep -A 10 ""</pid>，看是不是卡在HashMap.get或某个正则匹配上 - C/C++/Go 等原生进程：用
perf record -p <pid> -g -- sleep 10</pid>录 10 秒，再perf report -g看热点函数
perf 不可用时的替代方案
很多生产环境没装 perf，或者权限受限。这时候别硬等，有更轻量的路径：
- 先试
strace -p <pid> -c</pid>（加-c是统计模式），几秒就能看到最耗时的系统调用，比如全是epoll_wait就可能是网络事件堆积，全是read就可能是日志刷太猛 - 对 Python 进程，
py-spy record -p <pid> -o profile.svg</pid>（需提前装 py-spy）比strace更友好，能直接看到 Python 函数级火焰图 - 如果连
strace都被禁用，就用cat /proc/<pid>/stack</pid>（仅限内核支持），看当前线程在内核哪条路径上卡住，常见输出如[<ffffffff81204b5d>] __do_page_fault+0x2ad/0x4f0表示缺页异常频繁
真正难的不是找到高 CPU 进程，而是判断“它该不该这么高”。比如一个定时归档脚本在凌晨 2 点把 CPU 拉到 95%，只要持续时间短、不影响业务，可能根本不用动；但同一个脚本白天持续 30 分钟不退，就得查它是不是误读了错误的文件路径导致遍历全盘。这类边界情况，工具给不出答案，得结合业务节奏和历史基线来判断。
