c++oding="utf-8" ?>
当std::thread::hardware_concurrency()返回0时，应优先调用sysconf(_sc_nprocessors_onln)（linux）或getsysteminfo()（windows）获取逻辑核数；在容器中须解析/cpuset.effective_cpus以获实际配额，最终取各层约束最小值作为线程池上限。
std::thread::hardware_concurrency() 返回值为 0 怎么办
这个函数本意是返回系统能支持的**逻辑处理器数量**（即超线程后的 CPU 核心数），但它不保证一定非零——标准允许实现返回 0，尤其在嵌入式、精简版 libc++ 或某些容器环境中。遇到 std::thread::hardware_concurrency() 返回 0，不能直接当作“无并发能力”处理，而是要 fallback 到更底层的系统接口。
Linux 下用 sysconf(_SC_NPROCESSORS_ONLN) 获取在线逻辑核数
这是最可靠、POSIX 标准的方式，返回当前在线（online）且可用的逻辑 CPU 数，和 lscpu | grep "CPU(s):" -m1 显示的 “CPU(s)” 一致。它反映的是内核当前启用的逻辑处理器数量，已考虑热插拔、cpuset cgroup 限制等运行时状态。
实操建议：
- 包含头文件：
#include <unistd.h></unistd.h> - 调用
sysconf(_SC_NPROCESSORS_ONLN)；若返回 -1 表示出错（比如系统不支持该查询），此时应谨慎 fallback（如设为 1） - 注意：它不等于物理核心数，也不反映超线程是否开启——只告诉你“此刻有多少个逻辑 CPU 可被调度”
- 在 Docker 容器中，如果启用了
--cpus=2或设置了cpuset.cpus，sysconf仍返回宿主机总核数；需配合/sys/fs/cgroup/cpuset/cpuset.effective_cpus解析（见下一点）
容器环境必须检查 cpuset.effective_cpus
在 Kubernetes 或 Docker 中，sysconf(_SC_NPROCESSORS_ONLN) 和 /proc/cpuinfo 都会暴露宿主机信息，无法反映实际配额。真正限制并发线程上限的是 cgroup v1 的 /sys/fs/cgroup/cpuset/cpuset.effective_cpus（v2 对应 /sys/fs/cgroup/cpuset.cpus.effective）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 读取该文件内容，例如
"0-3"、"0,2,4"或"0" - 需自行解析范围表达式：用
strtok拆逗号，再按短横线切分起止，累加计数 - 若文件不存在或读取失败（如非 cgroup 环境），回退到
sysconf - 不要依赖
/proc/cgroups判断是否在容器中——有些环境禁用了该接口，而cpuset.effective_cpus即使值为"0-0"也明确给出了硬上限
Windows 上用 GetSystemInfo() 还是 GetLogicalProcessorInformationEx()？
GetSystemInfo() 返回的 dwNumberOfProcessors 是最简方案，但它只给总数，不区分逻辑/物理，也不感知组（Group）边界。Windows 10 1803+ 推荐用 GetLogicalProcessorInformationEx() + RelationProcessorCore，但代价是代码变复杂、需要多次调用获取 buffer 大小。
实操建议：
- 对绝大多数应用，
GetSystemInfo()足够：它返回的是当前会话可见的逻辑处理器数，已受SetThreadGroupAffinity或启动参数（如start /node）影响 - 若需精确识别物理核心数（比如做 cache-aware 线程绑定），才值得上
GetLogicalProcessorInformationEx() - 注意：Windows 容器（LCOW）中，该值仍反映宿主机逻辑核数；目前无等效于 Linux
cpuset.effective_cpus的稳定用户态接口，需依赖容器运行时注入环境变量（如HOST_PROC_CPUINFO）或通过 WSL2 内部路径绕行
跨平台封装时，最容易被忽略的是 cgroup 边界——很多 C++ 库把 hardware_concurrency() 当作“安全线程池大小”直接用，却没意识到在 --cpus=1.5 的容器里，它可能让线程池创建 64 个空转线程，拖垮调度器。真正的“最大并发线程数”永远是运行时约束的最小值：cgroup 配额 ≤ 逻辑核数 ≤ 硬件线程数。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
