JDBC资源释放的绝对安全依赖于正确使用try-with-resources机制、严格遵循逆序声明规则、避开手动关闭和引用丢失等陷阱；Connection、PreparedStatement、ResultSet须在try()内声明，按rs→ps→c依赖逆序排列，异常时主因不被掩盖，且仅限短生命周期资源适用。
Java 中 JDBC 资源释放的“绝对安全”并不存在于某一行代码，而取决于三件事：是否用对机制、是否守好顺序、是否避开常见陷阱。真正可靠的做法不是追求 100% 零风险，而是把出错路径全部堵死——try-with-resources 是目前最接近绝对安全的实践，但必须用对。
JDBC 资源必须在 try() 括号内声明并初始化
Connection、PreparedStatement、ResultSet 自 JDBC 4.0（Java 6+）起都实现了 AutoCloseable，但 JVM 只识别“在 try 后圆括号里直接创建”的对象为受管资源：
- ✅ 正确：
try (Connection c = ds.getConnection(); PreparedStatement ps = c.prepareStatement(sql)) { ... } - ❌ 错误：
Connection c = null; try { c = ds.getConnection(); ... } finally { if (c != null) c.close(); }—— 这是手动模式，不自动，易漏、易错、异常时可能跳过关闭 - ❌ 更隐蔽的错误：
try (Connection c = ds.getConnection()) { c = anotherConn; }—— 原连接引用丢失，不会被关闭
多资源必须按依赖关系逆序声明
JDBC 资源有强依赖链：ResultSet ← Statement ← Connection。关闭顺序错了，轻则报错，重则资源卡死：
- ✅ 应该这样写：
try (Connection c = ...; PreparedStatement ps = ...; ResultSet rs = ...) { ... }→ 关闭顺序是rs.close()→ps.close()→c.close() - ❌ 不要颠倒：
try (ResultSet rs = ...; PreparedStatement ps = ...) {...}—— 编译不过，因为rs初始化依赖ps，但语法上先声明rs就违反了作用域规则 - ⚠️ 注意：连接池中
c.close()实际是归还连接，不是销毁，但依然必须调用，否则连接永远不回池
异常处理要保留主因，不掩盖真实问题
传统 finally 里 close() 抛异常会覆盖业务异常；try-with-resources 内部已解决这个问题：
立即学习“Java免费学习笔记（深入）”；
- 如果
executeQuery()抛出SQLException，同时rs.close()也失败，JVM 会把关闭异常设为“被抑制异常”（suppressed），主异常照常抛出 - 可通过
e.getSuppressed()查看被抑制的异常，调试时能一眼定位 SQL 执行失败原因，而不是被“连接已关闭”干扰 - 不需要、也不应该在
try-with-resources外再套一层try-catch来捕获 close 异常——那是画蛇添足
不适用场景要心里有数
不是所有跟数据库有关的对象都适合放进 try-with-resources：
- ✅ 适合：Connection、Statement、PreparedStatement、ResultSet、文件流、HTTP 响应体等短生命周期、一次操作即结束的资源
- ❌ 不适合：EntityManager、Session、DataSource、JPA Repository 实例——它们是长生命周期对象，由 Spring 容器或事务管理器统一管控，自己关会破坏上下文
- ⚠️ 特别注意：不要在仓储（Repository）方法里对 EntityManager 调用
close()，哪怕它实现了AutoCloseable—— 这属于职责越界
