/proc/sys/kernel/threads-max是决定能否新建线程的关键阈值，它表示系统级总线程上限，受内存和pid_max约束；ulimit -u和pid_max均非直接限制因素，但需协同调整以防失效。
ulimit -u 改了不一定管用，/proc/sys/kernel/threads-max 才是真正卡死新建线程的开关。绝大多数“unable to create new native thread”报错，根源不在 Java 堆内存，而在三层限制中某一层悄悄触顶。
查清到底是哪一层在拦你
别一上来就改配置，先定位瓶颈点：
-
cat /proc/sys/kernel/threads-max—— 看系统总线程上限，若ps -eLf | wc -l接近这个值，就是它卡住了 -
ulimit -u—— 普通用户默认常为 1024，Java 进程启动时直接继承，prlimit -n $PID可确认进程实际拿到的值 -
cat /proc/sys/kernel/pid_max—— 若ps -eLf | wc -l接近此值，且fork: Cannot allocate memory报错，说明 PID 池耗尽 - 容器里还要看是否传了
--ulimit nproc，K8s 需检查securityContext.limits.nproc
优先调 ulimit -u（最常见生效点）
90% 的 Java、Python 多线程服务卡在这层，因为 Linux 中线程即轻量进程，ulimit -u 同时约束进程+线程总数：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 临时生效（当前 shell 及子进程）：
ulimit -u 65535 - 永久生效（新登录会话）：写入
/etc/security/limits.d/90-nproc.conf，内容为：* soft nproc 65535* hard nproc 65535 - root 用户也要单独配：
root soft nproc 65535和root hard nproc 65535，否则 SSH 登录后仍可能受限 - systemd 服务不读 limits.conf，必须在 service 文件
[Service]段加：LimitNPROC=65535，或全局设DefaultLimitNPROC=65535在/etc/systemd/system.conf
改 /proc/sys/kernel/threads-max（内核级兜底）
当 ulimit -u 已放开，但 ps -eLf | wc -l 仍卡在几万、且 cat /proc/sys/kernel/threads-max 明显偏低时才动它：
- 临时修改（立即生效，重启失效）：
sudo sysctl -w kernel.threads-max=2097152或echo 2097152 | sudo tee /proc/sys/kernel/threads-max - 写入前务必确认：
cat /proc/sys/kernel/pid_max≥ 目标值，否则会报Invalid argument - 永久生效：写入
/etc/sysctl.d/99-thread-limit.conf，内容为：kernel.threads-max = 2097152，再执行sudo sysctl --system - RHEL/CentOS 7+ 还需
sudo systemctl restart systemd-sysctl
别漏掉 pid_max（系统级 PID 池天花板）
它不是直接限制线程数，但它是所有进程/线程分配 PID 的池子。当 ulimit -u 和 threads-max 都调高了，却还是 fork 失败，大概率是它没跟上：
- 临时调高：
sudo sysctl -w kernel.pid_max=4194304 - 永久配置：在
/etc/sysctl.d/99-pid-limit.conf加kernel.pid_max = 4194304，再sudo sysctl --system - x86_64 架构上限约 4194304，别设更高，否则无效
- 改完记得验证：
cat /proc/sys/kernel/pid_max和ls /proc/[0-9]* | wc -l是否仍有余量
改完不验证等于白改，尤其要注意 prlimit -n $PID 查具体进程实际继承到的值——很多服务跑在 systemd 下，limits.conf 对它完全没用。
