top本身不够，需结合load average、%cpu(s)中us/sy占比、time+、wchan及线程视图等综合判断真cpu瓶颈，并排除i/o等待、容器限频、锁阻塞等干扰项。
直接看 top 本身不够——它只显示“谁在用 CPU”，但卡顿往往不是 CPU 真被占满，而是进程卡在等待（比如磁盘、锁、网络），此时 %CPU 反而很低。精准定位 CPU 大户，关键在于看清真实负载来源、区分瞬时与持续占用、穿透到线程级，并排除干扰项。
先确认是不是真 CPU 问题
顶部 load average（1/5/15 分钟）持续高于 CPU 核心数，且 %Cpu(s) 中 us（用户态）或 sy（内核态）长期 >80%，才说明是 CPU 真瓶颈。如果 id（idle）很高但系统仍卡，大概率是 I/O 或内存问题，别死盯 %CPU 列。
- 按 1 键展开所有 CPU 核心，避免单核打满（如 100%）而整体平均值仅 25% 的误判
- 按 Shift + M 切换内存排序，若 RES 高、%MEM 持续 >80%，可能触发 swap 或 OOM，此时 CPU 占用低但响应极慢
- 注意状态列 S：D（不可中断睡眠）进程不贡献 %CPU，却在等磁盘或内核锁——这才是卡点，不是“CPU 大户”但比它更致命
聚焦真正耗 CPU 的进程和线程
%CPU 是“自上次刷新以来”的占比，不是持续占用率。短时 burst（如日志刷盘、GC）会造成假高峰；而 TIME+ 值大 + %CPU 稳定高，才是长期霸占 CPU 的证据。
- 按 P（大写）确保按 %CPU 降序，再按 Shift + H 开启线程视图——Java、数据库等多线程应用，热点常藏在某个子线程里
- 按 f 进入字段管理，启用 WCHAN（等待的内核函数）和 TIME+，结合看：TIME+ 突增 + WCHAN 为空（即 RUNNING/RUNNABLE），才确认是纯 CPU 计算型消耗
- 按 u 输入用户名，快速过滤业务账户，避开 root/systemd 等系统进程干扰
交叉验证，排除常见假象
容器、虚拟化、驱动层都可能导致 top 显示失真。单靠 top 得出结论容易翻车。
- 容器环境：宿主机 top 看到的 PID 是容器内 PID，%CPU 可能被 cgroup 限频扭曲。应同步查
cat /sys/fs/cgroup/cpu/xxx/cpuacct.usage_percpu或docker stats - GPU 驱动锁定内存：老版 NVIDIA 驱动会把大量内存锁进显存，导致可用内存骤降、频繁 swap。运行
nvidia-smi -q -d MEMORY和cat /proc/driver/nvidia/params | grep -i lock交叉验证 - slab 泄漏：
slabtop查看 dentry、size-4096 占比是否超 60%，大量小文件操作后未 sync 容易引发此问题，表现为内存“莫名吃紧”、CPU 却不高
定位后下一步做什么
拿到高 CPU 进程 PID 后，别急着 kill。先抓上下文，再决定是调优、重启还是深入分析。
- 查命令行和线程关系：
ps -p PID -o pid,tid,ppid,comm,%cpu,time,args - 看内核栈（需 root）：
cat /proc/PID/stack，若停在mutex_lock或wait_event，说明卡在锁或等待，不是 CPU 计算问题 - Java 应用：
jstack PID | grep -A 10 'nid 0x[0-9a-f]\+.*RUNNABLE'（线程 ID 先转十六进制） - 通用分析：
strace -p PID -c统计系统调用耗时，高频futex或epoll_wait暗示锁争用或事件循环阻塞
