druid-1.0.29数据源导致报错“connect holder is null”

1. 首先这个报错是因为应用的数据库连接长时间空闲，导致数据库把连接断掉了，但是应用的连接池认为该连接仍然有效，所以继续使用该连接时就会拿不到connect，就会报“connect holder is null”的错误
2. 由于我们公司的mysql数据库的wait_timeout设置的时间比较短，所以当应用数据量上去的时候，也会出现“connect holder is null”的错误
3. 综上所述：有两个原因：1）druid数据源配置的有问题；2）wait_timeout时间太短
4. druid-1.0.29数据源的问题：

• 数据源本身的Bug
• 数据源配置：

• #初始化大小，最小，最大
        initialSize: 5
        minIdle: 5
        maxActive: 300
        #配置获取连接等待超时的时间
        maxWait: 60000
        #配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒
        timeBetweenEvictionRunsMillis: 60000
        #配置一个连接在池中最小生存的时间，单位是毫秒
        minEvictableIdleTimeMillis: 300000
        validationQuery: SELECT 1 FROM DUAL
        testWhileIdle: true
        testOnBorrow: true
        testOnReturn: false
        #打开PSCache，并且指定每个连接上PSCache的大小
        poolPreparedStatements: true
        maxPoolPreparedStatementPerConnectionSize: 20
        #配置监控统计拦截的filters，去掉后监控界面sql无法统计，'wall'用于防火墙
        filters: stat,wall,slf4j
        #通过connectProperties属性来打开mergeSql功能；慢SQL记录
        connectionProperties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=3000
        #合并多个DruidDataSource的监控数据
        #useGlobalDataSourceStat: true
        isRemoveAbandoned: true
        removeAbandonedTimeOut: 1800

  其中几个重要的参数：

• testOnBorrow：指明是否在从池中取出连接前进行检验,如果检验失败,则从池中去除连接并尝试取出另一个。druid官方文档推荐为false，生产环境一般都为false，主要是考虑到性能问题，开启后druid会去检查连接的可用性，非常耗性能

• testWhileIdle：作用是连接是否被空闲连接回收器(如果有)进行检验.如果检测失败,则连接将被从池中去除。1.0.29的版本中这个参数不起作用，也是导致“ connect holder is null”报错的重要原因，只能升级到最新版

• removeAbandoned：标记是否删除泄露的连接,如果他们超过了removeAbandonedTimout的限制。如果设置为true, 连接被认为是被泄露并且可以被删除。如果空闲时间超过removeAbandonedTimeout，设置为true可以为写法糟糕的没有关闭连接的程序修复数据库连接

• removeAbandonedTimeout：泄露的连接可以被删除的超时值, 单位秒