需同时调大用户级线程上限（ulimit -u）、系统PID上限（/proc/sys/kernel/pid_max）和内核线程总数上限（/proc/sys/kernel/threads-max），三者缺一不可，否则仍报“Resource temporarily unavailable”。
直接调大用户级线程上限（ulimit -u），同时确保系统级 PID 和内核线程总数不成为瓶颈——三者缺一不可，否则仍会报“Resource temporarily unavailable”。
查清当前卡在哪一层
先快速定位真正瓶颈，避免只改一层白忙活：
-
看用户级限制：运行
ulimit -u，普通用户默认常为 1024，Java 或 Node.js 多线程服务很容易打满 -
看系统 PID 上限：运行
cat /proc/sys/kernel/pid_max，若ps -eLf | wc -l接近该值，说明 fork 已无可用 PID -
看内核线程总数上限：运行
cat /proc/sys/kernel/threads-max，若总线程数逼近此值，就是内核硬限制挡路 -
查具体进程实际值：用
prlimit -n $PID确认该服务进程是否真继承了你设的nproc值
永久生效用户级线程上限（最常用）
绝大多数高并发服务（如 Java、Python 多线程、Node.js cluster）都卡在这层，因为 ulimit -u 同时约束该用户所有进程 + 线程总数：
- 编辑
/etc/security/limits.d/90-nproc.conf（推荐优先用此文件，比limits.conf更清晰），添加两行：
* soft nproc 65535
* hard nproc 65535 - 确认 PAM 加载生效：检查
/etc/pam.d/common-session中存在session required pam_limits.so - 用户需重新登录（SSH 或 console）才生效；已有 shell 不会自动更新
systemd 服务必须单独配置
systemd 默认不读 limits.conf 或 limits.d，服务启动时不会继承用户级设置：
- 在服务单元文件（如
/etc/systemd/system/myapp.service）的[Service]段添加：
LimitNPROC=65535 - 或全局生效：在
/etc/systemd/system.conf中设DefaultLimitNPROC=65535，再执行systemctl daemon-reload - 改完后必须重启服务：
systemctl restart myapp，不是 reload
同步调大系统级和内核级上限
只放开用户限制，但 pid_max 或 threads-max 还卡在默认值，高并发下照样失败：
-
调大 PID 总量天花板：
临时：sysctl -w kernel.pid_max=4194304
永久：在/etc/sysctl.conf加kernel.pid_max = 4194304，再运行sysctl -p -
调大系统总线程数：
临时：sysctl -w kernel.threads-max=200000
永久：在/etc/sysctl.conf加kernel.threads-max = 200000，再运行sysctl -p
