物理核心总数 = Socket(s) × Core(s) per socket，lscpu 中这两字段并列存在、无需计算；CPU(s) 表示逻辑线程总数，/proc/cpuinfo 的 cpu cores 非全局总数，dmidecode -t processor 的 Core Count 最接近硬件真实值，nproc 等仅反映当前可见逻辑 CPU 数。
lscpu 里哪几行直接对应物理核心总数
物理核心总数 = Socket(s) × Core(s) per socket，这两个字段在 lscpu 输出里是并列存在的，不用算、不用猜。比如看到：
Socket(s): 2<br>Core(s) per socket: 16<br>Thread(s) per core: 2
那就明确表示：2 颗物理 CPU，每颗 16 个物理核心，总共 32 个物理核心——不是 64，64 是逻辑线程数。
容易踩的坑：
-
CPU(s)字段只反映逻辑处理器总数，新手常误以为这就是“核数” -
Core(s) per socket是单颗 CPU 的物理核数，不是全系统总和；必须乘Socket(s) - 某些 ARM 虚拟机或容器镜像里
lscpu可能不显示Socket(s)，此时要结合dmidecode -t processor或dmesg | grep -i cpu辅助判断
为什么别直接用 /proc/cpuinfo 里的 cpu cores 字段
/proc/cpuinfo 每条记录都带 cpu cores，但它只表示“当前 physical id 对应那颗 CPU 的核心数”，不是全局总数。常见错误是：
grep "cpu cores" /proc/cpuinfo | wc -l
这实际统计的是“有多少条记录含该字段”，毫无意义。
正确提取方式（仅适用于多物理 CPU 且配置一致）：
- 取第一条的值：
grep "cpu cores" /proc/cpuinfo | head -n1 | cut -d: -f2 | xargs - 再手动乘以物理 CPU 数：
grep "physical id" /proc/cpuinfo | sort -u | wc -l
但注意：VMware/KVM 环境下 physical id 常全为 0，导致结果恒为 1；ARM 平台可能压根没这个字段。所以不能单靠它。
dmidecode -t processor 是 BIOS 层最准的物理核心来源
当 lscpu 和 /proc/cpuinfo 出现矛盾，或你怀疑 BIOS 关闭了部分核心时，sudo dmidecode -t processor 是最接近硬件出厂规格的依据。
重点看这两行：
-
Core Count：BIOS 报告的物理核心总数（不含超线程） -
Thread Count：BIOS 报告的最大并发线程数
它不依赖内核运行时状态，也不受 cgroups 或 CPU pinning 影响。但需 root 权限，且部分云主机（如 AWS EC2）会屏蔽 DMI 信息，返回空或无效值。
别被 nproc 和 getconf _NPROCESSORS_ONLN 迷惑
nproc 和 getconf _NPROCESSORS_ONLN 返回的只是当前进程可见的在线逻辑 CPU 数，它受以下因素影响：
- cgroups 限制（如 Docker 容器设了
--cpus=2） - 内核启动参数
maxcpus=或isolcpus= - CPU offline（如
echo 0 > /sys/devices/system/cpu/cpuX/online）
比如 nproc 输出 8，不代表机器只有 8 核——可能是双路 16 核服务器，但被 systemd-cgtop 限制了资源。它永远不体现物理拓扑，纯属运行时调度视图。
真实物理核心数必须回到 lscpu 的 Socket(s) 和 Core(s) per socket，或者 dmidecode 的 Core Count。其他所有命令都是辅助或易偏移的参考。
