Linux中线程数受RLIMIT_NPROC限制，即每进程最大线程数（含主线程），可用getrlimit(RLIMIT_NPROC, &rl)获取软硬限制；Windows无等价全局限制，线程创建失败主因是内存或内核对象耗尽。
Linux 下用 getrlimit 查看线程数软硬限制
线程数量本质受系统资源限制，最直接的是每个进程能创建的「最大文件描述符数」和「最大线程数」，而后者在 Linux 上通常由 RLIMIT_NPROC 控制——它限制的是进程可拥有的**总线程数（含主线程）**，不是“当前已用数”。
实操时调用 getrlimit 获取该值即可：
#include <sys/resource.h>
#include <iostream>
int main() {
struct rlimit rl;
if (getrlimit(RLIMIT_NPROC, &rl) == 0) {
std::cout << "soft limit: " << rl.rlim_cur << "\n";
std::cout << "hard limit: " << rl.rlim_max << "\n";
}
}
-
rl.rlim_cur是当前生效的软限制，std::thread构造失败常因触达此值 -
rl.rlim_max是上限，普通用户无法突破，需sudo prlimit --nproc=xxx $$临时调整 - 注意：该限制是**每进程**的，不是全系统；不同用户、不同 shell 启动的进程可能有不同默认值
Windows 下没有等价的全局线程数限制 API
Windows 不提供类似 RLIMIT_NPROC 的硬性线程计数限制。线程创建失败（std::thread 构造抛 std::system_error）通常源于内存不足或内核对象耗尽，而非预设配额。
你可以间接估算：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 每个线程默认栈空间约 1MB（可通过
CreateThread的dwStackSize调整），可用虚拟内存总量决定理论上限 - 用
GetSystemInfo()查dwNumberOfProcessors只反映 CPU 核心数，和线程数无关 - 实际中更应关注
std::thread构造是否抛异常，而不是预先“查支持多少个”
std::thread::hardware_concurrency() 返回的是逻辑核心数，不是线程容量
这个函数常被误读为“最多能开几个线程”，但它只返回 std::thread::hardware_concurrency() —— 即 CPU 支持的并发执行单元数（如 8 表示 8 个逻辑核心），和操作系统能承载的线程总数完全无关。
- 它可能返回 0（检测失败），此时不应作为线程池大小依据
- 即使返回 8，你仍可能成功创建 1000 个空闲线程（只要内存够、
RLIMIT_NPROC允许） - 真正影响性能的是线程数远超
hardware_concurrency()后的上下文切换开销，不是创建失败
运行时探测比静态查询更可靠
与其纠结“系统支持多少”，不如在关键路径上做轻量级探测：
- 启动前尝试构造一个
std::thread并立即join()，捕获std::system_error判断是否基础环境异常 - 线程池扩容时，用
try_emplace+ 异常处理逐步增加，比硬编码上限更健壮 - Linux 下若频繁遇到
Resource temporarily unavailable（对应errno == EAGAIN），优先检查ulimit -u和/proc/sys/kernel/threads-max，后者是全系统级硬上限
真正卡住你的往往不是“系统最大支持数”，而是栈内存碎片、glibc 的 NPTL 实现细节，或者忘记 join()/detach() 导致的资源泄漏——这些比查一个数字重要得多。
