std::thread::hardware_concurrency() 返回的是逻辑核心数，不是物理核心数
这个函数返回的是操作系统报告的「可用硬件线程数」，也就是启用了超线程（Hyper-Threading / SMT）后的逻辑 CPU 数量。比如一台 8 核 16 线程的 Intel CPU，在 Windows/Linux 上通常返回 16；若 BIOS 中禁用超线程，则大概率返回 8。它不区分物理核心和逻辑线程，也不做任何运行时探测——只是读取系统接口（如 Linux 的 /proc/sys/kernel/ngroups_max 或 sysconf(_SC_NPROCESSORS_ONLN)，Windows 的 GetSystemInfo()）。
为什么它有时返回 0？
标准只要求该函数「尽力而为」，返回 0 表示「无法确定」。常见于：
- 嵌入式或无操作系统的环境（如 freestanding 实现）
- 某些容器或虚拟机未正确暴露 CPU 信息（例如部分 Docker 默认限制）
- 旧版 libc 或 libstdc++/libc++ 实现缺陷（极少见，但曾出现在早期 MinGW-w64）
遇到 0 时不能当作「单核」处理，应 fallback 到保守值（如 1 或根据部署环境预估）。
用它决定线程池大小是否安全？
多数场景下可以作为起点，但需结合负载类型调整：
立即学习“C++免费学习笔记（深入）”；
- CPU 密集型任务：设为
std::thread::hardware_concurrency()常常过载，尤其在超线程开启时——两个逻辑线程共享一个物理核心的 ALU/FPU，实际吞吐未必翻倍 - I/O 密集型任务：可适度放大（如 ×1.5～2），因为线程常阻塞在系统调用上
- 混合型或 NUMA 架构：需额外考虑内存带宽与跨 socket 访问延迟，单纯依赖该值会误导调度
更稳妥的做法是：
int thread_count = std::thread::hardware_concurrency(); if (thread_count == 0) thread_count = 1; // 对 CPU 密集型，优先用物理核心数（需自行探测） // 例如 Linux 下读取 /sys/devices/system/cpu/cpu*/topology/core_id 去重计数
如何获取物理核心数（Linux / Windows）？
没有跨平台标准 API，但有可靠补充手段：
- Linux：
lscpu | grep "Core(s) per socket"+"Socket(s)"相乘；或解析/sys/devices/system/cpu/online和/sys/devices/system/cpu/cpu*/topology/core_id - Windows：用
GetLogicalProcessorInformation()遍历RelationProcessorCore类型结构体，统计唯一GroupMask中的Mask位数 -
macOS：
sysctl -n hw.physicalcpu
注意：这些方法需要额外权限或头文件（如 Windows 的 Windows.h），且不能在所有受限环境中运行（如某些容器、沙箱）。所以，除非你明确需要物理核心数来避免超线程争抢，否则别轻易绕过 std::thread::hardware_concurrency() —— 它至少代表了系统「愿意给你多少并发执行单元」。
真正容易被忽略的是：即使你知道物理核心数，现代 CPU 的微架构特性（如 Intel 的 Turbo Boost、AMD 的 Precision Boost）会让单核频率动态变化，此时固定线程数反而不如配合 work-stealing 的自适应调度器稳定。别太迷恋那个数字本身。
