java线上服务报“too many open files”需三步协同解决：先查cat /proc//limits确认真实限制值；再按启动方式配对配置——systemd服务须在service文件中设limitnofile和limitnproc并重载，脚本启动需加ulimit -n，同时补全limits.conf并启用pam_limits.so；最后用lsof -p 排查句柄泄漏。
Java 线上服务报 “Too many open files”，不是代码写错了，而是 Linux 进程级文件句柄限制（nofile）卡住了。单纯改 /etc/security/limits.conf 常常无效——必须匹配启动方式、验证生效路径、同步排查泄漏，三者缺一不可。
确认当前进程真实限制值
别猜，先看 Java 进程实际读到的值：
- 查 PID：
pgrep -f 'java.*YourApp'（替换 YourApp 为应用标识） - 查 limits：
cat /proc/<pid>/limits | grep "Max open files"</pid> - 若 Soft Limit 是 1024 或 4096，说明配置没生效；若 Hard Limit 过低（如低于 65536），则 soft 无法设高
按启动方式配对修改配置
systemd 启动的服务完全不读 limits.conf，交互式登录启动才走 PAM 流程：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
systemd 服务（主流部署）：编辑
/etc/systemd/system/your-app.service，在[Service]段加两行：LimitNOFILE=65536LimitNPROC=65536
执行sudo systemctl daemon-reload && sudo systemctl restart your-app -
脚本启动（如 start.sh）：在脚本首行加
ulimit -n 65536，确保执行用户有提升硬限权限 -
root 或专用用户（如 appuser）：仍需补全
/etc/security/limits.conf，覆盖该用户：appuser soft nofile 65536appuser hard nofile 65536
确保 PAM limits 模块启用
limits.conf 是 PAM 的配置文件，模块未加载等于白配：
- Ubuntu/Debian：检查
/etc/pam.d/common-session是否含session required pam_limits.so - RHEL/CentOS：检查
/etc/pam.d/system-auth或/etc/pam.d/login - 若缺失，手动添加该行（注意是
required，不是optional或路径错误） - 修改后需重新 SSH 登录或切换用户验证：
su - appuser -c 'ulimit -n'
排除泄漏并验证效果
调高限制只是兜底，持续上涨说明存在资源泄漏：
- 实时统计句柄数：
lsof -p <pid> | wc -l</pid>，间隔 1 分钟多次采样 - 分类查看占用来源：
lsof -p <pid> | awk '{print $8}' | sort | uniq -c | sort -nr | head -10</pid>（常见泄漏源：未关闭的 Socket、InputStream、FileChannel、日志滚动异常） - 验证生效后，观察错误是否消失；若仍报错，检查 JVM 是否显式设置了
-XX:MaxDirectMemorySize或 Netty 的EpollEventLoopGroup线程数是否触发 nproc 限制
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
