Linux线程数限制由内核级threads-max、用户级ulimit -u、进程级pid_max三层叠加构成，任一层触顶均导致“unable to create new native thread”等错误，需逐层检查验证并针对性调优。
Linux线程数限制不是单一配置，而是三层叠加：内核级 threads-max、用户级 ulimit -u、进程级 pid_max。任一层触顶都会报 resource temporarily unavailable 或 unable to create new native thread，必须逐层检查。
查清当前哪一层卡住了
先快速定位瓶颈点，避免盲目调参：
- 看系统总线程上限：
cat /proc/sys/kernel/threads-max—— 若接近或等于当前线程数（ps -eLf | wc -l），说明内核级已满 - 看当前用户限制：
ulimit -u—— 普通用户默认常为1024，Java应用一开几百线程就爆 - 看 PID 总量天花板：
cat /proc/sys/kernel/pid_max—— 若ps -eLf | wc -l接近此值，fork: Cannot allocate memory就是它在作祟 - 验证某进程实际限制：
prlimit -n $PID（-n对应nproc），确认是否继承了预期值
改用户级线程上限（最常见生效点）
绝大多数 Java、Node.js、Python 多线程服务卡在这层，因为 ulimit -u 同时约束进程+线程总数（Linux 中线程即轻量进程）：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 临时生效（当前 shell 及子进程）：
ulimit -u 65535 - 永久生效（需新登录会话）：编辑
/etc/security/limits.d/90-nproc.conf，把这行改成更大值：* soft nproc 65535 * hard nproc 65535
- 注意：systemd 服务不读
limits.conf，得在 service 文件里加LimitNPROC=65535，或全局设DefaultLimitNPROC=65535在/etc/systemd/system.conf - 容器环境（Docker/K8s）默认继承宿主机
ulimit，但必须显式传参：docker run --ulimit nproc=65535:65535；K8s 则填securityContext.limits.nproc
调内核级 threads-max 和 pid_max
当用户级已放开，但 ps -eLf | wc -l 仍卡在几万、且 cat /proc/sys/kernel/threads-max 值偏低时，才动内核参数：
-
threads-max默认≈内存页数 / 4，不能瞎设太高；建议值不超过pid_max的 80%，例如：sysctl -w kernel.threads-max=2097152 -
pid_max决定整个系统能分配多少 PID，x86_64 最高支持约4194304；若跑万级容器或微服务，建议设为4194304：sysctl -w kernel.pid_max=4194304 - 永久写入：
echo "kernel.threads-max = 2097152" >> /etc/sysctl.conf，再sysctl -p；pid_max同理 - 关键约束：
threads-max不应显著超过pid_max，否则多出来的线程根本分不到 PID，形同虚设
验证修改是否真正落地
改完不验证等于没改，尤其要注意“看似生效、实则被覆盖”的情况：
- 新开终端执行
ulimit -u，确认值变了；旧终端不会刷新 - 查内核参数：
sysctl kernel.threads-max kernel.pid_max - 对运行中的 Java 进程（如 Tomcat）查实际限制：
prlimit -n $(pgrep -f tomcat)，不是看启动脚本里的ulimit命令 - 若用 systemd 启动，务必确认
systemctl show --property=LimitNPROC输出匹配预期，否则limits.conf白配
最容易被忽略的是：systemd 服务绕过 /etc/security/limits.conf，还有容器未透传 ulimit 导致应用拿到的仍是默认 1024。线程数问题从来不是改一个地方就能解决的，得像查漏一样一层层过。
