sysconf(_sc_threads) 返回系统理论最大线程数，非当前进程可用数，linux常返回2147483647，macos可能返回-1，windows无等效api；实际受限于内存、栈空间、句柄数及调度开销。
Linux/macOS 下用 sysconf(_SC_THREADS) 获取理论最大线程数
这个值反映系统级线程资源上限，不是当前进程能创建的线程数，也不是运行时实际可用数。它由内核配置（如 /proc/sys/kernel/threads-max）和 RLIMIT_SIGPENDING 等限制共同影响。
实操建议：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
sysconf(_SC_THREADS)返回long，若为 -1 表示不支持或出错，需检查errno - 该值通常远高于实际可用数（比如 Linux 常返回 2147483647），不能直接用于线程池大小决策
- macOS 上该调用可能返回 -1，应降级尝试读取
sysctl kern.num_threads
Windows 下没有等效的全局 API，得靠间接估算
Windows 不提供类似 _SC_THREADS 的标准接口。GetProcessAffinityMask 或 GetSystemInfo 只给 CPU 核心数，和线程数无关。真正制约的是堆栈空间、句柄数和内存。
实操建议：
- 默认每个线程预留 1MB 栈空间（x64 下可配），32GB 内存最多支撑约 32000 个线程——但这只是粗略上界
- 用
GetLastError()捕获ERROR_NOT_ENOUGH_MEMORY或ERROR_COMMITMENT_LIMIT才是真实失败信号 - 更实用的做法：在目标机器上用
CreateThread循环创建并计数，直到失败，再减去已占用句柄数
别把 std::thread::hardware_concurrency() 当成最大线程数
这个函数返回的是逻辑处理器数量（即 CPU 并发能力），不是系统支持的最大线程总数。它常用于设置线程池初始大小，但和“最多能开多少线程”完全不是一回事。
常见错误现象：
- 误以为
std::thread::hardware_concurrency() == 8就代表最多只能开 8 个线程——其实可以轻松开几百上千个（只要内存够） - 在容器环境里该值可能返回 0（检测失败），此时硬编码 fallback 值比盲目信任更稳妥
- 该函数不抛异常，也不保证实时性；虚拟机热插拔 CPU 后它不会自动更新
真正决定“能开多少线程”的其实是资源配额和调度开销
系统允许你创建大量线程，但性能拐点往往出现在几百个活跃线程时。上下文切换、TLB 压力、锁竞争会让吞吐暴跌，这时候“最大数”已经失去意义。
关键判断点：
- Linux 上看
/proc/[pid]/status的Threads:行，比查全局上限更有参考价值 - 用
ulimit -u查当前用户最大进程/线程数（注意：POSIX 线程算作轻量级进程） - 高并发服务中，优先考虑无锁队列 + 协程模型，而不是堆线程数——多数场景下 50 个精心设计的工作线程比 500 个裸
std::thread更可靠
/proc/sys/kernel/threads-max 和 ulimit -u 的交集才是硬门槛，但真正卡住你的，往往是第 300 个线程开始的调度抖动，而不是第 10000 个线程的创建失败。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
