“Too many open files”本质是Java进程打开的文件描述符超限，需分三步根治：先精准定位瓶颈（查进程实际使用量、limits、用户会话及系统全局限制），再按用户级（limits.conf）、systemd级（LimitNOFILE）、内核级（fs.file-max）三层持久化调高，最后验证JVM是否生效并用lsof和JMX排查真实泄漏。
Java 应用在 Linux 线上环境报 “Too many open files”，本质是进程打开的文件描述符（包括 socket、日志文件、数据库连接、临时文件等）超出了系统对它的限制。单纯调高限制只是缓解，但必须配合验证和泄漏排查才能根治。解决需分三步走：先确认当前限制是否过低，再按层级持久化调高，最后验证 JVM 是否真正生效并检查应用是否有泄漏。
查清当前限制和真实瓶颈
别急着改配置，先定位到底是哪一层卡住了：
- 查看 Java 进程实际使用的句柄数：
lsof -p $(pgrep -f 'java.*YourApp') | wc -l - 对比该进程的软硬限制：
cat /proc/$(pgrep -f 'java.*YourApp')/limits | grep "Max open files" - 确认运行用户当前会话限制：
su - your_app_user -c 'ulimit -n'（注意必须用 su - 模拟登录环境） - 检查系统全局上限：
cat /proc/sys/fs/file-max，确保它 ≥ 单进程 hard nofile × 预估最大并发进程数
按层级持久化调高限制
Linux 文件描述符限制有三层，缺一不可：
-
用户级（PAM）：编辑
/etc/security/limits.conf，添加两行（替换 your_app_user）：your_app_user soft nofile 65536your_app_user hard nofile 65536
确保/etc/pam.d/common-session包含session required pam_limits.so -
服务管理器级（systemd）：若用 systemctl 启动，创建覆盖配置：
sudo systemctl edit your-app.service，写入：[Service]LimitNOFILE=65536
然后执行sudo systemctl daemon-reload && sudo systemctl restart your-app -
内核级（全局）：编辑
/etc/sysctl.conf，添加：fs.file-max = 2097152
执行sudo sysctl -p生效
验证 JVM 是否真正拿到新限制
很多问题出在“配置写了，但 JVM 没继承”：
立即学习“Java免费学习笔记（深入）”；
- 重启应用后，再次执行
cat /proc/$(pgrep -f 'java.*YourApp')/limits | grep "Max open files"，确认两列数值已更新 - 如果仍是旧值，说明启动方式绕过了 PAM（比如 root 下
sudo -u your_app_user java ...），此时应在启动脚本开头显式加：ulimit -n 65536 - 检查 JVM 日志或通过 JMX 获取
OperatingSystemMXBean.getOpenFileDescriptorCount()，观察是否随时间异常增长
排查应用是否真有句柄泄漏
调高限制只是兜底，持续上涨说明代码或配置有问题：
- 用
lsof -p $(pgrep -f 'java.*YourApp') -n | awk '{print $9}' | sort | uniq -c | sort -nr | head -10查看高频路径（如大量未关闭的 socket、logback 的 rolling file appender、未 close 的 InputStream） - 重点检查：数据库连接是否归还连接池、HTTP 客户端是否关闭响应体、NIO Channel 是否显式 close、日志框架是否配置了过多历史文件保留数
- Java 代码中优先使用 try-with-resources；Spring Boot 可启用
spring.resources.cache.period减少静态资源句柄占用
