本质是文件描述符未释放而非流太多，操作系统限制进程fd数量，Java GC不回收系统资源，必须显式关闭；应严格用try-with-resources管控生命周期，避免手动close、嵌套流误关、异步传参等泄漏场景，并通过编译拦截、运行监控、压测验证三道防线工程化防控。
高并发下 IO 流未关闭引发的 java.io.IOException: Too many open files，本质不是“流太多”，而是“句柄没释放”。操作系统对每个进程的文件描述符（fd）数量有限制（如默认 1024），而每个打开的文件、socket、管道都会占用一个 fd。Java 的 GC 不会回收这些系统资源，必须显式释放。
核心原则：所有流生命周期必须由代码严格管控
不能依赖 finalize() 或等待 GC；不能靠“看起来关了”——要确保在 所有执行路径下都真正关闭，包括异常分支、提前 return、异步回调等场景。
- 优先用
try-with-resources：JDK 7+ 全面支持，自动覆盖正常执行和异常退出两种情况 - 避免手动
close()+finally：容易漏写、重复调用、或close()自身抛异常导致主异常被掩盖 - 禁止把流传给长期存活对象（如静态缓存、监听器、线程池任务）后就撒手不管
高频泄漏场景与写法避坑
这些地方最容易“看似安全，实则泄漏”：
-
HTTP 响应体未消费：用 OkHttp / HttpClient 发起请求后，只检查 status code 却不调用
response.body().close()或response.close()，底层 socket fd 一直卡在 CLOSE_WAIT -
XML/JSON 解析流未托管：
DocumentBuilder.parse(is)、ObjectMapper.readValue(is, ...)等框架方法绝不会关闭传入的 InputStream，必须由你 wrap 在 try-with-resources 中 -
嵌套流未统一释放：例如
new BufferedReader(new InputStreamReader(new FileInputStream(...)))，只需关闭最外层BufferedReader，内部会逐级委托关闭；但若只关FileInputStream，上层缓冲流仍持有句柄 -
异步流处理中 using 失效：Java 中
CompletableFuture.supplyAsync(() -> { try (var is = ...) { ... } })是安全的；但若流对象在异步块外创建、再传入，则脱离作用域后无法自动释放
上线前强制落地的三道防线
单靠开发自觉不可靠，需工程化约束：
立即学习“Java免费学习笔记（深入）”；
-
编译期拦截：接入自研 Checkstyle 规则，扫描 AST，对未包裹在 try-with-resources 中的
InputStream/OutputStream/Reader/Writer及其子类直接报错阻断构建 -
运行时监控：在应用启动时记录初始 fd 数（
ls -l /proc/$PID/fd | wc -l），定时采样并告警增长趋势；结合lsof -p $PID | awk '{print $5}' | sort | uniq -c | sort -nr | head -5快速定位高频句柄类型 -
压测验证：模拟高峰期持续请求（如每秒 100 次文件读取），观察 fd 数是否线性增长；启用
-XX:+PrintGCDetails和jstack $PID辅助判断线程是否阻塞在 IO 调用上
兜底策略：系统级与 JVM 层面协同
即使代码有疏漏，也要降低影响范围：
- 调整进程级限制：
ulimit -n 65536（临时）或在 systemd service 文件中设LimitNOFILE=65536（长期） - 禁用 JDK 文件缓存（仅调试用）：加 JVM 参数
-Djdk.net.URLClassPath.disableJarChecking=true -Dsun.net.inetaddr.ttl=60，加快句柄泄漏暴露速度 - 避免全局共享流：如
static FileInputStream或复用同一BufferedInputStream实例服务多个请求，极易引发竞争和误关
