std::thread::hardware_concurrency() 返回0是标准允许的“尽力而为”行为，需fallback：Linux读/sys/devices/system/cpu/online或解析/proc/cpuinfo，Windows用GetActiveProcessorCount()，其他平台用sysconf(_SC_NPROCESSORS_ONLN)，并设上限防误判。
std::thread::hardware_concurrency() 返回0怎么办
多数情况下，std::thread::hardware_concurrency() 是最直接的跨平台方式，但它不保证返回有效值——在某些编译器（如旧版 MinGW）、静态链接场景或容器环境中可能返回 0。这不是 bug，而是标准允许的“尽力而为”行为。
- 先检查是否真为
0：if (n == 0) { /* fallback needed */ } - 不要把它当绝对权威，尤其在 CI/CD 或 Docker 容器里，OS 层面可能限制了可见 CPU 数（比如
docker run --cpus=2），此时hardware_concurrency()仍可能返回宿主机总数 - Linux 下可读
/sys/devices/system/cpu/online；Windows 下用GetActiveProcessorCount()（Win10 1607+）更准确
Linux 下读取 /proc/cpuinfo 的坑
/proc/cpuinfo 看似简单，但容易数错：它按逻辑核（包括超线程）列条目，processor 字段从 0 开始编号，最后一行的编号 + 1 才是总数。别用 grep -c 'processor' 直接计数——如果文件末尾有空行或注释，会多算。
- 推荐用：
grep '^processor' /proc/cpuinfo | tail -n1 | awk '{print $3 + 1}' - 更健壮的做法是逐行解析，跳过空行和非
processor行，只取最后一个processor后的数字 - 注意：容器中挂载的
/proc可能被 cgroups 限制，cpu.rt_runtime_us或cpuset.cpus文件更能反映实际配额
Windows 上 GetLogicalProcessorInformation 太重？用 GetActiveProcessorCount
GetLogicalProcessorInformation() 能区分物理核/逻辑核，但 API 复杂、需多次调用、还要处理 ERROR_INSUFFICIENT_BUFFER。对只要总数的场景，GetActiveProcessorCount(ALL_PROCESSOR_GROUPS) 更轻量，且尊重当前进程的处理器组和亲和性设置。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须链接
kernel32.lib，头文件含<windows.h></windows.h> - 返回值是当前进程可见的活跃逻辑核数，比
GetSystemInfo().dwNumberOfProcessors更准（后者忽略组限制） - 若程序未启用“处理器组支持”，
ALL_PROCESSOR_GROUPS和0效果一致；启用后才真正生效
跨平台封装建议：优先系统 API，fallback 到 std::thread
别写“一次封装打遍天下”的宏，不同平台差异真实存在。务实做法是分层判断：
立即学习“C++免费学习笔记（深入）”；
- Linux：尝试读
/sys/devices/system/cpu/online（返回类似0-3或0,2,4,6），解析后得实际可用核数；失败再 fallback 到/proc/cpuinfo - Windows：调用
GetActiveProcessorCount()；XP 或极老环境才用GetSystemInfo() - 其他平台（macOS、FreeBSD）：用
sysconf(_SC_NPROCESSORS_ONLN)，它比hardware_concurrency()更可靠 - 所有 fallback 都应设上限（比如不超过 128），防止误判导致线程池爆炸
真正麻烦的不是获取数字，而是这个数字到底代表“物理核”“逻辑核”还是“当前配额”——得看你要调度什么任务，别默认它等于能开多少个 std::thread。
