记一次 Druid 超时配置的问题 → 引发对 Druid 时间配置项的探究

link之家

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

DruidDataSource 初始化

为了方便演示，就手动初始化了

多线程查询

线程数多于连接池中 connect 数

模拟慢查询

如果查询飞快，15 个查询，可能都用不上 10 个 connect ，所以我们需要简单处理下

很简单，给表加写锁呗： LOCK TABLES tbl_user WRITE

给表 tbl_user 加上写锁，然后跑线程去查询 tbl_user 的数据

先锁表，再启动程序

可以看到，15 个线程中，有 5 个线程获取 connect 失败

Thread-13 Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 10004, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user
Thread-5 Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 10004, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user
Thread-10 Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 10004, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user
Thread-7 Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 10004, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user
Thread-8 Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 10004, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user

示例代码： druid-timeout

时间配置项

Druid 中关于时间的配置项有很多，我们我们重点来看下如下几个

maxWait

最大等待时长，单位是毫秒，-1 表示无限制

从连接池获取 connect ，如果有空闲的 connect ，则直接获取到，如果没有则最长等待 maxWait 毫秒，如果还获取不到，则抛出 GetConnectionTimeoutException 异常

removeAbandonedTimeout

设置 druid 强制回收连接的时限，单位是秒

从连接池获取到 connect 开始算起，超过此值后， Druid 将强制回收该连接

官网也有说明：连接泄漏监测

validationQueryTimeout

检测连接是否有效的超时时间，单位是秒，-1 表示无限制

Druid 内部的一个检测 connect 是否有效的超时时间，需要结合 validationQuery 来配置

timeBetweenEvictionRunsMillis

检查空闲连接的频率，单位是毫秒, 非正整数表示不进行检查

空闲连接检查的间隔时间， Druid 池中的 connect 数量是一个动态从 minIdle 到 maxActive 扩张与收缩的过程

connect 使用高峰期，数量会从 minIdle 扩张到 maxActive ，使用低峰期， connect 数量会从 maxActive 收缩到 minIdle

收缩的过程会回收一些空闲的 connect ，而 timeBetweenEvictionRunsMillis 就是检查空闲连接的间隔时间

queryTimeout

执行查询的超时时间，单位是秒，-1 表示无限制

最终会应用到 Statement 对象上，执行时如果超过此时间，则抛出 SQLException

transactionQueryTimeout

执行一个事务的超时时间，单位是秒

minEvictableIdleTimeMillis

最小空闲时间，单位是毫秒，默认 30 分钟

如果连接池中非运行中的连接数大于 minIdle ，并且某些连接的非运行时间大于 minEvictableIdleTimeMillis ，则连接池会将这部分连接设置成 Idle 状态并关闭

maxEvictableIdleTimeMillis

最大空闲时间，单位是毫秒，默认 7 小时

如果 minIdle 设置的比较大，连接池中的空闲连接数一直没有超过 minIdle ，那么那些空闲连接是不是一直不用关闭？

当然不是，如果连接太久没用，数据库也会把它关闭（MySQL 默认 8 小时），这时如果连接池不把这条连接关闭，程序就会拿到一条已经被数据库关闭的连接

为了避免这种情况， Druid 会判断池中的连接，如果非运行时间大于 maxEvictableIdleTimeMillis ，也会强行把它关闭，而不用判断空闲连接数是否小于 minIdle

其实前面的示例中设置了

获取 connect 的最大等待时长是 10000 毫秒，也就是 10 秒

而 removeAbandonedTimeout 设置是 7 秒

照理来说 connect 如果 7 秒未执行完 SQL 查询，就会被 Druid 强制回收进连接池，那么等待 10 秒应该能够获取到 connect ，为什么会抛出 GetConnectionTimeoutException 异常了？

这也就是文章标题中的超时设置问题

很显然，我们从 dataSource.init(); 开始跟源码

会看到如下一块代码

我们继续跟 createAndStartDestroyThread();

重点来了，我们看下 DestroyTask 到底是怎么样一个逻辑

我们接着跟进 removeAbandoned ，关键代码

如果 connect 正在运行中是不会被强制回收进连接池的

回到我们的示例， connect 都是在运行中，只是都在进行慢查询，所以是无法被强制回收进连接池的，那么其他线程自然在 maxWait 时间内无法获取到 connect

至此文章标题中的问题的原因就找到了

那么问题又来了： removeAbandonedTimeout 作用在哪？

我们再仔细阅读下：连接泄漏监测

Druid 提供了 RemoveAbandanded 相关配置，目的是监测连接泄露，回收那些长时间游离在连接池之外的空闲 connect

可能因为程序问题，导致申请的 connect 在处理完 sql 查询后，不能回到连接池的怀抱，那么这个 connect 处理游离态，它真实存在，但后续谁也申请不到它，这就是连接泄露

而 removeAbandoned 的设计就是为了帮助这些泄露的 connect 回到连接池的怀抱

开启 removeAbandoned 对性能有影响，官方不建议在生产环境使用

那么我们接受官方的建议，不开启 removeAbandoned （不配置即可，默认是关闭的）

为了不让慢查询占用整个连接池，而拖垮整个应用，我们设置查询超时时间 queryTimeout

有两种方式，一个是设置 DataSource 的 queryTimeout ，另一个是设置 JdbcTemplate 的 queryTimeout

如果两个都设置，最终生效的是哪个，为什么？大家自己去分析，权当是给大家留个一个作业

这里就配置 DataSource 的 queryTimeout ，给大家演示下效果

可以看到，所有线程都获取到了 connect

1、 Druid 的 removeAbandoned 对性能有影响，不建议开启

removeAbandoned 的开启后的作用要捋清楚，而非简单的过期强制回收

2、 Druid 的时间配置项有很多，不局限于文中所讲，但常用的就那么几个，其他的保持默认值就好

配置的时候一定要弄清楚各个配置项的具体作业，不要去猜！

3、查询超时 queryTimeout 即可在 DataSource 配置，也可在 JdbcTemplate 配置