AutoCloseable仅提供标准close()入口，不负责归还；连接池（如HikariCP）在close()中实现归还逻辑，将连接放回池而非物理关闭，配合try-with-resources确保资源安全释放。
AutoCloseable 本身不负责连接池中资源的“归还”，它只提供一个标准的关闭入口（close() 方法）。真正执行归还逻辑的是连接池实现（如 HikariCP、Druid、Apache DBCP）在 close() 方法内部做的——把连接对象标记为可复用，放回池中，而非物理关闭。
为什么 Connection 实现了 AutoCloseable？
这是 JDBC 规范的要求。从 Java 7 开始，java.sql.Connection 继承自 AutoCloseable，目的是支持 try-with-resources 语法，让开发者能自动释放资源。但关键点在于：
- 调用
connection.close()不一定等于断开数据库连接； - 在连接池环境下，它大概率只是将连接对象“还给池子”；
- 物理关闭由连接池根据空闲超时、最大生命周期等策略异步触发。
连接池如何利用 AutoCloseable？
以 HikariCP 为例：它返回的 Connection 是一个代理对象（HikariProxyConnection），其 close() 方法被重写：
- 先清理当前线程绑定的事务/状态；
- 检查连接是否有效、是否泄露（通过弱引用跟踪）；
- 将底层真实连接（
PhysicalConnection）重新放入内部的并发队列（ConcurrentBag）； - 唤醒等待连接的线程（如有）。
整个过程对上层透明，开发者只需写 try (Connection conn = ds.getConnection()) { ... } 即可。
手动归还 vs try-with-resources：推荐后者
错误做法（易遗漏、难维护）：
Connection conn = null;
try {
conn = ds.getConnection();
// do something
} finally {
if (conn != null) conn.close(); // 容易忘记或抛 NPE
}
正确做法（简洁、安全、符合语义）：
try (Connection conn = ds.getConnection();
PreparedStatement ps = conn.prepareStatement("...")) {
// 自动 close()，归还连接和语句
}
注意：只要连接来自连接池数据源（DataSource），且未调用 unwrap() 获取原始物理连接，这里的 close() 就是归还，不是销毁。
特殊情况：需要强制物理关闭怎么办？
极少数场景（如连接损坏、怀疑泄露、测试清理），可绕过池子直接关底层连接：
- HikariCP：调用
conn.unwrap(com.zaxxer.hikari.pool.HikariProxyConnection.class).getRawConnection().close()（不推荐生产使用）； - 通用方式：检查连接是否为池代理（
conn.getClass().getName().contains("Proxy")），再尝试unwrap()； - 更稳妥的做法是配置连接池的健康检测与泄露检测（如
leakDetectionThreshold），让池子主动处理异常连接。
