mpstat -P ALL 是唯一能原生、准确、持续输出每核/每线程实时利用率的工具，直接读取 /proc/stat 原始计数器，按秒级精度拆分 us/sy/id/wa/hi/si；top 按 1 键仅视觉拆分，数值为平均值且不区分 hi/si。
mpstat -P ALL 是最直接的命令
要看到每个逻辑 CPU（包括超线程线程）的实时利用率，mpstat -P ALL 是唯一能原生、准确、持续输出每核/每线程统计的工具。它不依赖进程视角，而是直接读取内核 /proc/stat 的原始计数器，按秒级精度拆分 us/sy/id/wa/hi/si 等字段。
常见错误是只用 top 按 1 键展开——那只是把整体 CPU 行“视觉上”拆成条形图，数值仍是采样窗口内的平均值，且不区分硬中断（hi）和软中断（
si</code），更不提供 per-thread 的独立统计。</p> <ul> <li><code>mpstat -P ALL 1：每秒刷新一次，所有逻辑 CPU（如 8 核 16 线程就显示 0–15 号）+ 一个
all 汇总行
mpstat -P 0,1,16 2：只监控物理核心 0、1 和对应超线程的第 2 个线程（编号 16），减少干扰lscpu 的 CPU(s) 总数和 Thread(s) per core 决定，不是随便猜的htop 能看线程但默认不显示 per-thread 利用率
htop 界面顶部的 CPU 条形图确实是 per-logical-CPU 的，但它只显示单一百分比（通常是 us+sy 合并值），没有 wa、si、hi 等细分维度。而且它的刷新逻辑和内核计数器不同步，偶尔会出现瞬时跳变或滞后。
如果你真想在 htop 里关联线程和 CPU，得配合其他命令：
- 先在
htop里按H显示线程（而非进程），再按F2→ “Columns” → 添加PROCESSOR列，才能看到每个线程绑定到哪个逻辑 CPU - 但此时你看到的是调度归属，不是该线程在那个 CPU 上实际占用了多少时间——这必须靠
mpstat或perf top -t -
htop不支持导出 per-CPU 时间片明细，无法做历史对比或自动化分析
别误用 top -H 或 ps -T 当作线程级 CPU 监控
top -H 或 ps -T 显示的是线程列表，但它们的 %CPU 字段是**进程级采样窗口内所有线程的累计值均摊到单个线程上**，不是该线程在特定 CPU 上的真实占用。比如一个 4 线程进程占满一个 CPU（100%），top -H 可能显示四个线程各 25%，但这不代表每个线程只用了 25%——可能是一个线程霸占了全部时间，其余三个几乎空转。
这种统计方式在排查锁竞争或调度延迟时反而会误导判断：
- 高
%CPU线程不一定跑在高频 CPU 上，可能刚被迁移到低频核 - wa 值为 0 的线程，不代表它没在等 I/O——它可能正休眠，而
wa统计的是 CPU 等待时刻，不是线程状态 - 真正要看线程级瓶颈，得用
perf record -e cycles,instructions,task-clock -p <pid></pid>，再perf report -g看热点函数绑定在哪颗核
需要脚本化或存档时，优先用 mpstat -o JSON
如果要把 per-CPU 数据喂给 Prometheus 或写入日志做长期趋势分析，mpstat -P ALL -o JSON 1 是唯一稳妥选择。前提是 sysstat ≥ 11.7.3，否则 JSON 输出不可用。
注意几个坑：
- JSON 输出里
"cpu-load" : "all"对应汇总行，"cpu-load" : "0"才是逻辑 CPU 0；别把all当成某个真实核心 - 字段名随版本变化：
usr（旧版） vsuser（新版），解析前先mpstat -V确认版本 - 间隔设太小（如
0.1）会导致内核统计抖动，mpstat自身开销也会上升，1 秒是生产环境推荐下限
线程编号和物理拓扑关系容易混淆，lscpu 和 mpstat -P ALL 输出对齐后才敢说“这个 98% 是 CPU 3 上的超线程 B 在干活”。
