nproc最简单粗暴地显示当前可用逻辑cpu总数，即物理cpu数×每颗核心数×超线程倍数；lscpu则清晰区分socket(s)、core(s) per socket、thread(s) per core，精准反映物理与逻辑关系。
直接看逻辑CPU总数用 nproc
最简单粗暴的方法：运行 nproc，它输出的就是当前系统可用的逻辑处理器（即线程）总数。这个值等于「物理CPU个数 × 每颗CPU核心数 × 超线程倍数」。它不区分物理/逻辑，只告诉你系统现在能跑多少个并行任务。
常见误区：nproc 不受 taskset 或 cgroups 限制影响——它返回的是全局可用数，不是当前进程被允许使用的数。如果需要查当前进程绑定的CPU范围，得用 taskset -p $PID。
- 输出是纯数字，适合脚本直接捕获，比如
cores=$(nproc) - 在容器里执行时，若启用了 CPU 配额（如
--cpus=2），nproc仍返回宿主机总逻辑数，不是容器可见数
lscpu 一眼看清物理/逻辑/超线程关系
lscpu 是唯一能同时、清晰列出物理插槽数、每槽核心数、每核线程数的命令。关键字段含义必须盯住：
-
CPU(s):→ 逻辑处理器总数（等同nproc输出） -
CPU socket(s):→ 物理CPU插槽数（即几颗物理CPU） -
Core(s) per socket:→ 每颗物理CPU有多少个物理核心 -
Thread(s) per core:→ 是否启用超线程（1 = 关，2 = 开）
验证超线程是否生效：如果 Thread(s) per core 是 2，且 CPU(s) 等于 CPU socket(s) × Core(s) per socket × 2，那就确认启用了。否则可能 BIOS 里关了，或内核启动参数加了 nosmt。
从 /proc/cpuinfo 手动统计容易漏掉的细节
虽然 /proc/cpuinfo 信息全，但直接 grep + wc -l 容易出错，因为字段语义有陷阱：
-
cat /proc/cpuinfo | grep "processor" | wc -l→ 正确，逻辑CPU数 -
cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l→ 物理CPU个数（注意必须sort -u，不能只uniq，否则未排序的重复行会漏去重） -
cat /proc/cpuinfo | grep "cpu cores" | uniq→ 每颗物理CPU的核心数（输出形如cpu cores : 16，别误当成总数） -
cat /proc/cpuinfo | grep "siblings" | uniq→ 每颗物理CPU的逻辑线程总数（含超线程），用于和cpu cores对比判断是否开启超线程
特别注意：core id 字段只在多核单CPU时可靠；在多路服务器上，不同物理CPU可能有相同 core id，所以不能靠它算总核数。
为什么 top 或 htop 显示的 CPU 列数不等于物理核心数？
top 默认按逻辑CPU显示负载条（比如 32 根竖条），这反映的是调度器看到的可运行单元数，也就是逻辑处理器数。它不隐藏超线程，也不合并物理核心——哪怕两个逻辑CPU共享一个物理核心，它们在 top 里仍是独立的两列。
这意味着：
- 如果你看到 64 列 CPU 使用率，不代表有 64 个物理核心，可能是 32 核 + 超线程
-
htop可以按F2 → Display options → Hide userland threads关闭线程视图，但依然不会合并超线程逻辑核 - 真正想看物理核心级负载，得结合
perf stat -C 0-7（指定物理核心范围）或用mpstat -P ALL 1观察每个逻辑CPU的中断/上下文切换分布
超线程带来的性能提升高度依赖工作负载类型，单纯看核心数没意义；实际压测时，关闭超线程有时反而提升延迟敏感型应用的稳定性。
