记一次 Druid 超时配置的问题 → 引发对 Druid 时间配置项的探究原创
问题背景
最近生产环境出现了一个问题，错误日志类似如下
Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 1010, active 10, maxActive 10, creating 0, runningSqlCount 10 : select * from tbl_user
日志信息提示的很明显：获取 JDBC Connection 失败，因为从 druid 连接池获取 connection 超时了
上图的意思是：执行 select * from tbl_user 之前，需要从 druid 连接池中获取一个 connect
而此时连接池的状态是：一共 10 个激活的 connect ，连接池最大创建 10 个 connect ，正在执行 sql 的 connect 也是 10 个
所以不能创建新的 connect ，那就等呗，一共等了 1010 毫秒，还是拿不到 connect ，就抛出 GetConnectionTimeoutException 异常
简单点说就是是连接池中连接数不够，在规定的时间内拿不到 connect
那有人就说了：连接池的最大数量设置大一点，问题不就解决了吗？
最大连接数设置大一点只能说可以降低问题发生的概率，不能完全杜绝，因为网络情况、硬件资源的使用情况等等都是不稳定因素
今天要讲的不是连接池大小问题，而是超时设置问题，我们慢慢往下看
问题复现
我们先来模拟下上述问题
MySQL 版本： 5.7.21 ，隔离级别：RR
Druid 版本： 1.1.12
spring-jdbc 版本： 5.2.3.RELEASE
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 配置。
