Java进程ulimit限制不生效，须查其真实启动上下文：手动运行才继承shell限制，systemd等托管服务需配LimitNOFILE并重载；验证必须看/proc//limits而非ulimit -n。
Java进程的ulimit -n限制不生效？先确认启动方式
OpenJDK 进程的文件句柄限制，**不是看当前终端的 ulimit -n 值，而是看它被哪个上下文启动的**。如果你用 java -jar app.jar 手动运行，那它继承当前 shell 的限制；但绝大多数生产环境是通过 systemd、supervisord、Docker 或 init 脚本启动的——这些机制会绕过 /etc/security/limits.conf，导致你改了文件却完全没用。
验证方法：找到 Java 进程 PID（如 pgrep -f "myapp.jar"），然后执行：cat /proc/。这个输出才是真实生效值。
- 如果显示
1024或4096，说明限制太低且未正确配置 - 如果软硬限制不一致（如 soft=1024, hard=65535），Java 可能只拿到软限，需显式提升
- 如果显示
unlimited，但应用仍报Too many open files，大概率是fs.file-max或fs.nr_open卡住了
systemd 启动的 Java 服务必须配 LimitNOFILE
/etc/security/limits.conf 对 systemd 托管的服务基本无效——因为 systemd 不走 PAM 登录流程。你得在 service 文件里直接声明。
操作步骤：
- 运行
sudo systemctl edit your-java-app.service（推荐覆盖式编辑，避免改错主文件） - 填入以下内容：
[Service] LimitNOFILE=65535 LimitNPROC=65535
- 执行
sudo systemctl daemon-reload && sudo systemctl restart your-java-app - 再用
cat /proc/$(pgrep -f "your-app.jar")/limits | grep "Max open files"确认两行值都变成65535
注意：LimitNOFILE 是软硬合一设置，不需要分开写 soft/hard；设太高（如 >100 万）可能触发 fs.nr_open 限制，导致启动失败。
Java 应用自身也可能主动调低句柄数
某些 Java 框架或中间件（如旧版 Netty、Spring Boot DevTools、或自定义 FileDescriptor 操作代码）会在启动时调用 ulimit -n 查询并缓存该值，之后即使你动态调高系统限制，它也不会重新读取。更隐蔽的是：JVM 启动参数里加了 -XX:+UseG1GC 等选项后，某些 GC 日志轮转逻辑会悄悄打开大量临时文件，加剧耗尽风险。
排查建议：
- 加 JVM 参数
-Djdk.lang.Process.launchMechanism=vfork（仅 JDK 10+），可减少 fork 子进程时的 fd 复制开销 - 禁用不必要的日志滚动（如 Logback 的
- 检查是否有代码显式调用
new FileInputStream("/dev/zero")类操作，这类资源若未 close，fd 就不会释放
别漏掉内核级兜底参数 fs.nr_open 和 fs.file-max
就算你把每个 Java 进程都设到 65535，如果 fs.nr_open（单进程硬上限）或 fs.file-max（全系统总池子）太小，照样失败。而且这两个值有依赖关系：hard nofile 在 /etc/security/limits.conf 中不能超过 fs.nr_open，否则用户登录会卡死。
检查与设置：
- 查当前值：
cat /proc/sys/fs/nr_open和cat /proc/sys/fs/file-max - 临时调高：
sudo sysctl -w fs.nr_open=2097152、sudo sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf追加两行：fs.nr_open = 2097152 fs.file-max = 1048576
再运行sudo sysctl -p
重点提醒：fs.nr_open 是单个进程能申请的最大 fd 数，它决定了 ulimit -Hn 的天花板；而 fs.file-max 是全局总和，建议按「最大并发连接数 × 进程数 × 1.5」估算，别盲目拉到千万级——每 fd 占约 1KB 内核内存。
