Java防fd泄露核心是显式及时关闭所有流：强制try-with-resources、分层关闭嵌套流、禁用流字段持有、异步任务配清理钩子、Cleaner作兜底；排查靠观测fd数量趋势、lsof/Process Explorer定位文件、file-leak-detector抓调用栈。
Java 中防止文件描述符（fd）泄露，核心就一条：**所有打开的流必须显式、确定、及时关闭**。它不靠 GC，不靠 finalize，也不靠 System 类——只靠代码结构和运行时保障机制。
怎么防止文件描述符泄露
防止的关键是切断“打开不关”的路径，从编码习惯到资源生命周期全程设防：
-
强制使用 try-with-resources：只要类实现
AutoCloseable（如FileInputStream、BufferedReader、ZipInputStream），就必须在 try 括号中声明。JVM 保证无论是否异常、是否 return，都会按逆序调用close()。 -
嵌套流要分层覆盖：比如
new BufferedReader(new FileReader(f))，只需包裹外层BufferedReader即可，其close()会自动级联关闭底层FileReader；但若手动用File.open()得到FileDescriptor或FileChannel，就得单独关。 -
禁用静态/实例字段持有流：不要把
FileInputStream存成static或对象成员变量，否则它的生命周期脱离方法作用域，极易被长期持有着不放。 -
异步或长周期任务必须配清理钩子：例如
CompletableFuture或定时任务中打开了文件，需在whenComplete或 finally 块中显式 close；若任务可能被中断，还要响应Thread.interrupted()并提前释放。 -
用 Cleaner 设兜底（JDK9+）：对极少数无法用 try-with-resources 包裹的 native 资源（如
MappedByteBuffer），可注册Cleaner，在对象不可达时触发清理逻辑——但这只是保险，不能替代主动关闭。
怎么排查文件描述符泄露
排查不是看日志猜，而是直接观测系统级事实。重点盯住 fd 数量是否随时间单向增长：
-
查实时 fd 数量（Linux/macOS）：执行
ls -l /proc/[pid]/fd | wc -l，每 30 秒采样一次，画趋势图。若持续上涨，基本锁定泄漏。 -
定位泄漏文件类型：用
lsof -p [pid] | grep -E "\.(log|txt|csv|dat)" | head -20，看是不是某类业务文件反复打开却未关闭。 - Windows 下用 Process Explorer：附加 Java 进程 → View → Lower Pane View → Handles → 搜索扩展名，观察同路径句柄是否堆积数十个以上。
-
用 file-leak-detector 工具抓堆栈：加 JVM 参数
-javaagent:file-leak-detector.jar=http=19999，访问http://localhost:19999可看到每个打开文件对应的线程和完整调用栈，精准定位哪行代码开的、为什么没关。 -
加速复现（.NET 不适用，Java 可参考思路）：Java 本身无等效
DOTNET_SYSTEM_IO_DISABLEFILECACHE，但可通过减小系统 ulimit（ulimit -n 100）让 “Too many open files” 快速暴露，再结合 jstack 看卡在哪次 IO 调用上。
常见误判和隐蔽坑点
很多代码“看着关了”，其实根本没生效：
立即学习“Java免费学习笔记（深入）”；
- 用了
try-finally但close()写在 finally 外面；或者close()调用前没判空，对象已是 null 导致跳过。 - 流被包装后传给其他组件（如上传到某个缓存服务、塞进监听器队列），原始方法早已退出，但流还在别处被引用着。
- 在
finally里调close()，结果close()自己抛IOException，掩盖了主逻辑异常，且后续 close 可能因异常中断而不再执行。 - 用
Files.lines(path)或Files.readAllLines()等便捷方法——它们内部打开流，但不返回流对象，也就无法手动关；应改用Files.newBufferedReader()+ try-with-resources。
不复杂但容易忽略：句柄泄漏不是内存泄漏，但它会让系统在无声中瘫痪。盯住 fd 数、用对工具、写死关闭逻辑，问题就可控。
