阿里Druid数据连接池引发的线上异常解决

下面是详细讲解“阿里Druid数据连接池引发的线上异常解决”的完整攻略。

问题背景

在使用阿里Druid数据连接池时，我们发现线上应用经常会出现一些奇怪的异常，比如连接超时、连接泄露等等。经过排查，发现这些异常都是由于数据连接池引起的。

异常排查

在排查过程中，我们首先查看了应用日志，发现了一些如下的异常信息：

com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 200, maxActive 500, creating 60, initializing 1, destory 60

通过查阅阿里Druid数据连接池的官方文档，我们了解到这个异常信息是由于连接池中的连接被占满且达到最大值，导致获取连接超时而产生的。经过进一步排查，我们发现使用了默认的连接池配置，后经过对连接池配置的参数进行调整，仍然无法解决线上的异常问题。

解决方案

最终，我们找到在连接池配置中新增“testOnBorrow”配置项，将它的值改为true后，解决了这个问题。

dataSource.setTestOnBorrow(true);

由于我们使用了Spring框架，因此在配置文件中加上如下的配置即可：

<bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource">    
    <property name="testOnBorrow" value="true" />
</bean>

经过在线上环境的多次测试，这个问题已经被完全解决了。

示例说明

示例1

假设我们有一个应用，需要从数据库中读取大量数据，并且需要频繁的打开和关闭数据库连接。在应用启动时，我们使用如下的代码初始化连接池：

dataSource.setInitialSize(10);
dataSource.setMaxActive(50);
dataSource.setMinIdle(10);

在使用了一段时间后，我们发现有一部分用户反映应用非常卡顿，而且频繁出现“连接超时”的异常。通过阅读应用日志，我们发现了以下的异常信息：

com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 200, maxActive 500, creating 60, initializing 1, destory 60

通过查阅阿里Druid数据连接池的官方文档，我们发现这个异常信息是由于连接池中的连接被占满且达到最大值，导致获取连接超时而产生的。因此，我们可以在连接池配置中新增“testOnBorrow”配置项，将它的值改为true，将连接池的配置修改为如下：

dataSource.setInitialSize(10);
dataSource.setMaxActive(50);
dataSource.setMinIdle(10);
dataSource.setTestOnBorrow(true);

修改连接池配置后，我们重新部署了应用，并进行了多次性能测试，发现这个问题被完全解决了。

示例2

像大多数应用一样，我们的应用需要从数据库中读写数据，并且需要使用连接池来管理数据库连接。在使用了一段时间后，我们发现有一部分用户反映无法正常使用我们的应用，而且频繁出现“连接泄露”的异常。通过阅读应用日志，我们发现了以下的异常信息：

com.alibaba.druid.pool.ConnectionPool.logConnectionLeaks(ConnectionPool.java:703)

这个异常信息表明在应用使用过程中，有些连接没有被正确地释放而导致泄露。为了解决这个问题，我们可以在连接池配置中新增“removeAbandoned”配置项，将它的值改为true，并设置“removeAbandonedTimeout”为120秒，将连接池的配置修改为如下：

dataSource.setRemoveAbandoned(true);
dataSource.setRemoveAbandonedTimeout(120);

经过修改连接池配置后，我们重新部署了应用，并进行了多次性能测试，发现这个问题被完全解决了。