/proc/sys/kernel/threads-max是系统当前允许创建的线程总数上限，由内存和页大小计算得出（≈total_memory_kb/(4*page_size)），但受pid_max截断；查法为cat /proc/sys/kernel/threads-max。
直接看 /proc/sys/kernel/threads-max
这个值就是系统当前允许创建的线程总数上限，不是估算值，也不是理论值，而是内核实际 enforce 的硬限制。它由内存总量和页大小动态计算（≈ total_memory_kb / (4 * page_size)），但会被 /proc/sys/kernel/pid_max 截断：如果 threads-max > pid_max，内核会静默设为 pid_max。
查法就一条命令：
cat /proc/sys/kernel/threads-max
注意：ulimit -u 查的是单用户进程+线程总数（RLIMIT_NPROC），Java 启动时继承这个值，但它不决定“能不能 fork 出新线程”——真正卡住你的，往往是 threads-max 耗尽。
ps -eLf | tail -n +2 | wc -l 是唯一靠谱的当前线程总数统计
top 或 htop 显示的 “Tasks” 数不准：top 默认只显示屏幕可见行数（几百行），htop 会过滤掉 [kthreadd]、[ksoftirqd/0] 这类内核线程——而它们也占用 threads-max 配额，同样会导致 java.lang.OutOfMemoryError: unable to create new native thread。
真正反映内核调度器当前管理的所有线程（含用户线程 + 内核线程）的命令是：
ps -eLf | tail -n +2 | wc -l
-
ps -eLf强制 full format，字段稳定，避免 busybox ps 等精简版漏列 -
tail -n +2去掉表头行，防止误计 - 该结果可脚本化、无竞态、无需 root 权限（普通用户也能跑）
别被 ulimit -a 和 /proc/sys/kernel/pid_max 带偏
ulimit -a 输出里的 max user processes (-u) 是单用户软硬限制，影响 shell 子进程，但不等于系统级线程池容量；pid_max 是 PID 编号池上限，数值大不代表线程真能建那么多——它只是个编号池，而 threads-max 才是资源配额控制器。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
验证是否真触顶的方法很直接：
- 堆内存充足，但 Java 报
unable to create new native thread - 运行
ps -eLf | wc -l接近或等于cat /proc/sys/kernel/threads-max - 此时改
ulimit -u没用，必须调threads-max或pid_max（若后者更小）
临时修改 threads-max 要防 Invalid argument
执行 echo 65536 | sudo tee /proc/sys/kernel/threads-max 失败？大概率是目标值超过了当前 pid_max。先检查：
cat /proc/sys/kernel/pid_max
如果它比你想设的 threads-max 小，得先扩 pid_max：
sudo sysctl -w kernel.pid_max=65536
再设 threads-max 才生效。改完立即起效，已运行线程不受影响，也不需重启服务。
真正容易被忽略的点是：容器里改 /proc/sys/kernel/threads-max 只对当前 PID namespace 生效，且前提是 procfs 没被只读挂载——Docker 默认是可写的，但 Kubernetes Pod 若启用了 readOnlyRootFilesystem: true，写入会静默失败。
