开心一刻

  一天在路边看到一个街头采访

  记者:请问,假如你儿子娶媳妇,给多少彩礼合适呢

  大爷:一百万吧,再给一套房,一辆车

  大爷沉思一下,继续说到:如果有能力的话再给老丈人配一辆车,毕竟他把女儿养这么大也不容易

  记者:那你儿子多大了?

  大爷:我没有儿子,有两个女儿

记一次 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

  

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

select * from tbl_user 之前,需要从 druid 连接池中获取一个 connect

connect ,连接池最大创建 10 个 connect ,正在执行 sql 的 connect

connect ,那就等呗,一共等了 1010 毫秒,还是拿不到 connect ,就抛出 GetConnectionTimeoutException

connect

  那有人就说了:连接池的最大数量设置大一点,问题不就解决了吗

  最大连接数设置大一点只能说可以降低问题发生的概率,不能完全杜绝,因为网络情况、硬件资源的使用情况等等都是不稳定因素

  今天要讲的不是连接池大小问题,而是超时设置问题,我们慢慢往下看

问题复现

  我们先来模拟下上述问题

MySQL 版本: 5.7.21

Druid 版本: 1.1.12

spring-jdbc 版本: 5.2.3.RELEASE

  DruidDataSource 初始化

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

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

  多线程查询

connect

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

  模拟慢查询

connect

LOCK TABLES tbl_user WRITE

tbl_user 加上写锁,然后跑线程去查询 tbl_user

  异常演示

  先锁表,再启动程序

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

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

再看问题

  其实前面的示例中设置了

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

connect 的最大等待时长是 10000 毫秒,也就是 10

removeAbandonedTimeout

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

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

源码探究

dataSource.init();

  会看到如下一块代码

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

createAndStartDestroyThread();

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

DestroyTask

记一次 Druid 超时配置的问题 → 引发对 Druid 时间配置项的探究_连接池_09

removeAbandoned

记一次 Druid 超时配置的问题 → 引发对 Druid 时间配置项的探究_连接池_10

connect

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

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

removeAbandonedTimeout

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

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

connect 在处理完 sql 查询后,不能回到连接池的怀抱,那么这个 connect

removeAbandoned 的设计就是为了帮助这些泄露的 connect

解决问题

removeAbandoned

removeAbandoned

queryTimeout

DataSource 的 queryTimeout ,另一个是设置 JdbcTemplate 的 queryTimeout

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

DataSource 的 queryTimeout

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

connect

总结

Druid 的 removeAbandoned

removeAbandoned

Druid

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

queryTimeout 即可在 DataSource 配置,也可在 JdbcTemplate