DBCP连接池无应用活动时活跃连接未归零问题咨询

我之前帮团队排查过几乎一模一样的问题，大概率是连接泄漏或者配置踩了坑导致的，咱们一步步拆解：

最常见的原因：连接没被正确关闭 #

虽然你说应用没活动，但很可能某些初始化逻辑、之前的请求或者后台定时任务，获取了数据库连接后没调用close()归还。DBCP的连接计数很直白——只要连接没被调用close()（或者通过try-with-resources自动关闭），连接池就会一直把它标记为「活跃」状态。

怎么排查？ #

• 先给DBCP开个「泄漏追踪」：在配置里加上这几个参数：

  logAbandoned=true
  removeAbandoned=true
  removeAbandonedTimeout=300
  

  开启后，DBCP会把泄漏连接的调用栈打印到日志里，还会在超时后自动回收这些连接，帮你快速定位哪段代码没关连接。
• 检查所有获取连接的代码，强制用try-with-resources——这是避免手动遗漏关闭的最佳实践：

  try (Connection conn = dataSource.getConnection()) {
      // 你的数据库操作逻辑
  } catch (SQLException e) {
      // 异常处理
  }
  

  这种写法会在代码块结束时自动关闭连接，不管有没有抛出异常。

其他可能的原因 #

1. 第三方组件「私藏」了连接 #

如果你的应用用了ORM框架（比如Hibernate）、定时任务（比如Quartz）或者其他依赖数据库的组件，要排查这些组件是否正确释放了连接：

• 比如Hibernate的Session没关闭，底层的Connection就不会归还到池里；
• 定时任务中途挂了，获取的连接没机会执行关闭逻辑；
• 线程池里的长期线程持有连接，线程不销毁，连接就一直占着。

2. 连接池配置的坑 #

如果你的配置里initialSize=16、maxActive=16，同时minIdle=16，那连接池启动时会一次性创建16个连接，但正常情况下这些连接应该是「空闲」状态（NumIdle=16，NumActive=0）。如果你的NumActive一直是16，说明这些连接全被借出去没还，还是回到了连接泄漏的问题。

另外，如果testWhileIdle=false，数据库端主动关闭了连接，但连接池没检测到，也可能导致计数异常，但这种情况NumActive一般不会固定在16。

3. DBCP版本bug #

老版本的DBCP（比如1.2.x之前）确实存在过连接计数不准的bug。如果你的版本比较旧，可以试试升级到稳定的新版本（比如2.9.0），说不定问题直接解决。

快速解决步骤总结 #

1. 先开泄漏日志定位问题代码；
2. 把所有获取连接的代码改成try-with-resources；
3. 临时开启removeAbandoned参数回收泄漏的连接，保证应用正常运行；
4. 排查第三方组件的连接使用逻辑；
5. 升级DBCP版本试试（如果是旧版本）。

内容的提问来源于stack exchange，提问作者NaiveCoder