std::thread::hardware_concurrency() 经常返回 0 是因标准仅要求“尽力而为”，windows 旧版 msvc 或容器环境可能探测失败；应优先解析 /sys/devices/system/cpu/online（linux）、调用 getlogicalprocessorinformationex（windows），最后 fallback 并处理 0 值。
std::thread::hardware_concurrency() 返回值为什么经常是 0？
这个函数本意是返回系统能并行执行的线程数（通常是逻辑核心数），但标准只要求“尽力而为”，不保证非零。Linux/macOS 一般能正确返回，Windows 在旧版 MSVC 或某些容器环境下可能返回 0 —— 这不是 bug，而是实现未探测到可用核心数。
- 遇到
std::thread::hardware_concurrency()返回 0，不能直接当作 1 使用，得 fallback 到更可靠的探测方式 - 它不考虑超线程是否启用、也不反映当前 cgroup 限制（比如 Docker 容器里被
--cpus=2限制后，仍可能返回宿主机总核数） - 该值适合做初始线程池大小参考，但不适合用于资源敏感型调度（如实时任务）
Linux 下读取 /sys/devices/system/cpu/online 更准确
这是最轻量、最贴近真实可用 CPU 的方式，尤其在容器或被 cgroups 限制的环境中依然有效。它返回的是当前进程可见的在线逻辑 CPU 范围（例如 0-3 或 0,2,4,6）。
- 用
std::ifstream读取/sys/devices/system/cpu/online，然后解析区间或列表 - 注意：该文件内容格式可能是
0-7（连续）或0,2,4-6（稀疏），需用简单状态机解析，别直接std::stoi - 如果打开失败（权限不足或路径不存在），说明不在 Linux 环境，应退回到
std::thread::hardware_concurrency()
// 示例片段：解析 online CPUs
std::string line;
std::ifstream f("/sys/devices/system/cpu/online");
if (f && std::getline(f, line)) {
int count = parse_cpu_range(line); // 自定义解析函数
return count > 0 ? count : fallback;
}
Windows 上用 GetLogicalProcessorInformationEx 获取实际可用逻辑核心
GetLogicalProcessorInformationEx 比 GetSystemInfo 更可靠，尤其在启用了组（Processor Group）的 64 核以上机器上，后者会漏掉跨组核心。
- 必须传入
RelationProcessorCore类型，才能拿到每个物理核对应的逻辑处理器集合 - 遍历返回的
PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX，对每个 core 统计GroupMask中的 bit 数（BitScanForward64配合掩码） - 记得用
LocalFree释放返回内存，否则泄漏；且该 API 在 Windows 7+ 才支持
跨平台封装建议：优先 sysfs，其次 Windows API，最后 fallback 到 hardware_concurrency
不要写“一次封装跑全平台”的宏大全，不同系统差异太大。实际项目中推荐分层判断：
- 先检查是否 Linux（
__linux__），尝试读/sys/devices/system/cpu/online - 再检查是否 Windows（
_WIN32），调用GetLogicalProcessorInformationEx - 最后 fallback 到
std::thread::hardware_concurrency()，若为 0，则保守取std::max(1u, std::thread::hardware_concurrency()) - 避免在启动时缓存该值——cgroup 或 CPU 热插拔可能动态改变可用核心数
真正麻烦的不是获取数字，而是这个数字代表什么：它只是并发能力上限，不代表此刻就能跑满。IO 密集型任务多开线程反而降低吞吐，CPU 密集型又受限于 L3 缓存争用。数值本身容易拿，理解它在你 workload 里的意义才最难。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
