使用c3p0连接池出现BasicResourcePool资源获取超时问题求助

我们使用C3P0作为数据库连接池，遇到了连接获取超时问题：程序尝试从连接池获取连接，但在checkoutTimeout设置的5秒后超时。日志显示连接池管理的连接数为45，其中空闲连接数为0，但实际存在200多个空闲连接。

相关日志信息 #

2023-10-25T12:55:34.162 [INFO] thread:[pool-9-thread-7]
[ApplicationVersion:[83.0.4-4021]
DiagnosticKey:[e4b904f6-a77c-4001-93ac-cf562153faf3] ReferenceCode:[]
ClientMachine:[127.0.0.1] RemoteIp:[] RemotePort:[]]
c.t.s.e.TransactionExecutorThreadingManager.run@53: 新线程从以下标识创建：5a62c616-df3f-4b9d-99b4-74a70edf5d49，新线程信息：pool-9-thread-7, 184

2023-10-25T12:55:34.174 [DEBUG]
thread:[pool-9-thread-7] [ApplicationVersion:[83.0.4-4021]
DiagnosticKey:[e4b904f6-a77c-4001-93ac-cf562153faf3] ReferenceCode:[]
ClientMachine:[127.0.0.1] RemoteIp:[] RemotePort:[]]
o.s.orm.jpa.JpaTransactionManager.getTransaction@366: 创建名称为[ExternalTransaction]的新事务：PROPAGATION_REQUIRES_NEW,ISOLATION_DEFAULT

2023-10-25T12:55:36.482 [TRACE] thread:[pool-9-thread-7]
[ApplicationVersion:[83.0.4-4021]
DiagnosticKey:[e4b904f6-a77c-4001-93ac-cf562153faf3] ReferenceCode:[]
ClientMachine:[127.0.0.1] RemoteIp:[] RemotePort:[]]
c.m.v2.resourcepool.BasicResourcePool.log@187: trace
com.mchange.v2.resourcepool.BasicResourcePool@227dcf [managed: 45, unused: 0, excluded: 0] (例如：com.mchange.v2.c3p0.impl.NewPooledConnection@5cbc0787)

2023-10-25T12:55:41.551 [DEBUG] thread:[pool-9-thread-7]
[ApplicationVersion:[83.0.4-4021]
DiagnosticKey:[e4b904f6-a77c-4001-93ac-cf562153faf3] ReferenceCode:[]
ClientMachine:[127.0.0.1] RemoteIp:[] RemotePort:[]]
com.mchange.v2.sql.SqlUtils.log@198: 将Throwable转换为SQLException... com.mchange.v2.resourcepool.TimeoutException: 客户端等待从com.mchange.v2.resourcepool.BasicResourcePool@227dcf获取资源时超时 -- 在awaitAvailable()处超时
at com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1461)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:639)
at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:674)
...

可能原因及解决方案 #

可能原因 #

1. 连接泄漏：代码中存在连接未正确释放的情况，比如获取连接后未在finally块中关闭，或者事务未正确提交/回滚，导致连接被长期占用。
2. 连接池配置不合理：
   • maxPoolSize设置过小，无法支撑并发请求；
   • 未启用连接有效性检测，导致空闲连接实际已失效，无法被复用；
3. 线程池与连接池不匹配：业务线程池的线程数远大于连接池最大连接数，大量线程阻塞等待连接。
4. 数据库端限制：数据库的max_connections参数设置小于连接池的maxPoolSize，导致连接池无法创建足够的连接。

解决方案 #

1. 排查连接泄漏：
   • 开启C3P0的连接泄漏检测：配置unreturnedConnectionTimeout（设置未归还连接的超时时间）和debugUnreturnedConnectionStackTraces=true，定位未释放连接的代码位置；
   • 检查代码逻辑，确保所有数据库连接、事务操作都在finally块中完成释放，事务正确提交或回滚。
2. 调整连接池配置：
   • 根据业务并发量调整maxPoolSize，确保其不超过数据库的max_connections限制；
   • 启用连接有效性检测：可设置testConnectionOnCheckin=true（归还连接时检测）或idleConnectionTestPeriod（定期检测空闲连接），避免无效连接占用池资源；
   • 若为临时高峰导致超时，可适当延长checkoutTimeout，但不建议作为长期解决方案。
3. 匹配线程池与连接池配置：调整业务线程池的核心线程数和最大线程数，使其与连接池的maxPoolSize匹配，减少线程等待连接的情况。
4. 检查数据库配置：查看数据库的max_connections参数，确保其值大于等于连接池的maxPoolSize，必要时联系DBA调整。

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