std::thread::hardware_concurrency() 经常返回 0 是因标准仅要求“尽力而为”，嵌入式或旧 libc 实现可能直接返回 0；应 fallback 到平台接口：Linux 用 sysconf(_SC_NPROCESSORS_ONLN)，Windows 用 GetSystemInfo().dwNumberOfProcessors。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
它不保证返回有效值——标准只要求“尽力而为”，在某些平台（尤其是嵌入式或旧版 libc 实现）会直接返回 0。这不是 bug，而是标准留的余地。遇到 0 时不能当作“无并发能力”，必须 fallback 到系统级查询。
Linux 下用 sysconf(_SC_NPROCESSORS_ONLN) 最可靠
这是 POSIX 标准接口，返回当前在线的逻辑 CPU 数（即可用硬件线程数），比读 /proc/cpuinfo 更轻量、更权威。注意不是 _SC_NPROCESSORS_CONF（后者是配置数，可能包含离线 CPU）。
实操建议：
- 始终检查返回值是否为
-1（出错），而非只判断正负 - 在容器中运行时，该值反映的是 cgroup 限制后的可用核数，符合预期
- 不需要 root 权限，普通用户可安全调用
#include <unistd.h>
int hw_threads = sysconf(_SC_NPROCESSORS_ONLN);
if (hw_threads == -1) { /* 处理错误 */ }
Windows 上用 GetSystemInfo().dwNumberOfProcessors
这个字段返回的是当前系统可见的逻辑处理器数量，已自动考虑亲和性掩码和 Hyper-V 虚拟化限制，比手动解析 GetLogicalProcessorInformation 简单且足够准确。
立即学习“C++免费学习笔记（深入）”；
常见误区：
- 别用
GetActiveProcessorCount（Windows 10 1607+），它受进程亲和性影响，返回的是当前进程能用的数，不是系统最大值 - 不要依赖
NUMBER_OF_PROCESSORS环境变量——它可能被用户篡改或未设置 -
GetSystemInfo是同步调用，无额外开销
#include <windows.h> SYSTEM_INFO si; GetSystemInfo(&si); int hw_threads = si.dwNumberOfProcessors;
跨平台封装要注意的边界情况
不同平台对“硬件线程”的定义一致（逻辑核心数），但行为差异藏在细节里：
- macOS 没有直接等价的 sysconf 常量，得用
sysctlbyname("hw.logicalcpu")，且需处理errno == ENOENT的情况 - 如果程序运行在 CPU 限制容器（如 Docker --cpus=2）中，Linux 的
_SC_NPROCESSORS_ONLN和 Windows 的dwNumberOfProcessors都会如实反映限制值，这是正确行为，不是缺陷 - 某些 ARM 平台（如树莓派）启用了 CPU hotplug，
_SC_NPROCESSORS_ONLN会动态变化，应缓存但需支持重查
真正容易被忽略的点：获取结果后别直接当成线程池大小硬编码——它只是上限，实际并发数还需结合 I/O 密集度、内存带宽和任务粒度动态调整。
