Java连接池Connection未归还本质是应用层未正确释放资源，需通过监控指标、泄漏检测、JDBC代理及JVM工具定位未close的getConnection调用，并强制使用try-with-resources或模板封装预防。
Java 中连接池中 Connection 归还未关闭，本质是 应用层未正确释放资源，而非连接池本身“漏关”。排查关键在于：定位哪段代码获取了 Connection 却没调用 close()，尤其在异常分支、提前 return、循环或异步逻辑中容易遗漏。
确认是否真有连接未归还
先验证问题存在，避免误判：
- 查看连接池监控指标（如 HikariCP 的
active、idle、total；Druid 的「活动连接数」和「等待线程数」），持续增长且不回落，或出现Connection is not available, request timed out报错，是典型信号 - 开启连接池的泄漏检测（如 HikariCP 设置
leakDetectionThreshold=60000，单位毫秒），它会在 Connection 被借用超过阈值后自动打印堆栈，直接指出哪里 get 但没 close - Druid 可开启
removeAbandonedOnBorrow=true+removeAbandonedTimeout=1800（秒），并配合logAbandoned=true记录被强制回收的连接调用栈
检查代码中 Connection 的使用模式
90% 的问题出在手动管理 Connection 的老式写法中：
-
缺失 try-with-resources 或 finally 块：直接
conn = dataSource.getConnection(); ... conn.close();是高危写法，一旦中间抛异常，close()就跳过了 - 在 if/else 或多个 return 分支中遗漏 close：例如查询为空时 return，但前面已获取 Connection 却没关
- 将 Connection 作为方法参数传递后，在调用方关闭，但被调用方又用了它并没再传回：责任边界模糊，极易漏关
-
在 Stream 或 Lambda 中使用 Connection 但未确保其关闭：比如
list.parallelStream().forEach(...)内部打开了 Connection，却没在该作用域内关闭
用工具辅助定位泄漏点
光靠日志和经验不够，需结合技术手段：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
启用 JDBC 代理（如 p6spy）：记录所有
getConnection()和close()调用，比对调用次数是否匹配，并关联线程 ID 和堆栈 -
使用 JVM 诊断工具抓取堆内存中的 Connection 实例：用
jmap -histo:live <pid>查看HikariProxyConnection或DruidPooledConnection实例数是否异常增多；再用jstack <pid>找到持有这些对象的线程，结合代码分析 -
在测试环境复现 + IDE 断点追踪：在
dataSource.getConnection()和connection.close()处加条件断点（如按线程名或 SQL 关键字过滤），观察哪些 getConnection 缺少对应 close
预防胜于修复：统一资源管理规范
从工程层面降低风险：
- 强制使用 try-with-resources：Connection、Statement、ResultSet 全部纳入，JVM 保证异常下也关闭
- 封装 DAO 层，让模板方法（如 Spring JdbcTemplate、MyBatis SqlSessionTemplate）接管 Connection 生命周期，业务代码不直连 DataSource
- 禁用
Connection.close()的原始语义（HikariCP 默认已重写为归还，但语义上仍建议保留 close 调用），避免开发者误以为“关了就真销毁” - 在 CI 阶段加入静态扫描（如 SonarQube 规则 “Resources should be closed”），拦截未关闭资源的代码合入
不复杂但容易忽略——核心就是盯住每一条 getConnection 调用，确保它落在 try-with-resources 里，或有明确、无分支遗漏的 finally close。泄漏检测开关和堆栈日志，是你的第一双眼睛。
