查当前进程线程数限制最准方式是执行cat /proc/[pid]/limits | grep "max processes"，该值即该进程能创建的线程总数（含主线程），超限则pthread_create返回eagain或std::thread抛resource_unavailable_try_again异常。
怎么查当前进程的线程数限制
直接看 /proc/[pid]/limits 最准，不用猜。比如你的进程 PID 是 1234，执行：
cat /proc/1234/limits | grep "Max processes"注意这一行显示的是
Max processes，它实际控制的是该进程能创建的线程总数（Linux 中线程即轻量级进程，共用同一 RLIMIT_NPROC 限制）。值为 1024 就意味着最多 1024 个线程（含主线程），超了 pthread_create 就会返回 EAGAIN，std::thread 构造时抛 std::system_error 并带 resource_unavailable_try_again。
为什么 ulimit -u 显示的值和实际不符
ulimit -u 查的是当前 shell 会话的 RLIMIT_NPROC，但它可能被子进程继承、覆盖或被 systemd 服务单元强制重设。常见坑点：
- 用
systemctl启动的服务，默认受DefaultLimitNPROC或服务文件里的LimitNPROC=约束，跟 shell 的ulimit无关 - 容器环境（如 Docker）中，
--ulimit nproc=...或 cgroup v2 的pids.max才是真实上限 - 某些发行版（如 RHEL/CentOS）启用了
user.max_processes这类 PAM 限制，ulimit看不见
pthread_create 返回 EAGAIN 一定是线程数超限吗
不全是。虽然 EAGAIN 是最常见原因，但也要排除其他可能性：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 虚拟内存耗尽：特别是 mmap 区域碎片化严重时，
pthread_create内部需要分配栈空间（默认 8MB），ENOMEM有时也伪装成EAGAIN - 用户级资源限制：比如该 UID 下所有进程总线程数已达系统级
/proc/sys/kernel/threads-max - SELinux 或 AppArmor 拒绝：日志里搜
avc: denied，不是纯数值限制问题
验证是否真因线程数：用 ps -T -p [pid] | wc -l 数当前线程数，再对比 /proc/[pid]/limits 里的软限制值。
临时调高限制但程序仍失败怎么办
改了 ulimit -u 或 systemd 配置后还是报错，说明限制没真正生效：
- 确认改的是**目标进程启动前**的上下文：改完
ulimit后必须新开 shell 再启动程序；改systemd必须sudo systemctl daemon-reload && sudo systemctl restart your-service - 检查
/proc/[pid]/limits是否已更新——这是唯一可信依据，别信启动脚本里的 echo -
std::thread创建失败时，别只 catch 异常就完事；在异常 handler 里加std::cerr ，才能区分是 <code>EAGAIN还是ENOMEM
线程限制这事，永远以 /proc/[pid]/limits 和 ps -T 的实时输出为准，其他都是参考。配置改了不生效，八成是没作用到真正跑起来的那个进程上。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
