std::thread::hardware_concurrency() 返回的是逻辑核心数，不是物理核心数

这个函数返回的是操作系统报告的「可用硬件线程数」，也就是启用了超线程（Hyper-Threading / SMT）后的逻辑 CPU 数量。比如一台 8 核 16 线程的 Intel CPU，在 Windows/Linux 上通常返回 16；若 BIOS 中禁用超线程，则大概率返回 8。它不区分物理核心和逻辑线程，也不做任何运行时探测——只是读取系统接口（如 Linux 的 /proc/sys/kernel/ngroups_max 或 sysconf(_SC_NPROCESSORS_ONLN)，Windows 的 GetSystemInfo()）。

为什么它有时返回 0？

标准只要求该函数「尽力而为」，返回 0 表示「无法确定」。常见于：

• 嵌入式或无操作系统的环境（如 freestanding 实现）
• 某些容器或虚拟机未正确暴露 CPU 信息（例如部分 Docker 默认限制）
• 旧版 libc 或 libstdc++/libc++ 实现缺陷（极少见，但曾出现在早期 MinGW-w64）

遇到 0 时不能当作「单核」处理，应 fallback 到保守值（如 1 或根据部署环境预估）。

用它决定线程池大小是否安全？

多数场景下可以作为起点，但需结合负载类型调整：

立即学习“C++免费学习笔记（深入）”；

• CPU 密集型任务：设为 std::thread::hardware_concurrency() 常常过载，尤其在超线程开启时——两个逻辑线程共享一个物理核心的 ALU/FPU，实际吞吐未必翻倍
• I/O 密集型任务：可适度放大（如 ×1.5～2），因为线程常阻塞在系统调用上
• 混合型或 NUMA 架构：需额外考虑内存带宽与跨 socket 访问延迟，单纯依赖该值会误导调度

更稳妥的做法是：

int thread_count = std::thread::hardware_concurrency();
if (thread_count == 0) thread_count = 1;
// 对 CPU 密集型，优先用物理核心数（需自行探测）
// 例如 Linux 下读取 /sys/devices/system/cpu/cpu*/topology/core_id 去重计数

如何获取物理核心数（Linux / Windows）？

没有跨平台标准 API，但有可靠补充手段：

• Linux：lscpu | grep "Core(s) per socket" + "Socket(s)" 相乘；或解析 /sys/devices/system/cpu/online 和 /sys/devices/system/cpu/cpu*/topology/core_id
• Windows：用 GetLogicalProcessorInformation() 遍历 RelationProcessorCore 类型结构体，统计唯一 GroupMask 中的 Mask 位数
• macOS：sysctl -n hw.physicalcpu

注意：这些方法需要额外权限或头文件（如 Windows 的 Windows.h），且不能在所有受限环境中运行（如某些容器、沙箱）。所以，除非你明确需要物理核心数来避免超线程争抢，否则别轻易绕过 std::thread::hardware_concurrency() —— 它至少代表了系统「愿意给你多少并发执行单元」。

真正容易被忽略的是：即使你知道物理核心数，现代 CPU 的微架构特性（如 Intel 的 Turbo Boost、AMD 的 Precision Boost）会让单核频率动态变化，此时固定线程数反而不如配合 work-stealing 的自适应调度器稳定。别太迷恋那个数字本身。