top 默认按cpu使用率降序排列但显示采样周期内平均值，3秒刷新易掩盖瞬时尖刺；需用top -d 0.5并按p排序，注意线程视图、容器pid映射、进程名截断等问题。
top 命令看不准高 CPU 进程？先确认 top 的默认排序和刷新逻辑
top 默认按 CPU 使用率降序排列，但很多人没注意到：它显示的是「采样周期内平均值」，且默认刷新间隔是 3 秒——短时脉冲型 CPU 尖刺（比如 200ms 的密集计算）极易被平滑掉。如果你怀疑有瞬时占用，必须手动调高刷新频率：top -d 0.5（每 0.5 秒刷新），再按 P 确保按 CPU 排序。
常见误判场景：
- 看到某个
java进程占 95%，但实际是多个线程在争抢 CPU，top默认不显示线程视图 - 容器化环境里，宿主机
top看到的 PID 是容器内 PID，和docker ps或crictl ps不对应 - 某些进程名被截断（如
python3 /opt/app/xxx…），真实命令行需用ps -T -p <pid> -o pid,tid,%cpu,comm,args</pid>补全
定位到进程后，为什么 pstack 和 perf top 结果对不上？
pstack <pid></pid> 只抓当前时刻的用户态调用栈快照，适合看 Java/C++ 应用是否卡死在某个锁或循环里；而 perf top -p <pid></pid> 是基于硬件事件采样的统计视图，能暴露热点函数（包括内核路径），但需要 perf 权限支持且默认不解析符号（尤其 Go/Java 需额外配置）。
实操建议：
- 先跑
perf record -g -p <pid> -a -- sleep 10</pid>录 10 秒，再用perf report -n --no-children看带调用次数的火焰图式报告 - Java 进程优先用
jstack <pid></pid>，比pstack更准（能识别 JVM 线程状态） - Go 程序记得加编译参数
-gcflags="all=-N -l"，否则perf无法解析函数名
查到是某个系统调用（如 futex、epoll_wait）占 CPU，下一步怎么切？
这类调用本身不耗 CPU，高占比说明进程在频繁进出内核——本质是应用逻辑问题，比如：
-
futex高频：线程争抢锁太激烈，或使用了低效同步原语（如std::mutex在无竞争时也走内核） -
epoll_wait返回频繁但处理慢：I/O 事件多但业务逻辑阻塞（如数据库查询未加索引、JSON 解析大 payload） -
nanosleep异常高：程序在自旋等待，可能漏掉了条件变量唤醒或信号丢失
验证方法：
strace -p <PID> -e trace=futex,epoll_wait,nanosleep -c
看各系统调用的调用次数与耗时总和；再配合 /proc/<pid>/stack</pid> 看内核栈（需 root），确认是否卡在特定驱动或子系统。
容器内进程 CPU 虚高？检查 cgroup 限制和 cpu.shares 是否被误设
宿主机 top 显示某容器内进程 CPU 使用率超 100%，往往不是真超，而是 cgroup v1 的 cpu.shares 机制导致的归一化偏差——当容器只分配到 512 份 shares（默认 1024），而宿主机有 16 核，该容器最多只能用 0.5 核，此时它的「CPU%」在 top 里会显示为 50% × 16 = 800%，造成误判。
正确做法：
- 进容器查
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us，算实际配额（如 -1 表示不限制） - 宿主机上用
docker stats <container></container>或crictl stats，它们读取的是 cgroup 统计，数值更可信 - 避免混用 cgroup v1/v2：Kubernetes 1.20+ 默认启 v2，但部分发行版内核仍默认挂载 v1，会导致
/sys/fs/cgroup/cpu/下路径行为不一致
真正难啃的是那种「CPU 利用率 30%，但响应延迟飙升」的情况——那大概率是 CPU 调度器被干扰，或者 NUMA node 绑定错乱，这时候得看 perf sched latency 和 numastat -p <pid></pid>。
