try-with-resources 并非万能，资源泄漏主因是资源未实现 AutoCloseable、嵌套资源遗漏关闭（如 Files.lines 返回的 Stream）、异常导致提前退出或异步使用中过早关闭；需结合系统句柄监控与代码审查定位真实泄漏点。
try-with-resources 本身是防止资源泄漏的正确写法，但它不是“万能保险”。排查中发现“用了 try-with-resources 却仍有 Unclosed Resource”，说明问题不在语法错误，而在资源链未被完整覆盖、异常中断执行路径，或资源对象本身不符合 AutoCloseable 合约。
确认资源是否真正实现了 AutoCloseable
很多开发者误以为“new 了流就自动可关闭”，但关键要看构造出的对象类型：
- FileInputStream、BufferedReader、Connection（JDBC 4.1+）等标准类确实实现了 AutoCloseable；
- 自定义包装类若未显式 implements AutoCloseable 或未重写 close()，即使放在 try-with-resources 中也不会触发关闭；
- 某些第三方 SDK 返回的“流”其实是装饰器（如 OkHttp 的 ResponseBody），需确认其 close() 是否真正释放底层 socket 或文件句柄。
检查嵌套资源是否被遗漏关闭
常见陷阱是只关闭外层包装，忽略底层原始资源：
- ❌ 错误写法：
try (var reader = new BufferedReader(new FileReader("a.txt"))) { ... }—— FileReader 被关闭，但 BufferedReader 的 close() 会调用 FileReader.close()，看似安全； - ⚠️ 隐患写法：
try (var is = Files.newInputStream(Paths.get("x.log"))) { ... }—— 正确；但若改成try (var is = new DataInputStream(new FileInputStream("x.log"))) { ... }，DataInputStream.close() 会调用 FileInputStream.close()，仍安全； - ✅ 高风险场景：使用
Files.lines(path)返回 Stream<String> —— 它内部打开文件流，但 Stream 不实现 AutoCloseable，必须手动 try-with-resources 包裹或显式 close()，否则句柄泄露。
验证异常是否绕过了 close() 执行
try-with-resources 的 close() 在 try 块退出时（无论正常还是异常）都会执行，但有两类例外：
立即学习“Java免费学习笔记（深入）”；
- 如果 try 块中抛出异常，且资源的 close() 方法也抛出异常，则 close 异常可能被压制（suppressed），主异常仍抛出，但 close 实际已执行；
- 真正危险的是：资源对象在 try 块内被提前赋值为 null 或重新指向新对象，导致原对象脱离作用域，JVM 不再对其调用 close()；
- 更隐蔽的是：资源被传递给异步任务（如 CompletableFuture.runAsync(() -> use(is))），而 try 块已结束，is 被关闭，但异步线程仍在读 —— 这不是未关闭，而是“过早关闭”，也会报 IOException，易被误判为泄漏。
用系统级观测反向验证是否真未关闭
不依赖代码逻辑猜测，直接看操作系统是否还持有句柄：
- Linux/macOS：定时执行
lsof -p <pid> | grep "\.log|\.dat" | wc -l，观察数量是否随请求增长； - Windows：用 Process Explorer 打开目标进程 → Handles 标签页 → 搜索扩展名，看同一文件是否反复出现多个句柄；
- Java 层辅助：启动时加
-Djdk.net.URLClassPath.disableJarChecking=true并启用-XX:+PrintGCDetails，结合 jstack 查看阻塞在线程 IO 调用上的堆栈，往往指向未释放的 Socket 或 FileChannel。
本质上，try-with-resources 是语法糖，不是魔法。它只保证“该对象的 close() 被调用”，不保证 close() 内部逻辑一定释放了所有底层资源。定位 Unclosed Resource，核心是把“谁没关”变成“哪个 fd 没退”，再倒查是哪个对象创建了它却没彻底清理。
