十一、HikariCP源码分析之HouseKeeper

欢迎访问我的博客，同步更新: 

枫山别院

源代码版本2.4.5-SNAPSHOT

HouseKeeper是一个

HikariPool

的内部类，它实现了

Runnable

接口，也就是一个线程任务。这个任务是由

ScheduledThreadPoolExecutor

类型的线程池执行的，也就是说它是一个定时任务。我们在《HikariCP源码分析之初始化分析二》中分析 HikariCP 初始化的时候，遇到了

houseKeepingExecutorService

的初始化，简单分析了它的初始化过程，但是这个任务是非常重要的，我们要仔细分析一下。

它的主要作用就是：检测时间回拨，并关闭空闲时间超期的连接。下面的代码依然是有详细的注释，同时也记录了我当时自己分析代码时遇到的一些疑问和解答。

我们看下代码：

/**
 * HouseKeeper用于空闲连接过期
 */
private class HouseKeeper implements Runnable {
 private volatile long previous = clockSource.plusMillis(clockSource.currentTime(), -HOUSEKEEPING_PERIOD_MS);

 @Override
 public void run() {
 //①
 //刷新通过MBean修改的设置
 connectionTimeout = config.getConnectionTimeout();
 validationTimeout = config.getValidationTimeout();
 leakTask.updateLeakDetectionThreshold(config.getLeakDetectionThreshold());
 //②
 final long idleTimeout = config.getIdleTimeout();
 final long now = clockSource.currentTime();

 //检测时间回拨, 即网络对时服务对时钟的调整, 允许 128 毫秒的时间差
 if (clockSource.plusMillis(now, 128) < clockSource.plusMillis(previous, HOUSEKEEPING_PERIOD_MS)) {
 LOGGER.warn(&quot;{} - Retrograde clock change detected (housekeeper delta={}), soft-evicting connections from pool.&quot;,
 clockSource.elapsedDisplayString(previous, now), poolName);
 previous = now;
 //连接池中所以的连接都标记删除
 softEvictConnections();
 //重新创建连
 fillPool();
 return;
 } else if (now > clockSource.plusMillis(previous, (3 * HOUSEKEEPING_PERIOD_MS) / 2)) {
 // No point evicting for forward clock motion, this merely accelerates connection retirement anyway
 //时钟快了, 没必要调整连接池, 反正是加速了连接的过期, 不影响
 LOGGER.warn(&quot;{} - Thread starvation or clock leap detected (housekeeper delta={}).&quot;, clockSource.elapsedDisplayString(previous, now), poolName);
 }
 //原来的实现代码如下文件的633-650 行: https://github.com/brettwooldridge/HikariCP/blob/bc010fba486b27ae3d034cc9701e0c4217457ddb/src/main/java/com/zaxxer/hikari/pool/HikariPool.java
 // logPoolState(&quot;Before cleanup &quot;);
 // for (PoolBagEntry bagEntry : connectionBag.values(STATE_NOT_IN_USE)) {
 // if (connectionBag.reserve(bagEntry)) {
 // if (bagEntry.evicted) {
 // closeConnection(bagEntry, &quot;(connection evicted)&quot;);
 // }
 // else if (idleTimeout > 0L && clockSource.elapsedMillis(bagEntry.lastAccess, now) > idleTimeout) {
 // closeConnection(bagEntry, &quot;(connection passed idleTimeout)&quot;);
 // }
 // else {
 // connectionBag.unreserve(bagEntry);
 // }
 // }
 // }
 //
 // logPoolState(&quot;After cleanup &quot;);
 //
 // fillPool(); // Try to maintain minimum connections
 // }
 // 代码中, 先将所有超过空闲时间的连接都关闭, 然后将连接池中的连接再填充到minIdle最小空闲连接数
 // 后来有个名为 yaojuncn 的人跟brett提了个 issue, 如下: https://github.com/brettwooldridge/HikariCP/issues/379
 // issue的内容就是yaojuncn发现, 清理空闲连接的时候, 连接数会小于minIdle, 极端情况下会是 0, 他认为这样有问题, 服务请求多的时候, 会大量的创建连接, 给数据库造成压力
 // 但是brett认为, 创建连接非常快, 极端情况的几率极小, 这不是个问题, 提议yaojuncn使用固定大小的连接池
 // 讨论来讨论去, brett终于烦了, 接受了yaojuncn的建议, 并且合并了yaojuncn的 merge request.
 // yaojuncn提的实现就是目前的请清理方式, 这个: https://github.com/yaojuncn/HikariCP/commit/cbb1e1cc93d050457ffe9939b67eacd6c6bd97a0

 //③
 //开始清理超过idleTimeout的空闲连接
 previous = now;

 String afterPrefix = &quot;Pool &quot;;
 if (idleTimeout > 0L) {
 //查出连接池中所有的空闲连接
 final List<PoolEntry> idleList = connectionBag.values(STATE_NOT_IN_USE);
 //空闲连接数量 - 用户配置的最小连接数 = 目前可以回收的连接数, 不明白详见Question①
 int removable = idleList.size() - config.getMinimumIdle();
 //如果有可以回收的连接
 if (removable > 0) {
 logPoolState(&quot;Before cleanup &quot;);
 afterPrefix = &quot;After cleanup &quot;;

 // 按照最近访问的实际, 从小到大排序, 排序指标是最后访问时间的时间戳, 时间大的是最近使用的, 从小到大遍历比较合理, 能先清理掉长时间没用的, 不用遍历所有的空闲连接
 //如果要清理的连接数够了,那么就不用继续遍历了,可以减少循环次数 
 Collections.sort(idleList, LAST_ACCESS_COMPARABLE);
 for (PoolEntry poolEntry : idleList) {
 //判断最后访问时间和当前时间的时间差, 是否超过了用户配置的最大空闲时间, 超过了就将连接变为保留状态
 if (clockSource.elapsedMillis(poolEntry.lastAccessed, now) > idleTimeout && connectionBag.reserve(poolEntry)) {
 //关闭连接
 closeConnection(poolEntry, &quot;(connection has passed idleTimeout)&quot;);
 //可回收连接数减 1, 如果可回收连接数等于 0, 就是清理完了
 if (--removable == 0) {
 break; // keep min idle cons
 }
 }
 }
 }
 }
 //记录日志
 logPoolState(afterPrefix);
 //可能有些连接过期了, 重新填充连接池到用户配置的最小连接数
 fillPool(); // Try to maintain minimum connections
 }
}


