最准确的系统级最大PID数是cat /proc/sys/kernel/pid_max返回的实时值，x86_64默认为32768或4194304，超4194304会被静默截断；ulimit -u是用户级限制，systemd服务需单独配置LimitNPROC，三者取最小值决定实际上限。
直接看内核参数 /proc/sys/kernel/pid_max
这是最准确、最实时的系统级最大 PID 数（即进程+线程总数上限），Linux 中所有进程和线程共享这个 PID 池。cat /proc/sys/kernel/pid_max 输出的值就是当前生效的硬上限。
常见值：x86_64 系统默认通常是 32768 或 4194304；32 位系统多为 32768。超过 4194304 的写入会被内核静默截断，不报错但不生效。
别用 sysctl kernel.pid_max 查——它可能返回缓存值，而 /proc/sys/ 下的是内核运行时真实状态。
ulimit -u 显示的是用户级限制，不是系统上限
ulimit -u 输出的是当前 shell 及其子进程（包括 Java 所有线程）能使用的最大 PID 数，它受 /etc/security/limits.d/ 配置控制，但只对新登录会话生效。
常见陷阱：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 普通用户常被设为
1024或4096，远低于pid_max，但高并发应用一开几千线程就爆 - 改了
/etc/security/limits.conf后没新开 shell，ulimit -u仍显示旧值 - systemd 服务完全忽略 limits.conf，必须在
.service文件里加LimitNPROC=
真正卡住 fork 的，是 pid_max 和 ulimit -u 的交集
进程创建失败时，错误往往是 fork: Cannot allocate memory，但 dmesg | tail 会看到 PID allocation failure——这不是内存不足，是 PID 耗尽。
验证方法：
- 已用 PID 数：
ls /proc/[0-9]* | wc -l（轻量，推荐）或ps -e --no-headers | wc -l - 剩余空间 =
cat /proc/sys/kernel/pid_max减去已用数 - 如果剩余 > 0 但 still fork 失败，说明
ulimit -u更小，成了瓶颈
容器和 systemd 场景下容易漏掉的配置点
Docker 默认继承宿主机 ulimit -u，但不会自动加载 /etc/security/limits.d/；Kubernetes 和 systemd 则完全绕过该机制。
必须显式配置：
- Docker 启动时加：
--ulimit nproc=65535:65535 - Kubernetes Pod：
securityContext.limits.nproc: 65535 - systemd 服务：
LimitNPROC=65535写进.service文件，或全局设DefaultLimitNPROC=65535在/etc/systemd/system.conf
调优时只改 pid_max 或只调 ulimit 都不够——两者都要对齐，且 ulimit -u 不能超过 pid_max，否则多余部分无意义。
