直接用try-with-resources关闭connection报错是因为旧版jdbc驱动（如mysql 5.1.x）未实现autocloseable接口，需升级驱动至8.0+并确保jdk≥7。
为什么直接用 try-with-resources 关闭 Connection 会报错？
因为 Connection 接口在 JDBC 4.0（Java 7+）才实现 AutoCloseable，如果你用的是旧版驱动（比如 MySQL Connector/J 5.1.x 或更早），Connection 仅实现 java.sql.Connection，而没实现 AutoCloseable —— 此时编译直接失败，提示 “cannot be auto-closed”。
实操建议：
- 检查驱动版本：
System.out.println(Driver.class.getPackage().getImplementationVersion()) - 升级到 MySQL Connector/J 8.0+、PostgreSQL JDBC 42+ 等明确支持 JDBC 4.1+ 的驱动
- 确认 JDK 版本 ≥ 7，且项目编译目标（
source/target）设为 7 或更高
try-with-resources 中必须声明哪些资源？
不是只写 Connection 就够了。只要用了 Statement、PreparedStatement、ResultSet，且它们的生命周期完全包裹在本次数据库操作内，就该一并放进资源列表——否则可能泄露 ResultSet（尤其大结果集），或触发连接池“连接未正常归还”告警。
正确写法示例：
try (Connection conn = dataSource.getConnection();
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
ResultSet rs = stmt.executeQuery()) {
stmt.setLong(1, userId);
while (rs.next()) {
// 处理数据
}
} catch (SQLException e) {
// 异常处理
}
注意：setLong() 必须在 executeQuery() 之前调用；否则参数未绑定，查不到数据。
使用连接池时，close() 真的关闭物理连接吗？
不关。调用 Connection.close() 在 HikariCP、Druid、DBCP2 等主流池中，实际是将连接归还给池，而非销毁 TCP 连接。所以 try-with-resources 触发的 close() 是安全的，也是推荐做法。
但要注意两个坑：
- 别在
finally块里再手动conn.close()—— 重复 close 可能抛SQLException（如 HikariCP 会报 “connection is closed”） - 如果连接是从 Spring
@Transactional方法中获取的，Spring 会代理Connection，此时try-with-resources的close()被拦截并忽略（由事务管理器统一控制），不会提前归还
异常被压制（suppressed）时怎么排查？
try-with-resources 在 try 块和资源 close() 都抛异常时，会把 close 抛出的异常“压制”（suppressed），只抛出 try 块的主异常。这容易掩盖连接未释放的根本原因。
调试建议：
- 在 catch 块里显式检查：
e.getSuppressed()，打印所有被压制的异常 - 开启连接池日志（如 HikariCP 的
debug级别），观察是否有 “connection leak detection triggered” 提示 - 避免在
close()前做耗时操作（比如写日志、发 HTTP 请求），否则 close 超时会被中断，导致资源残留
真正容易被忽略的是：当多个资源嵌套初始化（比如先 new Statement 再 new ResultSet），而中间某步抛出 NullPointerException 或 RuntimeException，前面已成功创建的资源仍会被自动关闭——但前提是它们已赋值给 final 或 effectively final 的变量。一旦漏写分号、错用逗号或提前 return，资源声明就失效了。
