不能只信top默认界面第一行，因%Cpu(s)仅为全局快照，不指向具体进程；须按P键强制%CPU降序，结合PID与%CPU列定位高耗进程，并注意wa、sy、st等指标交叉验证真实瓶颈。
直接用 top 就能看，但只敲 top 不够——得确认排序、识别干扰项、再交叉验证。
为什么不能只信 top 默认界面的第一行？
很多人一进 top 就盯着顶部 %Cpu(s) 行的总占用率，比如看到 92.1% us 就慌，其实这行只是全局快照，不指向具体进程。真正要找“谁在吃 CPU”，必须往下看进程列表，并确保它真按 CPU 排序。默认虽是，但可能被你或别人按过其他键（比如 M 切到内存排序）而失效。
- 进
top后第一件事：按P（大写 P），强制按%CPU降序 —— 别依赖“默认” - 重点关注两列：
PID（后续所有操作都靠它）和%CPU（注意：多核下可超 100%，比如 247% 表示占满 2.47 个核） - 如果
%CPU最高值只有 5–10%，但系统卡顿，大概率不是 CPU 瓶颈，而是wa（I/O 等待）或st（虚拟机被偷资源）高，回头再查
ps aux --sort=-%cpu | head -10 更适合脚本或快速导出
top 是交互式、动态的，适合人工盯屏；但如果你要写监控脚本、发告警、或者一次性导出 top10 做分析，ps 更干净、无状态、不依赖终端尺寸。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
ps aux --sort=-%cpu | head -10输出字段固定，含USER、%CPU、%MEM、完整COMMAND，一眼能判是否是预期服务（比如java或nginx） - 想过滤某类进程？加
grep：ps aux --sort=-%cpu | grep -E "(java|python)" | head -5 - 注意：
ps是快照，不是实时流；两次执行间隔哪怕 0.1 秒，结果都可能不同 —— 别拿它当top的替代品，而是互补
常见误判：%CPU 高 ≠ 进程真在忙
进程列表里某个 %CPU 显示 85%，但它可能根本没干活 —— 比如正卡在磁盘读写、网络收包、或等锁。这时候看 top 头部的 wa（iowait）或 sy（内核态）占比更关键。
- 如果
%Cpu(s): 12.0%us, 5.0%sy, 0.0%ni, 78.0%id, 4.0%wa→ 真正瓶颈是磁盘，%CPU高的进程只是在等 IO，杀它没用，得查iostat -x 1 - 如果
us很低但sy超过 30%，说明大量时间花在系统调用上，可能是频繁fork、epoll_wait、或驱动异常，不是业务代码问题 - 如果
st（steal）明显（>5%），说明你在虚拟机里，宿主机 CPU 被隔壁 VM 抢光了，联系运维查宿主机负载
别跳过线程层：单个进程 %CPU 高，但可能是某一个线程疯跑
Java、Go、Node.js 这类多线程服务，经常出现“整个进程占 300% CPU，但主线程很闲，某个 worker 线程死循环”。这时候只看进程级 %CPU 会漏掉根因。
- 先拿到高 CPU 进程的
PID（比如 1234），然后运行：top -H -p 1234→ 切换到线程视图，同样按P排序 - 找到
TID（线程 ID，显示为PID列），记下来（比如 1240） - 转成十六进制：
printf "%x\n" 1240→ 得到4d8，再用jstack 1234 | grep -A 10 "4d8"定位 Java 线程栈（非 Java 用perf record -p 1234）
真正难的不是找到那个线程，而是理解它为什么卡在 HashMap.get() 或 epoll_wait —— 那得结合应用日志和代码逻辑，工具只能指路，不能代劳。
