ulimit -u 限制用户级进程/线程总数，需同步调大 /proc/sys/kernel/pid_max 系统级 PID 上限，否则高并发时因 PID 耗尽报“Resource temporarily unavailable”；systemd 服务和容器环境须单独配置，不自动继承 limits.conf。
直接结论：改 ulimit -u（用户级）和 /proc/sys/kernel/pid_max（系统级）两个地方，缺一不可；只改一个，高并发场景下仍会报 Resource temporarily unavailable。
为什么 ulimit -u 改了还是创建不了线程？
Linux 中线程也占 PID，ulimit -u 限制的是“该用户所有进程 + 线程总数”，不是纯进程数。很多服务（如 Java 应用、Node.js cluster）默认启多线程，很容易打满这个值。
- 现象：Java 启动报
java.lang.OutOfMemoryError: unable to create new native thread，但内存充足；ps -eLf | wc -l显示线程数接近ulimit -u值 - 关键点：
ulimit -u是 per-user 限制，对 systemd 服务默认不生效——因为 systemd 不读/etc/security/limits.conf，除非显式配置 - 验证方式：在目标用户下开新 shell，运行
ulimit -u；再进对应服务的进程里用prlimit -n $PID查实际生效值 - 临时绕过：启动前加
ulimit -u 65535 && ./your-app，仅限调试
怎么永久生效 ulimit -u？注意 PAM 和 systemd 两层加载
/etc/security/limits.conf 配置不会自动被所有登录方式加载，必须确保 PAM 模块启用，且 systemd 服务额外声明。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 编辑
/etc/security/limits.conf，添加（不要用空格分隔数字）：* soft nproc 65535* hard nproc 65535 - 确认
/etc/pam.d/common-session和/etc/pam.d/common-session-noninteractive中存在：session required pam_limits.so - systemd 服务必须显式设置：
在/etc/systemd/system/your-service.service的[Service]段加：LimitNPROC=65535
或全局生效：在/etc/systemd/system.conf中设DefaultLimitNPROC=65535，再运行systemctl daemon-reload - 生效前提：用户需重新登录（SSH 或 console），或重启对应 service
/proc/sys/kernel/pid_max 设太小会导致 fork 失败
pid_max 是内核能分配的 PID 上限，也是系统理论最大进程/线程总数。当 ulimit -u 调得很高，但 pid_max 还卡在默认 32768，就会出现“用户允许开 65535 个线程，但内核连 PID 都分不出”的情况。
- 查看当前值：
cat /proc/sys/kernel/pid_max（x86_64 默认 32768，部分发行版可能为 4194304） - 临时修改：
sysctl -w kernel.pid_max=4194304 - 永久修改：在
/etc/sysctl.conf加kernel.pid_max = 4194304，再执行sysctl -p - 注意上限：
pid_max最大值受架构限制（x86_64 是 4194304），设更大无效；threads-max也不应显著超过它，否则多余线程无法调度
容器环境（Docker/K8s）要单独覆盖
容器默认继承宿主机的 ulimit -u，但多数生产环境没配，导致容器内应用一开多线程就失败。
- Docker 启动时加：
--ulimit nproc=65535:65535（软硬限制都设） - Kubernetes Pod spec 中写：
securityContext:limits:nproc: "65535" - 验证容器内是否生效：
docker exec -it your-container sh -c 'ulimit -u' - 别依赖宿主机 limits.conf —— 容器 init 进程不走 PAM 流程
最容易被忽略的是 systemd 服务不自动读 limits.conf，以及容器环境完全隔离了宿主机 ulimit 设置。调参后务必用 prlimit -n $PID 直接查目标进程的实际限制，而不是只信 ulimit -u 当前 shell 的输出。
