/proc/sys/kernel/threads-max 是决定能否新建线程的关键阈值，它表示系统级总线程上限，受内存和 pid_max 约束；ulimit -u 和 pid_max 均非直接限制因素，但需协同调整以防失效。
直接看 /proc/sys/kernel/threads-max，它才是决定“还能不能 fork 出新线程”的关键阈值，不是 ulimit -u，也不是 pid_max。
怎么查当前系统最大线程数限制
执行这条命令就能看到内核当前允许的最大线程总数：
cat /proc/sys/kernel/threads-max
注意：这个值是全局的、所有用户共享的，和内存总量强相关（默认 ≈ total_memory_kb / (4 * page_size)），但受 pid_max 约束——如果 threads-max > pid_max，内核会静默截断到 pid_max 值。
- 别只跑
ulimit -u：它查的是单用户进程+线程总数（即RLIMIT_NPROC），Java 进程启动时继承 shell 的这个限制，但即使它没满，threads-max也可能卡死你 - 别只信
pid_max：它只是 PID 编号池上限，理论值大，但不等于线程能真建那么多 - 验证是否真触顶：Java 报
java.lang.OutOfMemoryError: unable to create new native thread且堆内存充足，大概率就是threads-max到了
临时修改 threads-max（重启失效）
用 sysctl -w 或直接写 /proc 都行，适合快速验证或应急扩容：
sudo sysctl -w kernel.threads-max=65536
或者：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
echo 65536 | sudo tee /proc/sys/kernel/threads-max
- 必须有 root 权限，否则报
Permission denied - 写入失败常见原因是
pid_max小于目标值，错误提示是Invalid argument，先检查：cat /proc/sys/kernel/pid_max - 改完立即生效，已运行的线程不受影响，也不需要 reload 任何服务
- 在容器里改，只对当前 namespace 生效（前提是 procfs 没被只读挂载）
永久生效：写 sysctl 配置文件
把配置固化到 /etc/sysctl.d/ 下的独立文件，避免和主配置混在一起：
echo "kernel.threads-max = 65536" | sudo tee /etc/sysctl.d/99-thread-limit.conf
然后重载：
sudo sysctl --system
- 不要直接改
/etc/sysctl.conf，后续维护和卸载困难 - 用
sysctl --system而不是sysctl -p，前者会加载/etc/sysctl.d/全部文件，后者可能漏掉 - RHEL/CentOS 7+ 等发行版若启用了
systemd-sysctl，还需执行：sudo systemctl restart systemd-sysctl - 记得同步确认
pid_max是否足够：sudo sysctl kernel.pid_max，必要时一并调高
为什么改了还是创建失败？绕不开的三个层级
线程创建失败从来不是单一参数问题。你得按顺序排查这三层：
-
threads-max：系统级总上限，cat /proc/sys/kernel/threads-max -
pid_max：PID 号池大小，必须 ≥threads-max，否则无效，cat /proc/sys/kernel/pid_max -
ulimit -u：用户级软硬限制（即RLIMIT_NPROC），Java 进程启动时继承 shell 的该值；查某进程实际值用：prlimit -n $PID
最容易被忽略的是第三层——哪怕 threads-max 改到 200 万，一个 Java 进程如果是在 ulimit -u 4096 的 shell 里启动的，它最多也就建 4096 个线程（含主线程）。
