错误，sysconf(_sc_nprocessors_conf)返回的是系统配置的逻辑处理器总数（含超线程），非物理核心数；正确方法是遍历/sys/devices/system/cpu/cpu*/topology/core_id去重统计，并检查online状态。
Linux下用sysconf(_SC_NPROCESSORS_CONF)获取物理核心数？别信
这个函数返回的是系统配置的**逻辑处理器总数**（即包括超线程后的所有核），不是物理核心数。比如一台8核16线程的机器，它会返回16，完全没用。
真正能区分物理/逻辑核的，得靠/sys/devices/system/cpu/下的拓扑信息：
-
/sys/devices/system/cpu/cpu*/topology/core_id：每个逻辑CPU对应的物理核心ID（相同值表示同属一个物理核） -
/sys/devices/system/cpu/cpu*/topology/physical_package_id：对应物理CPU插槽ID（多路服务器有用）
所以正确做法是遍历所有在线的cpu*目录，收集core_id去重——结果就是物理核心数。注意要检查online文件，跳过离线CPU。
Windows上GetLogicalProcessorInformation()怎么筛出物理核
这个API返回的是SYSTEM_LOGICAL_PROCESSOR_INFORMATION数组，每项带Relationship字段。关键点在于：
- 只关注
RelationProcessorCore类型的条目 - 每个这样的条目里，
ProcessorMask是位图，1的个数 = 该物理核上的逻辑线程数（比如超线程开启时为2） - 物理核心数 =
RelationProcessorCore条目的总数，不是位图中1的总数
别误把ProcessorMask的popcount当核心数——那是逻辑线程总数。直接数RelationProcessorCore结构体个数就对了。
跨平台封装要注意std::thread::hardware_concurrency()的陷阱
这个C++11标准函数返回的是“推荐的并行度”，但语义模糊：
- Linux GCC实现通常调
sysconf(_SC_NPROCESSORS_ONLN)→ 返回逻辑核数 - Windows MSVC返回
GetSystemInfo().dwNumberOfProcessors→ 同样是逻辑核数 - 它从不保证是物理核，也不处理超线程关闭等场景
所以不能用于需要物理核心数的场景（如绑定到独占物理核、避免超线程争抢缓存）。真要跨平台，建议自己写条件编译分支，或用第三方库如hwloc（它内部就做了上述Linux/Win的拓扑解析）。
为什么/proc/cpuinfo里的cpu cores字段不可靠
这个字段在/proc/cpuinfo中看似直接，但它只反映当前CPU型号的**单颗物理CPU上的核心数**，不适用于多路系统。比如双路Xeon各16核，cpu cores仍显示16，而总物理核是32。
更糟的是，某些虚拟化环境（如KVM配了cores=4, threads=2, sockets=1）会让cpu cores显示4，但宿主机可能根本没暴露完整拓扑——此时必须依赖/sys/devices/system/cpu/的实时运行时信息，而不是静态字段。
物理核心数这事，没有“查一个文件或调一个函数就完事”的捷径。核心逻辑永远是：按拓扑关系聚合逻辑CPU，再数聚合组数。细节藏在路径、字段名和条件判断里，漏掉任一环节都可能翻车。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
