异常浅析"/>
durid连接池异常浅析
异常背景
connection holder is null
- 第一次发生是在圣诞节加班冒烟自测需求时曾发生过该异常，当时排查过可能是由于某个地方事务过长造成的，恰好我又在冒烟新增的接口，就去看了一遍，发现确实方法链路较长，且整个接口都处于事务中，我便将需要事务的逻辑单独抽出，重新测了一遍，发现该异常没有发生了。便不了了之。
- 第二次是在上线当天，测试环境出现大量异常，并导致接口成功率降至30％，排查无果，最后觉得是自动化测试调用频繁的原因，解决后便没有出现异常，开始上线。
- 由于上线当天出现了其他的bug，注意力全部都集中在bug排查修复上，凌晨四点半又开始发生异常，便开始重新review此次版本新增代码，发现了XX编辑接口，手动开启事务后紧接着抛出异常，觉得可能是该原因，不过该接口只调用了一次，想不通为什么会造成几十几百次异常。
- 在测试环境重复点击该异常（由于点击频率过高，200个事务堵塞了200条tomcat线程，服务器直接503）
- 排查进度缓慢，也快6点，客户也快要上班了，便先回滚代码，后续再说，先初步怀疑是这个XX编辑手动开启事务的坑。
异常特点
- 隐蔽性强
- 触发点不明确
- 复现难度高
初步分析
看看本次异常先是由哪里抛出
DruidPooledConnection是一个静态代理，持有ConnectionHolder, connection Holder里持有具体的connection对象， 可以看到在数据源连接在执行druidPooledConnection的所有和数据库相关方法时，都会先调用checkState()判断connection holder是否为null，如果是null就抛connection holder is null的异常。
holder是怎么被置为null的？
走一遍durid连接池源码就清楚了
深度分析
druid连接池源码追踪
先看看druid连接池各个参数代表的意思
druid连接池参数
| 配置 | 说明 |
|---|---|
| initialSize | 初始化时建立物理连接的个数。初始化发生在显示调用init方法，或者第一次getConnection时 |
| maxActive | 最大连接池数量 |
| minIdle | 最小连接池数量 |
| maxWait | 获取连接时最大等待时间，单位毫秒。配置了maxWait之后，缺省启用公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使用非公平锁。 |
| removeAbandoned | 开启线程持有连接超时移除 |
| removeAbandonedTimeout | 线程持有连接超过多长时间将会移除，默认300000，5分钟 |
| poolPreparedStatements | 是否缓存preparedStatement，也就是PSCache。PSCache对支持游标的数据库性能提升巨大，比如说oracle。在mysql下建议关闭。 |
| maxOpenPreparedStatements | 要启用PSCache，必须配置大于0，当大于0时，poolPreparedStatements自动触发修改为true。在Druid中，不会存在Oracle下PSCache占用内存过多的问题，可以把这个数值配置大一些，比如说100 |
| validationQuery | 用来检测连接是否有效的sql，要求是一个查询语句。如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会其作用。 |
| testOnBorrow | 申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。 |
| testOnReturn | 归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能 |
| testWhileIdle | 建议配置为true，不影响性能，并且保证安全性。申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。 |
| timeBetweenEvictionRunsMillis | 有两个含义：1) Destroy线程会检测连接的间隔时间2) testWhileIdle的判断依据，详细看testWhileIdle属性的说明 |
| connectionInitSqls | 物理连接初始化的时候执行的sql |
| exceptionSorter | 当数据库抛出一些不可恢复的异常时，抛弃连接 |
| filters | 属性类型是字符串，通过别名的方式配置扩展插件，常用的插件有：监控统计用的filter:stat日志用的filter:log4j防御sql注入的filter:wall |
| proxyFilters | 类型是List<com.alibaba.druid.filter.Filter>，如果同时配置了filters和proxyFilters，是组合关系，并非替换关系 |
看完参数配置详解后，注意两个参数removeAbandoned和removeAbandonedTimeout，没错，这就是与这次异常息息相关的参数配置。
本次引发异常的configuration服务，removeAbandoned参数为true，removeAbandonedTimeout未配置（不清楚未配置原因），不配置默认五分钟超时
先进入连接池的初始化方法
只看主要逻辑即可
连接池的初始化方法
/** 连接池初始化 */public void init() throws SQLException {/** 如果已经初始化直接返回 */if (inited) {return;}final ReentrantLock lock = this.lock;try {/*** 加锁处理 */lock.lockInterruptibly();} catch (InterruptedException e) {throw new SQLException("interrupt", e);}try {/** 1.创建数据源ID */this.id = DruidDriver.createDataSourceId();/** 2.初始化过滤器 */for (Filter filter : filters) {filter.init(this);}/*** 省略* 3.maxActive、maxAc更多推荐
durid连接池异常浅析
发布评论