连接池对象本身不被GC回收，真正导致内存泄漏的是未归还的数据库连接及其强引用链上的资源；需检查静态变量、ThreadLocal、AOP切面等不当持有Connection的场景，并通过堆转储和监控指标定位与修复。
连接池对象本身不是垃圾回收的直接目标，真正导致 GC 无法释放内存的，是本该归还却未归还的数据库连接，以及它所携带的强引用链上的资源对象
确认连接是否真实“泄露”而非仅被误捕获
所谓“不当捕获”，常见于代码中把 Connection 对象赋值给静态变量、缓存容器、线程局部变量（ThreadLocal）或长期存活的 Bean 属性，造成连接无法随业务逻辑结束而释放。这种引用会阻止连接对象进入可回收状态，进而拖住其关联的网络缓冲区、语句集、结果集等堆外/堆内资源。
- 检查所有
static Connection、static DataSource或@Component类中持有Connection字段的用法——连接池对象（如HikariDataSource）可长期存在，但具体Connection实例绝不能跨请求生命周期保存 - 搜索项目中
ThreadLocal<Connection>的使用，尤其注意未在finally块中调用remove()的场景 - 排查 AOP 切面、过滤器、拦截器里是否意外将
Connection存入 request attribute 或上下文容器且未清理
通过堆转储定位强引用路径
当应用出现 GC 频繁、老年代持续增长、Full GC 后内存回落极少时，说明有大量连接对象滞留。此时应触发堆转储（jmap -dump:format=b,file=heap.hprof <pid>），用 MAT（Memory Analyzer Tool）分析：
- 打开
Leak Suspects Report，重点关注com.mysql.cj.jdbc.ConnectionImpl或对应驱动类的实例数量 - 对任一连接对象右键 →
Path to GC Roots → exclude weak/soft references，查看谁在强引用它 - 典型泄漏路径包括：
java.lang.ThreadLocal$ThreadLocalMap → static MyUtils.connectionHolder → ConnectionImpl，或org.springframework.web.context.request.RequestContextHolder → RequestAttributes → Connection
验证连接池实际使用状态
光看代码不够，需结合运行时指标交叉验证：
- 启用连接池监控端点（如 HikariCP 的
/actuator/metrics/hikaricp.connections.active），观察活跃连接数是否随请求量线性上升后不回落 - 检查日志中是否有
Connection has been abandoned、Connection marked as broken等警告，这是连接未关闭的明确信号 - 开启 JDBC 连接代理（如
jdbc:log4jdbc:mysql://...或spring.datasource.hikari.data-source-properties.cachePrepStmts=true），追踪getConnection与close是否成对出现
修复与防护措施
修复核心是切断非必要强引用，同时建立防御性机制：
- 所有获取连接的代码必须使用
try-with-resources（JDBC 4.1+）或try-finally显式关闭，禁止依赖finalize或连接池自动回收 - 禁用全局
ThreadLocal<Connection>，改用 Spring 的TransactionSynchronizationManager管理事务绑定连接 - 在连接池配置中启用强制回收：HikariCP 设置
leak-detection-threshold=60000（毫秒），超时未归还将打印堆栈；Druid 设置removeAbandonedOnBorrow=true - 上线前增加单元测试：模拟高并发下连接获取/释放流程，用
Mockito验证close()调用次数
