零、类图 & 流程预览
本文会通过 getConnection 作为入口，摸索在 druid 里，一个连贯的生命周期。大体流程被划分成了以下几个主流程：
主流程 1：获取连贯流程
首先从入口来看看它在获取连贯时做了哪些操作：点击返回原文
上述为获取连贯时的流程图，首先会调用 init 进行连接池的初始化，而后运行责任链上的每一个 filter，最终执行getConnectionDirect 获取真正的连贯对象，如果开启了 testOnBorrow，则每次都会去测试连贯是否可用（这也是官网不倡议设置testOnBorrow 为true的起因，影响性能，这里的测试是指测试 mysql 服务端的长连贯是否断开，个别 mysql 服务端长连保活工夫是8h，被应用一次则刷新一次应用工夫，若一个连贯间隔上次被应用超过了保活工夫，那么再次应用时将无奈与 mysql 服务端通信）。
如果 testOnBorrow 没有被置为 true，则会进行 testWhileIdle 的查看（这一项官网倡议设置为 true，缺省值也是 true），查看时会判断以后连贯对象间隔上次被应用的工夫是否超过规定查看的工夫，若超过，则进行查看一次，这个查看工夫通过 timeBetweenEvictionRunsMillis 来管制，默认 60s。
每个连贯对象会记录下上次被应用的工夫，用以后工夫减去上一次的应用工夫得出闲置工夫，闲置工夫再跟 timeBetweenEvictionRunsMillis 比拟，超过这个工夫就做一次连贯可用性查看，这个相比 testOnBorrow 每次都查看来说，性能会晋升很多，用的时候无需关注该值，因为缺省值是 true，经测试如果将该值设置为 false，testOnBorrow 也设置为 false，数据库服务端长连保活工夫改为 60s，60s 内不应用连贯，超过 60s 后应用将会报连贯谬误。
若应用 testConnectionInternal 办法测试长连贯后果为 false，则证实该连贯已被服务端断开或者有其余的网络起因导致该连贯不可用，则会触发 discardConnection 进行连贯回收（对应流程 1.4，因为抛弃了一个连贯，因而该办法会唤醒主流程 3 进行查看是否须要新建连贯）。整个流程运行在一个死循环内，直到取到可用连贯或者超过重试下限报错退出（在连贯没有超过连接池下限的话，最多重试一次（重试次数默认重试 1 次，能够通过 notFullTimeoutRetryCount 属性来管制），所以取连贯这里一旦产生期待，在连接池没有满的状况下，最大期待 2 × maxWait 的工夫 ←这个有待验证）。
特地阐明①
为了保障性能，不倡议将 testOnBorrow 设置为 true，或者说牵扯到长连贯可用检测的那几项配置应用 druid 默认的配置就能够保障性能是最好的，如上所说，默认长连贯查看是 60s 一次，所以不启用 testOnBorrow 的状况下要想保障十拿九稳，本人要确认下所连的那个 mysql 服务端的长连贯保活工夫（尽管默认是 8h，然而 dba 可能给测试环境设置的工夫远小于这个工夫，所以如果这个工夫小于 60s，就须要手动设置 timeBetweenEvictionRunsMillis 了，如果 mysql 服务端长连接时间是 8h 或者更长，则用默认值即可。
特地阐明②
为了避免不必要的扩容，在 mysql 服务端长连贯够用的状况下，对于一些 qps 较高的服务、网关业务，倡议把池子的最小闲置连接数 minIdle 和最大连接数 maxActive 设置成一样的，且依照须要调大，且开启 keepAlive 进行连贯活性查看（参考流程 4.1），这样就不会前期产生动静新建连贯的状况（建连还是个比拟重的操作，所以不如一开始就申请好所有须要的连贯，集体意见，仅供参考），然而像治理后盾这种，长期 qps 非常低，然而有的时候须要用治理后盾做一些微小的操作（比方导数据什么的）导致须要的连贯暴增，且治理后盾不会特地要求性能，就适宜将 minIdle 的值设置的比 maxActive 小，这样不会造成不必要的连贯节约，也不会在须要暴增连贯的时候无奈动静扩增连贯。
主流程 2：初始化连接池
通过下面的流程图能够看到，在获取一个连贯的时候首先会查看连接池是否曾经初始化结束（通过 inited 来管制，bool 类型，未初始化为 flase，初始化结束为 true，这个判断过程在 init 办法内实现），若没有初始化，则调用 init 进行初始化（图主流程 1 中的紫色局部），上面来看看 init 办法里又做了哪些操作：
能够看到，实例化的时候会初始化全局的重入锁lock，在初始化过程中包含后续的连接池操作都会利用该锁保障线程平安，初始化连接池的时候首先会进行双重查看是否曾经初始化过，若没有，则进行连接池的初始化，这时候还会通过 SPI 机制额定加载责任链上的 filter。
然而这类 filter 须要在类上加上 @AutoLoad 注解。而后初始化了三个数组，容积都为 maxActive，首先 connections 就是用来寄存池子里连贯对象的，evictConnections 用来寄存每次查看须要摈弃的连贯（联合流程 4.1 了解），keepAliveConnections 用于寄存须要连贯查看的存活连贯（同样联合流程 4.1 了解），而后生成初始化数（initialSize）个连贯，放进 connections，而后生成两个必须的守护线程，用来增加连贯进池以及从池子里摘除不须要的连贯，这俩过程较简单，因而拆出来单说（主流程 3 和主流程 4）。
特地阐明①
从流程上看如果一开始实例化的时候不对连接池进行初始化（这个初始化是指对池子自身的初始化，并非单纯的指 druid 对象属性的初始化），那么在第一次调用 getConnection 时就会走上图那么多逻辑，尤其是耗时较久的建设连贯操作，被反复执行了很屡次，导致第一次 getConnection 时耗时过久，如果你的程序并发量很大，那么第一次获取连贯时就会因为初始化流程而产生排队，所以倡议在实例化连接池后对其进行预热，通过调用 init 办法或者 getConnection 办法都能够。
特地阐明②
在构建全局重入锁的时候，利用 lock 对象生成了俩 Condition，对这俩 Condition 解释如下：
当连接池连贯够用时，利用 empty 阻塞增加连贯的守护线程（主流程 3），当连接池连贯不够用时，获取连贯的那个线程（这里记为业务线程 A）就会阻塞在 notEmpty 上，且唤起阻塞在 empty 上的增加连贯的守护线程，走完增加连贯的流程，走完后会从新唤起阻塞在 notEmpty 上的业务线程 A，业务线程 A 就会持续尝试获取连贯。
三、流程 1.1：责任链
WARN：这块货色联合源码看更容易了解
这里对应流程 1 里获取连贯时须要执行的责任链，每个 DruidAbstractDataSource 里都蕴含 filters 属性，filters 是对 Druid 里 Filters 接口的实现，外面有很多对应着连接池里的映射办法，比方例子中 dataSource 的 getConnection 办法在触发的时候就会利用 FilterChain 把每个 filter 里的 dataSource_getConnection 给执行一遍，这里也要阐明下 FilterChain，通过流程 1.1 能够看进去，datasource 是利用 FilterChain 来触发各个 filter 的执行的，FilterChain 里也有一堆 datasource 里的映射办法，比方上图里的 dataSource_connect，这个办法会把 datasource 里的 filters 全副执行一遍直到 nextFilter 取不到值，才会触发 dataSource.getConnectionDirect，这个联合代码会比拟容易了解。
四、流程 1.2：从池中获取连贯的流程
通过 getConnectionInternal 办法从池子里获取真正的连贯对象，druid 反对两种形式新增连贯，一种是通过开启不同的守护线程通过 await、signal 通信实现（本文启用的形式，也是默认的形式），另一种是间接通过线程池异步新增，这个形式通过在初始化 druid 时传入 asyncInit=true，再把一个线程池对象赋值给 createScheduler，就胜利启用了这种模式，没认真钻研这种形式，所以本文的流程图和代码块都会躲避这个模式。
下面的流程很简略，连贯足够时就间接 poolingCount-1，数组取值，返回，activeCount+1，整体复杂度为 O(1)，要害还是看取不到连贯时的做法，取不到连贯时，druid 会先唤起新增连贯的守护线程新增连贯，而后陷入期待状态，而后唤醒该期待的点有两处，一个是用完了连贯 recycle（主流程 5）进池子后触发，另外一个就是新增连贯的守护线程胜利新增了一个连贯后触发，await 被唤起后持续退出锁竞争，而后往下走如果发现池子里的连接数依然是 0（阐明在唤醒后参加锁竞争里刚被放进来的连贯又被别的线程拿去了），则持续下一次的 await，这里采纳的是 awaitNanos 办法，初始值是 maxWait，而后下次被刷新后就是 maxWait 减去上次阻塞破费的理论工夫，每次 await 的工夫会逐渐缩小，直到归零，整体工夫是约等于 maxWait 的，但理论比 maxActive 要大，因为程序自身存在耗时以及被唤醒后又要参加锁竞争导致也存在肯定的耗时。
如果最终都没方法拿到连贯则返回 null 进来，紧接着触发主流程 1 中的重试逻辑。
druid 如何避免在获取不到连贯时阻塞过多的业务线程？
通过下面的流程图和流程形容，如果十分极其的状况，池子里的连贯齐全不够用时，会阻塞过多的业务线程，甚至会阻塞超过 maxWait 这么久，有没有一种措施是能够在连贯不够用的时候管制阻塞线程的个数，超过这个限度后间接报错，而不是陷入期待呢？
druid 其实反对这种策略的，在 maxWaitThreadCount 属性为默认值（-1）的状况下不启用，如果 maxWaitThreadCount 配置大于 0，示意启用，这是 druid 做的一种抛弃措施，如果你不心愿在池子里的连贯齐全不够用导阻塞的业务线程过多，就能够思考配置该项，这个属性的意思是说在连贯不够用时最多让多少个业务线程产生阻塞，流程 1.2 的图里没有体现这个开关的用处，能够在代码里查看，每次在 pollLast 办法里陷入期待前会把属性 notEmptyWaitThreadCount 进行累加，阻塞完结后会递加，由此可见 notEmptyWaitThreadCount 就是示意以后期待可用连贯时阻塞的业务线程的总个数，而 getConnectionInternal 在每次调用 pollLast 前都会判断这样一段代码：
`if (maxWaitThreadCount > 0 && notEmptyWaitThreadCount >= maxWaitThreadCount) {
connectErrorCountUpdater.incrementAndGet(this);
throw new SQLException(“maxWaitThreadCount ” + maxWaitThreadCount + “, current wait Thread count “
+ lock.getQueueLength()); // 间接抛异样，而不是陷入期待状态阻塞业务线程
}
复制代码 `
能够看到，如果配置了 maxWaitThreadCount 所限度的期待线程个数，那么会直接判断以后陷入期待的业务线程是否超过了 maxWaitThreadCount，一旦超过甚至不触发 pollLast 的调用（避免新增期待线程），间接抛错。
个别状况下不须要启用该项，肯定要启用倡议思考好 maxWaitThreadCount 的取值，一般来说产生大量期待阐明代码里存在不合理的中央：比方典型的连接池根本配置不合理，高 qps 的零碎里 maxActive 配置过小；比方借出去的连贯没有及时 close 偿还；比方存在慢查问或者慢事务导致连贯借出工夫过久。这些要比配置 maxWaitThreadCount 更值得优先思考，当然配置这个做一个极限爱护也是没问题的，只是要结合实际状况思考好取值。
五、流程 1.3：连贯可用性测试
①init-checker
讲这块的货色之前，先来理解下如何初始化检测连贯用的 checker，整个流程参考下图：
初始化 checker 产生在 init 阶段（限于篇幅，没有在主流程 2（init 阶段）里体现进去，只须要记住初始化 checker 也是产生在 init 阶段就好），druid 反对多种数据库的连贯源，所以 checker 针对不同的驱动程序都做了适配，所以才看到图中 checker 有不同的实现，咱们依据加载到的驱动类名匹配不同的数据库 checker，上图匹配至 mysql 的 checker，checker 的初始化里做了一件事件，就是判断驱动内是否有 ping 办法（jdbc4 开始反对，mysql-connector-java 早在 3.x 的版本就有 ping 办法的实现了），如果有，则把 usePingMethod 置为 true，用于后续启用 checker 时做判断用（上面会讲，这里置为 true，则通过反射的形式调用驱动程序的 ping 办法，如果为 false，则触发一般的 SELECT 1 查问检测，SELECT 1 就是咱们十分相熟的那个货色啦，新建 statement，而后执行 SELECT 1，而后再判断连贯是否可用）。
②testConnectionInternal
而后回到本节探讨的办法：流程 1.3 对应的 testConnectionInternal
这个办法会利用主流程 2（init 阶段）里初始化好的 checker 对象（流程参考 init-checker）里的 isValidConnection 办法，如果启用 ping，则该办法会利用 invoke 触发驱动程序里的 ping 办法，如果不启用 ping，就采纳 SELECT 1 形式（从 init-checker 里能够看出启不启用取决于加载到的驱动程序里是否存在相应的办法）。
六、流程 1.4：摈弃连贯
通过流程 1.3 返回的测试后果，如果发现连贯不可用，则间接触发摈弃连贯逻辑，这个过程非常简单，如上图所示，由流程 1.2 获取到该连贯时累加下来的 activeCount，在本流程里会再次减一，示意被取出来的连贯不可用，并不能 active 状态。其次这里的 close 是拿着驱动那个连贯对象进行 close，失常状况下一个连贯对象会被 druid 封装成 DruidPooledConnection 对象，外部持有的 conn 就是真正的驱动 Connection 对象，上图中的敞开连贯就是获取的该对象进行 close，如果应用包装类 DruidPooledConnection 进行 close，则代表回收连贯对象（recycle，参考主流程 5）。
七、主流程 3：增加连贯的守护线程
在主流程 2（init 初始化阶段）时就开启了该流程，该流程独立运行，大部分工夫处于期待状态，不会抢占 cpu，然而当连贯不够用时，就会被唤起追加连贯，胜利创立连贯后将会唤醒其余正在期待获取可用连贯的线程，比方：
联合流程 1.2 来看，当连贯不够用时，会通过 empty.signal 唤醒该线程进行补充连贯（阻塞在 empty 上的线程只有主流程 3 的单线程），而后通过 notEmpty 阻塞本人，当该线程补充连贯胜利后，又会对阻塞在 notEmpty 上的线程进行唤醒，让其进入锁竞争状态，简略了解就是一个生产 - 生产模型。这里有一些细节，比方池子里的连贯应用中（activeCount）加上池子里残余连接数（poolingCount）就是指以后一共生成了多少个连贯，这个数不能比 maxActive 还大，如果比 maxActive 还大，则再次陷入期待。而在往池子里 put 连贯时，则判断 poolingCount 是否大于 maxActive 来决定最终是否入池。
八、主流程 4：摈弃连贯的守护线程
流程 4.1：连接池瘦身，查看连贯是否可用以及抛弃多余连贯
整个过程如下：
整个流程分成图中次要的几步，首先利用 poolingCount 减去 minIdle 计算出须要做抛弃查看的连贯对象区间，意味着这个区间的对象有被抛弃的可能，具体要不要放进抛弃队列 evictConnections，要判断两个属性：
minEvictableIdleTimeMillis：最小查看间隙，缺省值 30min，官网解释：一个连贯在池中最小生存的工夫（联合查看区间来看，闲置工夫超过这个工夫，才会被抛弃）。
maxEvictableIdleTimeMillis：最大查看间隙，缺省值 7h，官网解释：一个连贯在池中最大生存的工夫（忽视查看区间，只有闲置工夫超过这个工夫，就肯定会被抛弃）。
如果以后连贯对象闲置工夫超过 minEvictableIdleTimeMillis 且下标在 evictCheck 区间内，则退出抛弃队列 evictConnections，如果闲置工夫超过 maxEvictableIdleTimeMillis，则间接放入 evictConnections（个别状况下会命中第一个判断条件，除非一个连贯不在查看区间，且闲置工夫超过 maxEvictableIdleTimeMillis）。
如果连贯对象不在 evictCheck 区间内，且 keepAlive 属性为 true，则判断该对象闲置工夫是否超出 keepAliveBetweenTimeMillis（缺省值 60s），若超出，则意味着该连贯须要进行连贯可用性查看，则将该对象放入 keepAliveConnections 队列。
两个队列赋值实现后，则池子会进行一次压缩，没有波及到的连贯对象会被压缩到队首。
而后就是解决 evictConnections 和 keepAliveConnections 两个队列了，evictConnections 里的对象会被 close 最初开释掉，keepAliveConnections 外面的对象将会其进行检测（流程参考流程 1.3 的 isValidConnection），碰到不可用的连贯会调用 discard（流程 1.4）摈弃掉，可用的连贯会再次被放进连接池。
整个流程能够看出，连贯闲置后，也并非一下子就缩小到 minIdle 的，如果之前产生一堆的连贯（不超过 maxActive），忽然闲置了下来，则至多须要花 minEvictableIdleTimeMillis 的工夫才能够被移出连接池，如果一个连贯闲置工夫超过 maxEvictableIdleTimeMillis 则必然被回收，所以极其状况下（比方一个连接池从初始化后就没有再被应用过），连接池里并不会始终放弃 minIdle 个连贯，而是一个都没有，生产环境下这是十分不常见的，默认的 maxEvictableIdleTimeMillis 都有 7h，除非是极度冷门的零碎才会呈现这种状况，而开启 keepAlive 也不会颠覆这个规定，keepAlive 的优先级是低于 maxEvictableIdleTimeMillis 的，keepAlive 只是保障了那些查看中不须要被移出连接池的连贯在指定检测时间内去检测其连贯活性，从而决定是否放入池子或者间接 discard。
流程 4.2：被动回收连贯，避免内存透露
过程如下：
这个流程在 removeAbandoned 设置为 true 的状况下才会触发，用于回收那些拿出去的应用长期未偿还（偿还：调用 close 办法触发主流程 5）的连贯。
先来看看 activeConnections 是什么，activeConnections 用来保留以后从池子里被借出去的连贯，这个能够通过主流程 1 看进去，每次调用 getConnection 时，如果开启 removeAbandoned，则会把连贯对象放到 activeConnections，而后如果长期不调用 close，那么这个被借出去的连贯将永远无奈被从新放回池子，这是一件很麻烦的事件，这将存在内存透露的危险，因为不 close，意味着池子会一直产生新的连贯放进 connections，不合乎连接池预期（连接池出发点是尽可能少的创立连贯），而后之前被借出去的连贯对象还有始终无奈被回收的危险，存在内存透露的危险，因而为了解决这个问题，就有了这个流程，流程整体很简略，就是将当初借出去还没有偿还的连贯，做一次判断，符合条件的将会被放进 abandonedList 进行连贯回收（这个 list 里的连贯对象里的 abandoned 将会被置为 true，标记已被该流程解决过，避免主流程 5 再次解决）。
这个如果在实践中能保障每次都能够失常 close，齐全不必设置 removeAbandoned=true，目前如果应用了相似 mybatis、spring 等开源框架，框架外部是肯定会 close 的，所以此项是不倡议设置的，视状况而定。
九、主流程 5：回收连贯
这个流程通常是靠连贯包装类 DruidPooledConnection 的 close 办法触发的，指标办法为 recycle，流程图如下：
这也是十分重要的一个流程，连贯用完要偿还，就是利用该流程实现偿还的动作，利用 druid 对外包装的 Connecion 包装类 DruidPooledConnection 的 close 办法触发，该办法会通过本人外部的 close 或者 syncClose 办法来间接触发 dataSource 对象的 recycle 办法，从而达到回收的目标。
最终的 recycle 办法：
①如果 removeAbandoned 被设置为 true，则通过 traceEnable 判断是否须要从 activeConnections 移除该连贯对象，避免流程 4.2 再次检测到该连贯对象，当然如果是流程 4.2 被动触发的该流程，那么意味着流程 4.2 里曾经 remove 过该对象了，traceEnable 会被置为 false，本流程就不再触发 remove 了（这个流程都是在 removeAbandoned=true 的状况下进行的，在主流程 1 里连贯被放进 activeConnections 时 traceEnable 被置为 true，而在 removeAbandoned=false 的状况下 traceEnable 恒等于 false）。
②如果回收过程中发现存在有未解决完的事务，则触发回滚（比拟有可能触发这一条的是流程 4.2 里强制偿还连贯，也有可能是单纯应用连贯，开启事务却没有提交事务就间接 close 的状况），而后利用 holder.reset 进行复原连贯对象里一些属性的默认值，除此之外，holder 对象还会把由它产生的 statement 对象放到本人的一个 arraylist 外面，reset 办法会循环着敞开外部未敞开的 statement 对象，最初清空 list，当然，statement 对象本人也会记录下其产生的所有的 resultSet 对象，而后敞开 statement 时同样也会循环敞开外部未敞开的 resultSet 对象，这是连接池做的一种保护措施，避免用户拿着连贯对象做完一些操作没有对关上的资源敞开。
③判断是否开启 testOnReturn，这个跟 testOnBorrow 一样，官网默认不开启，也不倡议开启，影响性能，理由参考主流程 1 里针对 testOnBorrow 的解释。
④间接放回池子（以后 connections 的尾部），而后须要留神的是 putLast 办法和 put 办法的不同之处，putLast 会把 lastActiveTimeMillis 置为以后工夫，也就是说不论一个连贯被借出去过久，只有偿还了，最初沉闷工夫就是以后工夫，这就会有造成某种非凡异常情况的产生（十分极其，简直不会触发，能够抉择不看）：
如果不开启 testOnBorrow 和 testOnReturn，并且 keepAlive 设置为 false，那么长连贯可用测试的距离根据就是利用以后工夫减去上次沉闷工夫（lastActiveTimeMillis）得出闲置工夫，而后再利用闲置工夫跟 timeBetweenEvictionRunsMillis（默认 60s）进行比照，超过才进行长连贯可用测试。
那么如果一个 mysql 服务端的长连贯保活工夫被人为调整为 60s，而后 timeBetweenEvictionRunsMillis 被设置为 59s，这个设置是十分正当的，保障了测试距离小于长连贯理论保活工夫，而后如果这时一个连贯被拿出去后始终过了 61s 才被 close 回收，该连贯对象的 lastActiveTimeMillis 被刷为以后工夫，如果在 59s 内再次拿到该连贯对象，就会绕过连贯查看间接报连贯不可用的谬误。
十、完结
到这里针对 druid 连接池的初始化以及其外部一个连贯从生产到沦亡的整个流程就曾经整顿完了，次要是列出其运行流程以及一些次要的监控数据都是如何产生的，没有波及到的是一个 sql 的执行，因为这个基本上就跟应用原生驱动程序差不多，只是 druid 又包装了一层 Statement 等，用于实现一些本人的操作。
参考：《2020 最新 Java 根底精讲视频教程和学习路线！》
链接：https://juejin.cn/post/694340…