try-with-resources防泄漏的前提是资源必须实现AutoCloseable接口、按依赖逆序声明、避免重新赋值或异步误用，否则仍会导致句柄泄露或关闭失效。
try-with-resources 本身是防泄漏的利器，但用错方式反而埋下隐患。关键不在语法是否正确，而在资源是否真被关、关得是否及时、关得是否完整。
确认资源对象真正可关闭
不是所有“看起来像资源”的对象都能自动释放：
- 必须实现 AutoCloseable 接口——如
FileInputStream、Connection（JDBC 4.1+）、BufferedReader符合；但Files.lines()返回的Stream<String>不实现该接口，必须显式关闭或套一层 try-with-resources - 自定义类若包装了底层资源（如封装 Socket 的工具类），需主动 implements AutoCloseable 并在
close()中释放真实句柄，否则放进 try 括号里也白搭 - 第三方 SDK 的“流式对象”（如 OkHttp 的
ResponseBody）要查文档确认close()是否真正断开连接，不能只看名字
多资源声明要按依赖顺序反向书写
关闭顺序是声明的逆序，这点直接影响资源能否安全释放：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 错误写法：
try (var bis = new BufferedInputStream(new FileInputStream("a.txt")); var fis = new FileInputStream("a.txt"))—— fis 后声明却先关闭，bis 关闭时会操作已关闭的 fis，抛IOException或静默失败 - 正确写法：
try (var fis = new FileInputStream("a.txt"); var bis = new BufferedInputStream(fis))—— fis 先声明、后关闭；bis 后声明、先关闭，依赖关系自然成立 - 同理，数据库连接 + PreparedStatement + ResultSet，应按“外层→内层”顺序声明，确保 ResultSet 先关、Connection 最后关
别让异常或逻辑中断绕过关闭流程
try-with-resources 能保证 close() 执行，但有两类情况会让它“失效”：
立即学习“Java免费学习笔记（深入）”；
-
资源 close() 方法本身抛异常且未处理：如果多个资源 close 都失败，只有第一个异常被主抛出，其余被压制（suppressed）。虽不中断关闭，但日志里看不到后续失败，可能掩盖真实泄漏点——建议在自定义
close()中捕获内部异常并打 warn 日志 -
资源在 try 块中被重新赋值：例如
try (var fis = new FileInputStream("x.txt")) { fis = new FileInputStream("y.txt"); }—— 原始 fis 引用丢失，JVM 关闭的是新 fis，旧文件句柄永远泄露 - 异步使用资源：把 try 内声明的流传给另一个线程处理，try 块一结束就关闭，而子线程还在读——必须确保资源生命周期与使用方完全对齐，必要时改用手动管理或共享引用计数
配合系统监控验证效果
代码写得再规范，也要落地验证：
- Linux 下用
lsof -p <pid>观察文件句柄数是否随请求稳定波动，而非持续增长 - JVM 参数加
-XX:+PrintGCDetails，关注 Full GC 后老年代占用是否缓慢上升（暗示资源对象堆积） - 对关键资源（如数据库连接池），开启连接泄漏检测（如 HikariCP 的
leakDetectionThreshold）
