17370845950

std::thread::hardware_concurrency() 返回 0 时应启用多层 fallback：优先读取 Linux 的 /sys/devices/system/cpu/online、Windows 的 GetSystemInfo() 或 macOS 的 sysctlbyname("hw.logicalcpu")，再退至保守值。

std::thread::hardware_concurrency() 返回 0 怎么办

这个函数不保证返回有效值，标准只要求“尽力而为”，某些环境下（比如容器、Wine、旧内核或编译器未正确识别硬件）会直接返回 0。不能把它当作绝对可靠的 CPU 核心数来源。

• 检查是否在真实 Linux/macOS/Windows 主机上运行，而非 Docker 默认限制的 cgroups v1 环境（docker run --cpus=2 时，hardware_concurrency() 仍可能返回宿主机总数或 0）
• 确认编译器和标准库版本：GCC 7+、Clang 5+、MSVC 2015u3+ 对该函数的支持更稳定
• 若返回 0，应有 fallback 逻辑，不要直接除零或 crash

Linux 下读取 /sys/devices/system/cpu/online 最可靠

这是内核暴露的真实在线逻辑 CPU 列表（考虑热插拔和 cpuset 限制），比 sysconf(_SC_NPROCESSORS_ONLN) 更贴近运行时实际可用数。

• 路径 /sys/devi

  

  ces/system/cpu/online 内容形如 0-3,6,8-9，需解析范围并计数
• 注意权限：普通用户可读，无需 root
• 比 get_nprocs_conf() 更准——后者返回配置最大值，可能包含被禁用的 core
• 示例片段（不依赖 Boost）：

  std::ifstream f("/sys/devices/system/cpu/online");
  std::string range; getline(f, range);
  int count = parse_cpu_range(range); // 需自行实现逗号+短横解析

Windows 用 GetSystemInfo() 比 hardware_concurrency() 更稳

GetSystemInfo() 是 Win32 API 中最轻量、最广泛支持的方式，返回的是当前会话可见的逻辑处理器数量（受进程 affinity mask 和组策略限制）。

• 返回值存于 SYSTEM_INFO.dwNumberOfProcessors，类型为 DWORD
• 它比 GetLogicalProcessorInformation() 简单，且不涉及内存分配或结构体枚举
• 注意：若进程被绑定了 CPU 亲和性（例如 SetProcessAffinityMask()），该值仍是全局总数；要获取当前进程实际可用数，得调用 GetProcessAffinityMask() 并统计 bit 数

跨平台封装建议：别只靠 std::thread::hardware_concurrency()

真正健壮的代码需要分层 fallback：先试标准函数，失败则走系统 API，再不行才退到保守估计（如返回 1 或 2）。

• 避免在初始化线程池前仅依赖 std::thread::hardware_concurrency() —— 它在 MinGW、某些嵌入式 libc++ 或静态链接场景下极易失效
• macOS 推荐用 sysctlbyname("hw.logicalcpu", ...)，比 sysconf(_SC_NPROC_ONLN) 更准（后者在 Rosetta 2 下可能返回 x86_64 逻辑核数而非 Apple Silicon 实际值）
• 如果程序对并发敏感（如实时音频、高频 tick），还要考虑超线程是否开启、以及 workload 是 CPU-bound 还是 memory-bound —— 物理核心数有时比逻辑核心数更关键

实际部署时，/proc/cpuinfo 的 processor 行数、Windows 的 GetActiveProcessorCount()（Win10 1607+）、macOS 的 host_processor_info() 都有各自适用边界，但多数服务端应用只需前三个 fallback 就已足够。别忘了加日志输出真实探测结果，方便排查调度异常。