std::thread::hardware_concurrency() 返回 0 表示无法确定硬件并发数，常见于嵌入式、macOS 或虚拟环境；应检查非零再使用，否则降级用 sysconf(_SC_NPROCESSORS_ONLN)。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
这个函数本意是返回系统能并行执行的硬件线程数（比如 8 核 16 线程 CPU 应该返回 16），但很多场景下它返回 0 —— 不是 bug，而是标准允许的“无法确定”情形。常见于嵌入式环境、部分 macOS 版本、或某些容器/虚拟机中未正确暴露拓扑信息时。
它不抛异常，也不 fallback，只是安静地返回 0。所以不能直接用，必须检查：
- 永远对
std::thread::hardware_concurrency()的返回值做非零判断 - 若为
0，需降级到平台特定 API 或 sysconf 查询 - 注意：该值反映的是当前进程可见的硬件并发能力，受 cgroups 限制（如 Docker 的
--cpus=2）时会变小
Linux 下用 sysconf(_SC_NPROCESSORS_ONLN) 更可靠
sysconf(_SC_NPROCESSORS_ONLN) 直接读取内核运行时在线 CPU 数，不受 C++ 标准库实现限制，且考虑了热插拔和 cpuset 限制。
示例用法：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
#include <unistd.h>
#include <iostream>
int main() {
long n = sysconf(_SC_NPROCESSORS_ONLN);
std::cout << (n > 0 ? n : 1) << "\n"; // 至少返回 1
}
-
_SC_NPROCESSORS_ONLN是运行中可用逻辑 CPU 数；_SC_NPROCESSORS_CONF是配置总数（含离线 CPU） - 返回
-1表示出错（通常 errno 为EINVAL），此时应 fallback 到1 - 该调用开销极低，无锁，可安全用于初始化阶段
Windows 上要用 GetSystemInfo() 而不是 GetLogicalProcessorInformation()
虽然 GetLogicalProcessorInformation() 能拿到详细拓扑（如 NUMA 节点、缓存层级），但获取“最大并发硬件线程数”只需最简路径：GetSystemInfo() 中的 dwNumberOfProcessors 字段。
-
GetSystemInfo()是轻量级同步调用，无额外分配，适合启动时一次查询 - 它等价于 Linux 的
_SC_NPROCESSORS_ONLN，反映当前会话可见的逻辑处理器数 - 不要用
GetActiveProcessorCount(NULL)—— 它受进程组/作业对象限制，可能比实际硬件小得多
跨平台封装时别忽略容器和云环境的现实约束
即使你拿到了 64，如果程序跑在 Kubernetes Pod 里且 resources.limits.cpu: "2"，那真实并发上限就是 2。硬编码或只信 hardware_concurrency() 会导致线程池过载、调度抖动。
- Docker/K8s 中优先读取
/sys/fs/cgroup/cpu.max（cgroup v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1）来判断配额 - macOS 上
sysctl hw.ncpu可用，但要注意 Rosetta 2 运行 x86_64 二进制时可能返回翻译层看到的逻辑数，而非原生 ARM 核心数 - 最终决定线程池大小时，建议取
min(探测值, 配额值, 用户配置上限)，而不是盲目信任硬件报告
真正麻烦的不是怎么查数字，而是查完之后——是否意识到这个数字只是起点，不是铁律。
