std::thread::hardware_concurrency() 不可靠，仅返回启发式估计值，可能为0或逻辑线程数而非物理核心数；应优先用sysconf(_SC_NPROCESSORS_ONLN)（Linux/macOS）或GetActiveProcessorCount（Windows）获取真实逻辑CPU数。
std::thread::hardware_concurrency() 返回值到底靠不靠谱
std::thread::hardware_concurrency() 是 C++11 起提供的标准方式，用于查询系统“建议的”硬件线程数。但它返回的是 启发式估计值，不是精确核心数，更不是当前可用逻辑 CPU 数。
常见现象：在某些虚拟机、容器或启用了 CPU 限制的环境中，它可能返回 0；在超线程开启的 Intel CPU 上，它通常返回逻辑处理器总数（如 8 核 16 线程 → 返回 16），而非物理核心数。
- 它不区分物理核心和逻辑线程（Hyper-Threading / SMT）
- 它不感知 cgroups、CPU affinity 或 runtime 限制（比如
docker run --cpus=2） - 返回
0表示“无法确定”，此时不应当作 1 使用，而应 fallback 到其他探测方式
跨平台获取真实逻辑 CPU 数（推荐实操方案）
要拿到当前进程实际能调度到的逻辑 CPU 总数，优先用 OS 原生 API，再 fallback 到 std::thread::hardware_concurrency()。
Linux/macOS 下最可靠的是 sysconf(_SC_NPROCESSORS_ONLN)（POSIX），Windows 下用 GetActiveProcessorCount(ALL_PROCESSOR_GROUPS)（Win10 1607+）或 GetSystemInfo().dwNumberOfProcessors（兼容旧版）。
立即学习“C++免费学习笔记（深入）”；
#include#ifdef _WIN32 #include #else #include #endif int get_logical_cpu_count() { #ifdef _WIN32 // Win10 1607+ 推荐，考虑 processor groups if (GetProcAddress(GetModuleHandleA("kernel32.dll"), "GetActiveProcessorCount")) { return static_cast (GetActiveProcessorCount(ALL_PROCESSOR_GROUPS)); } // fallback SYSTEM_INFO si; GetSystemInfo(&si); return static_cast (si.dwNumberOfProcessors); #else long n = sysconf(_SC_NPROCESSORS_ONLN); return (n > 0) ? static_cast (n) : 1; #endif } int main() { std::cout << "Logical CPU count: " << get_logical_cpu_count() << "\n"; std::cout << "std::thread::hardware_concurrency(): " << std::thread::hardware_concurrency() << "\n"; }
如何区分物理核心数和逻辑线程数
仅靠标准 C++ 无法做到。必须调用平台特定接口：
- Linux：读取
/sys/devices/system/cpu/cpu*/topology/core_id并去重统计（需 root 权限非必需，但部分容器中不可读） - Linux（无 root）：解析
/proc/cpuinfo中cpu cores（每物理 CPU 的核心数） ×physical id数量，或用lscpu | grep 'Core(s) per socket'+'Socket(s)' - macOS：
sysctl -n hw.physicalcpu和hw.logicalcpu - Windows：WMI 查询
Win32_Processor的NumberOfCores和NumberOfLogicalProcessors
注意：std::thread::hardware_concurrency() 从不提供物理核心数 —— 它的设计目标就是“适合并行任务的线程上限”，即逻辑线程数。
实际写并发程序时该用哪个值
绝大多数场景下，你应该用 get_logical_cpu_count()（或 sysconf(_SC_NPROCESSORS_ONLN)）作为线程池大小上限，而不是 std::thread::hardware_concurrency()。
- 当程序受 CPU 密集型负载主导时，线程数 ≈ 逻辑 CPU 数是最优起点
- 若混合 I/O，可适当上浮（如 ×1.5），但需压测验证
- 在容器中运行时，
/sys/fs/cgroup/cpuset/cpuset.effective_cpus才是真实可用 CPU 列表，需解析该文件（Linux only） -
std::thread::hardware_concurrency()唯一稳妥用途是：作为 fallback，且必须检查是否为 0
物理核心数只在极少数场景有用，比如绑定线程到独占物理核避免超线程干扰（real-time audio、低延迟交易），这时你得自己解析拓扑，不能依赖标准库。