①刷新配置

如果你看过《HikariCP源码分析之获取连接流程二》的话可能还记得，我们是可以通过 JMX 的方式来挂起整个连接池的，此时连接池是不可用的状态，然后我们就可以修改连接池的一些配置，然后将连接池恢复。修改了配置之后，并不是立即生效的，因为配置是在这里刷新的，而这里是一个定时任务，是每 30 秒触发一次。

为什么不能立即修改这些配置呢？

因为是在运行期修改的配置，你修改配置之后，连接池中之前的连接还是原来的配置呢，总得要处理一下这些连接吧？而这个处理过程正好是HouseKeeper的职责范围，因此就在这里刷新配置了，而且使用 JMX 修改配置这个需求，对时效性实在没有什么要求，30 秒完全可以接受，毕竟这不是一个常规的操作，一般是测试用途。

至于刷新的配置内容，略过，大家可以看下配置分析那一节的内容。

②时间回拨

这里比较有意思，通常我们的服务器都是有网络对时服务的，如果本地的系统时间不对的话就会自动调整。但是我们的 HikariCP 中的定时任务是依赖系统时间的啊，如果时间被调整了，那么定时任务就错乱了，后果非常严重，会导致该回收的连接回收不了。

开始正式任务之前，

idleTimeout

和

now

依然是准备工作，

idleTimeout

是用户的配置项，连接的最大空闲时间，而

now

就是当前的系统时间。

我们看下这个if判断

clockSource.plusMillis(now, 128) < clockSource.plusMillis(previous, HOUSEKEEPING_PERIOD_MS)

，

clockSource.plusMillis(now, 128)

的意思是当前时间加128毫秒，

clockSource

是一个时间工具类。

previous

是上一次任务的执行时间，

HOUSEKEEPING_PERIOD_MS

是任务的执行间隔，它们相加也就是本次任务应该执行的时间。如果当前时间+128 毫秒，小于，当前任务应该触发的时间，那么就是系统时间回退了128 毫秒以上对吧？这个是不行的。

有两种情况HikariCP 是可以容忍的：

• 系统时间回退 128 毫秒以内

• 系统时间前进了，具体多长时间不管

上面两种情况下，是不会进入 if 条件里的。但是我们还是要分析一下的，假如我们进入了 if 代码块，

previous = now;

这个的业务意思保存一下本次任务执行的时间，因为下次执行任务要用。

softEvictConnections();

一句简简单单的代码，就将连接池中所有的连接都驱逐出去了，连接首先会被标记删除，然后就真的关闭了这个连接，我们后面可以出一个 HikariCP 中连接关闭的单独文章分析下。

fillPool();

含义一眼就能看出来，是重新填充连接池，重新创建连接加入到连接池中。

如果是 else-if ，那么就是系统时间被调快了，这个只是加速了连接的生命结束，对 HikariCP 没有影响，连接被回收了是会自动创建新的连接，这个没有关系，因此不处理，只是打印一个警告。

③清理过期连接

我们直接看 if 里面，使用

connectionBag.values(STATE_NOT_IN_USE)

方法查询出来所有的空闲状态的连接，

int removable = idleList.size() - config.getMinimumIdle();

计算了当前空闲连接数超出用户配置数几个，也就是要清理的连接个数。

如果

removable

大于0，那么确实有需要清理的连接。

这里

Collections.sort(idleList, LAST_ACCESS_COMPARABLE);

先对所有的空闲连接按照最后使用时间从小到大进行排序，因为每个连接上都记录了最后使用时间，时间戳越小的，说明它最后使用时间越早，越大的越是最近使用过的。最近使用过的连接很可能被某个线程保存在本地的 ThreadLocal 中了，我们不清理这些连接，方便线程下次使用的时候直接获取。

然后循环遍历排序后的空闲连接，if 的条件是

clockSource.elapsedMillis(poolEntry.lastAccessed, now) > idleTimeout && connectionBag.reserve(poolEntry)

，如果

clockSource.elapsedMillis(poolEntry.lastAccessed, now)

，它是连接上次使用时间距离当前时间的时间差，大于用户配置的连接的最大空闲时间，说明这个连接空闲了太久，需要回收，此时在 if 条件中就执行

connectionBag.reserve(poolEntry)

，修改连接的状态，修改成功之后，

closeConnection

方法是关闭这个底层连接，是真的被关闭了，然后可回收连接数减 1，继续循环，直到可回收连接数为 0 ，说明已经达到了用户的配置要求，结束。

但是有个问题，我们是回收了多余的空闲连接，假如在这期间，有其他连接生命周期时间到了，被关闭了，或者是连接发生了致命错误，被关闭了。那么，现在剩下的连接数又少于用户配置的最小空闲连接数了，怎么办呢？

这就是

fillPool()

的作用，它会将连接池中的连接数量重新填充到最小连接数。

好了，至此，HouseKeeper的功能我们分析完了