std::thread::hardware_concurrency() 返回操作系统报告的逻辑核心数（含超线程），非物理核心数，且不响应 cgroup 限制或 CPU 热插拔；可能返回 0，需检查并兜底。
thread::hardware_concurrency 返回的是逻辑核心数，不是物理核心数
std::thread::hardware_concurrency() 返回的是操作系统报告的**可用硬件线程数**，即逻辑核心数（含超线程）。比如在 8 核 16 线程的 CPU 上，它通常返回 16，而非 8。这个值是静态估算，不保证实时准确——它可能返回 0（当系统无法确定时），也**不会动态响应 CPU 热插拔或 cgroup 限制**（如容器中被限制为 2 核，它仍可能返回宿主机的 32）。
常见错误现象：std::thread::hardware_concurrency() == 0，尤其在嵌入式环境、旧版 MinGW 或某些容器运行时中；这时不能直接用作线程池大小，需 fallback。
- 使用前必须检查返回值是否为
0，否则可能导致无限循环或未定义行为 - 若需物理核心数，
thread::hardware_concurrency()无法提供，得查/proc/cpuinfo（Linux）、sysctl hw.physicalcpu（macOS）或GetLogicalProcessorInformation（Windows） - 在 Docker 容器中，该函数看不到
--cpus=2这类限制，它只看宿主机 CPU topology
如何安全地用 hardware_concurrency 初始化线程池
直接用 std::thread::hardware_concurrency() 做线程数上限容易翻车。推荐加一层兜底和裁剪：
unsigned int thread_count = std::thread::hardware_concurrency();
if (thread_count == 0) {
thread_count = 2; // 最小合理值，避免退化为单线程
}
// 可选：对高核心数机器做保守限制，防止过度并发拖慢 I/O 密集型任务
if (thread_count > 16) {
thread_count = std::min(thread_count, 12U);
}
注意：hardware_concurrency() 是静态函数，无需实例；它不抛异常，但返回值无强制保证——C++ 标准只要求“尽力而为”。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要在循环里反复调用它，结果不会变，纯属浪费
- 多线程程序中，首次调用建议放在主线程初始化阶段，而非某个 worker 线程内
- 若任务是 I/O 密集型（如大量网络请求），线程数设为
hardware_concurrency() * 2可能更合适，但要配合连接池/异步 I/O，而非盲目增线程
为什么 Linux 下 /proc/cpuinfo 比 hardware_concurrency 更可靠
当需要精确区分物理核与逻辑核，或受容器 CPU 配额约束时，/proc/cpuinfo 是更底层、更可控的数据源。例如：
grep -P '^processor' /proc/cpuinfo | wc -l # 逻辑核心数（等价于 hardware_concurrency） grep 'core id' /proc/cpuinfo | sort -u | wc -l # 物理核心数（需配合 'physical id' 判断 socket）
但注意：/proc/cpuinfo 是 Linux 特有，不可跨平台；且读取它涉及系统调用和字符串解析，比调用 hardware_concurrency() 慢一个数量级。
- 在构建跨平台工具链时，优先用
hardware_concurrency()+0fallback，再按需补充平台特定逻辑 - Docker 中想获取实际配额，应读
/sys/fs/cgroup/cpu.max（cgroups v2）或/sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），而不是依赖/proc/cpuinfo - macOS 和 Windows 没有
/proc/cpuinfo，别硬写路径，会 crash
Windows 下 GetLogicalProcessorInformation 的替代方案
Windows 提供更细粒度的 API：GetLogicalProcessorInformation 可区分关系类型（RelationProcessorCore vs RelationLogicalProcessor），从而分离物理核与超线程。但使用门槛高：
- 需手动分配缓冲区并循环调用，直到返回
ERROR_INSUFFICIENT_BUFFER - 返回结构体数组，需遍历计数
Relationship == RelationProcessorCore的条目 - C++ 标准库不封装它，意味着你得写
#ifdef _WIN32分支，维护成本上升
除非你在开发性能敏感的系统工具（如数据库线程调度器），否则没必要绕过 hardware_concurrency()。它的设计初衷就是“够用就好”——多数应用真正需要的只是“别开太少线程”，而不是“精确到第 3 个物理核的第 2 个逻辑线程”。
最常被忽略的一点：即使你知道了物理核心数，也不等于就应该按此创建等量线程。内存带宽、L3 缓存争用、NUMA 节点分布，这些都比单纯数核更重要。别让 hardware_concurrency() 给你一种“已经最优”的错觉。
