记一次DBCP2连接不回收,程序卡死,分析过程

最新推荐文章于 2023-04-26 10:17:02 发布

原创最新推荐文章于 2023-04-26 10:17:02 发布 · 1k 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

本文为博主原创文章，未经博主允许不得转载。

java相关同时被 2 个专栏收录

16 篇文章

订阅专栏

性能

4 篇文章

订阅专栏

本文分享了一次在新公司优化代码、提升效率的经历。通过重构使用DruidDataSource封装的DB查询SDK，作者发现多线程并发下程序卡死的问题，并深入分析了原因，最终通过调整BasicDataSource参数解决了连接池并发瓶颈。

最近刚换了新公司,想去优化一下之前的代码,提高一下任务执行效率,review了一下之前的代码,可以优化的地方挺多的,公司有一个查询db的sdk,被之前的同事用druid datasource 封装了一下, 看了一下sdk的实现,本身是有pooling的支持的,那么我就大刀阔斧的进行了代码的重构,本着有现成的就不过多的扩展(之前的代码实现的也不是太好,fork了堆无用的类,只为了封装druid)。
经过一顿修改之后打包测试,简单的sql可以,但是如果多线程并发下,会出现
程序卡死的情况,执行了一下jstack

jstack -l $PID

看了一下堆栈,发现程序卡在了其中一个countdownLatch的await()处,那么在分析,是上面那些操作没有执行完么,又看了一下日志,程序有25个线程都卡在了_pool.borrowObject()处,连接拿完了？猜测有两种原因

慢查询,没有返回结果 (show processList以后发现没有慢查询占用)
连接池用完没有回收
后来查了一下BasicDataSource默认参数是没有开启超时回收的,那么肯定就有问题了,后来加了一下,下面的参数顺利运行

BasicDataSource dataSource = (BasicDataSource)dataSource(jdbcParamsState);
dataSource.setInitialSize(10);
dataSource.setMinIdle(10);
dataSource.setMaxIdle(100);
dataSource.setMaxTotal(120);
dataSource.setMaxWaitMillis(30 * 1000); //关键