逻辑CPU个数用lscpu查最准，即CPU(s):字段值；物理核心总数=Socket(s)×Core(s) per socket；运行时可用核数应以nproc或getconf _NPROCESSORS_ONLN为准。
查逻辑CPU个数：lscpu 最快最准
系统能调度的“CPU”数量，就是逻辑CPU个数（含超线程）。lscpu 一行命令直接给出 CPU(s): 字段，比如输出 CPU(s): 16，就表示当前有 16 个可被调度的逻辑处理器。
- 比
cat /proc/cpuinfo | grep processor | wc -l更可靠——后者在某些容器或虚拟化环境下可能漏数或重复计数 -
lscpu自动合并重复信息，不依赖文本解析，避开grep+uniq的边界问题（比如字段换行、空格不一致） - 注意：该值 = 物理CPU颗数 × 每颗核心数 × 超线程倍数（如开启 HT 就是 ×2）
查物理核心总数：看 lscpu 的三个关键字段
物理核心总数 ≠ 逻辑CPU个数。真正决定并行计算能力的是物理核心数，它由 Socket(s)（插槽数）、Core(s) per socket（每颗CPU核心数）共同决定。
- 执行
lscpu后找这三行：Socket(s): 2、Core(s) per socket: 8、Thread(s) per core: 2→ 物理核心总数 =2 × 8 = 16，逻辑CPU =2 × 8 × 2 = 32 - 别只看
cpu cores字段：/proc/cpuinfo 里这个值是“每颗物理CPU的核心数”，不是全局总数；单独用它会少乘Socket(s) - 容器中
lscpu仍显示宿主机全量信息；如需限制后的真实可用数，得结合 cgroups 或taskset -c验证
查当前生效的核心范围：nproc 和 getconf _NPROCESSORS_ONLN
当系统启用了 CPU 热拔插、或通过 isolcpus 内核参数隔离了部分核心，lscpu 显示的仍是硬件能力，而运行时真正可用的逻辑CPU数可能更少。
-
nproc直接返回当前 shell 进程可使用的逻辑CPU数（受cpuset、taskset、cgroup v1/v2 限制） -
getconf _NPROCESSORS_ONLN是 POSIX 标准接口，语义等价，但更底层、兼容性更好（尤其在 Alpine 等精简镜像中） - 常见陷阱：脚本里硬编码
$(nproc)做并行任务分发，结果在 Kubernetes Pod 里跑出远超预期的并发度——因为默认没限制，nproc返回的是节点总逻辑数
别信 /proc/cpuinfo 里单条 cpu cores 行
很多人用 cat /proc/cpuinfo | grep "cpu cores" | uniq，以为这就代表总核心数。其实它只反映第一颗 CPU 的核心数，对多路服务器完全不准。
- 示例：双路 16 核 CPU，
/proc/cpuinfo里会出现 32 行cpu cores : 16（每颗各 16 行），uniq后只剩一行，误导你认为总共只有 16 核 - 正确做法是先按
physical id分组再统计：grep -E "physical id|cpu cores" /proc/cpuinfo | paste -d' ' - - | sort -u | wc -l，但太绕，不如直接用lscpu - 在 WSL2 或某些云实例上，
/proc/cpuinfo可能伪造字段，physical id全为 0，导致误判为单路——lscpu内部做了校验，更稳
真正要确认程序能用几个核，不能只看硬件规格；得看 nproc，再对照 cgroup limits 或启动参数。很多性能问题，根源是以为“看到的=能用的”。
