Linux系统CPU信息查看：从核心数到超线程的完整指南
在Linux服务器运维、性能调优或者资源规划时，搞清楚“这台机器到底有几个CPU”是第一步。但这事儿，说简单也简单，说复杂也复杂——简单在于，几个命令就能出结果；复杂在于，物理核心、逻辑处理器、超线程这些概念容易混淆，稍不留神就会数错。今天，我们就来把几个常用命令掰开揉碎了讲清楚。
直接看逻辑CPU总数用 nproc
如果你只想要一个数字，一个代表系统当前能并行处理多少任务的总数，那么nproc命令无疑是最直接的选择。运行它，屏幕上蹦出来的那个数字，就是逻辑处理器（通常可以理解为线程）的总数。这个数字是怎么来的呢？其实就是“物理CPU颗数”乘以“每颗CPU的物理核心数”，再乘以“超线程的倍数”（如果开启的话）。
不过，这里有个常见的坑需要避开：nproc返回的是系统全局可用的逻辑CPU总数，它不受进程绑定（taskset）或者容器资源限制（cgroups）的影响。换句话说，即使你把一个进程绑定在了前两个CPU上，或者在一个只分配了2个CPU的容器里运行nproc，它依然会告诉你宿主机总共有多少个逻辑CPU。如果需要查看当前进程实际能被调度到哪些CPU上，得用taskset -p 进程ID来查。
正因为它的输出简洁到只有一个数字，所以nproc特别适合在脚本中捕获使用，比如cores=$(nproc)。但务必记住前面提到的限制，尤其在容器化环境中，这个值可能并不能反映容器真实的可用计算资源。
lscpu 一眼看清物理/逻辑/超线程关系
想要一眼看穿CPU的“家底”，lscpu才是那个“全能选手”。它用结构化的方式，把物理插槽、核心、线程的关系列得明明白白。解读它的输出，关键要盯住下面几个字段：
CPU(s):逻辑处理器总数，和nproc的输出是一致的。Socket(s):物理CPU插槽数，也就是主板上实际插了几颗CPU。Core(s) per socket:每颗物理CPU内部包含的物理核心数量。Thread(s) per core:每个物理核心能模拟出的逻辑线程数。这里是1，代表超线程关闭；是2，代表超线程开启。
如何验证超线程是否真的在起作用？很简单，做个乘法：用 Socket(s) 乘以 Core(s) per socket 再乘以 Thread(s) per core，看看结果是否等于 CPU(s)。如果相等，那超线程就是生效的。如果不相等，比如Thread(s) per core显示是2，但逻辑CPU总数却没翻倍，那很可能是在BIOS里关闭了超线程，或者内核启动时使用了nosmt这类参数。
从 /proc/cpuinfo 手动统计容易漏掉的细节
/proc/cpuinfo文件提供了最原始、最详细的CPU信息，堪称“宝库”。但手动用grep和wc去挖掘时，陷阱也不少，一个不小心就会数错。
cat /proc/cpuinfo | grep “processor” | wc -l：这个方法是对的，得到的是逻辑CPU的数量。cat /proc/cpuinfo | grep “physical id” | sort -u | wc -l：这是获取物理CPU颗数的正确姿势。注意，必须先用sort -u，因为uniq命令只能去除相邻的重复行，如果物理ID未排序，去重就会失败。cat /proc/cpuinfo | grep “cpu cores” | uniq：这个命令输出的是每颗物理CPU的核心数（例如“cpu cores : 16”），千万别把这个数字误认为是所有CPU的核心总数。cat /proc/cpuinfo | grep “siblings” | uniq：“siblings”字段表示每颗物理CPU内部的总逻辑线程数（包含了超线程）。把它和上面的“cpu cores”对比，如果siblings值是cpu cores值的两倍，通常就表明超线程开启了。
还有一个特别需要注意的细节：core id字段只在单颗多核CPU的系统中能唯一标识一个物理核心。在多路服务器（多个物理CPU）上，不同物理CPU可能拥有相同的core id值。因此，绝对不能通过统计唯一core id的数量来计算总的物理核心数，那样会漏算。
为什么 top 或 htop 显示的 CPU 列数不等于物理核心数？
用top或htop看系统负载时，顶部那一排CPU使用率柱状图常常让人困惑：明明机器是32个物理核心，为什么这里显示了64列？
原因在于，这些工具默认展示的是操作系统调度器所看到的“可调度单元”，也就是逻辑处理器。超线程模拟出来的逻辑CPU，在这里也会被单独显示为一列。所以，你看到64列，对应的可能是32个物理核心加上超线程带来的32个逻辑核心。
这意味着：
htop中可以通过设置（F2 → Display options → Hide userland threads）来隐藏用户态线程，但这并不会把超线程对应的逻辑核心“合并”掉。- 如果想观察物理核心级别的负载压力，需要借助更专业的工具。例如，使用
mpstat -P ALL 1可以查看每个逻辑CPU的详细中断和上下文切换情况；或者用perf stat -C 0-7来监控指定编号的物理核心的性能事件。
最后必须提一句，超线程并非“性能倍增器”。它能带来多少性能提升，极度依赖于工作负载的类型。对于某些延迟敏感型或计算密集型应用，关闭超线程反而能获得更稳定、更可预测的性能表现。因此，数清楚核心只是第一步，理解负载特性并合理配置，才是性能优化的关键所在。
