一、前言

连接池的用途实际上有过开发经验的朋友都已经比较清楚了，当资源对象的创建/销毁比较耗时的场景下，可以通过"池化"技术，达到资源的复用，以此来减少系统的开销、增大系统吞吐量，比如数据库连接池、线程池、Redis 连接池等都是使用的该方式，而我们在开发场景中使用较为广泛的 Jedis 就是使用了 GenericObjectPool 作为它底层的连接池实现。

二、原理概述

图示

• BorrowObject

业务模块通过 BorrowObject 方法从空闲连接队列中获取空闲连接，最长会等待 maxWaitMillis 毫秒，如果拿不到则走 Create。

• ReturnObject

把连接重新放回到 IdleObjects 队列中。

类结构

Jedis里如何使用的

一般情况下我们在 Spring Boot 应用中会通过 Spring-Data-Redis 来使用 Redis，而在业务层会通过 RedisTemplate 来进行 Redis 的操作，但是 RedisTemplate 是怎么来的呢？可以看到当我们引入 Spring-Data-Redis 时，就会引入 RedisAutoConfiguration，这个 AutoConfiguration 定义了，当我们存在 Jedis 的配置时且不存在 RedisTempalte 的 Bean 实例时会自动创建 Bean，核心代码如下图。

而 RedisConnectionFactory 的其中一个实现就是 JedisConnectionFactory，其中就包含了 Pool。

而 Pool 本身内部就能看到我们真正的主角。

捋一下其中的关系，我们常用的 Spring-Data-Redis 的 Jedis 实现最终是通过以下的层级结构来使用 GenericObjectPool 的。

三、深入分析

参数说明

如上述类结构所示，GenericObjectPool 都是在 GenericObjectPoolConfig 或 BaseObjectPoolConfig 中进行配置相关参数的，其中核心参数以及默认值如下：

上图对这些参数按颜色进行了一个归类：

这里需要注意的是，虽然 GenericObjectPool 支持我们配的参数较多，但是 Spring-Data-Redis 将这部分参数收敛了，具体可供我们修改的只有表格上面的这部分内容，其他参数，有一部分在 JedisPoolConfig 类中，继承了 GenericObjectPoolConfig 进行了修改，比如 Spring-Data-Redis 就修改了以下参数的默认值。

testWhileIdle=true minEvictableIdleTimeMillis=60000 timeBetweenEvictionRunsMillis=30000 numTestsPerEvictionRun=-1

核心方法

本文只会针对方法的一些核心链路进行说明，如想知道更多细节，针对源码解析的可以在网上搜索其他相关文章或是到我的参考链接里进行翻看。

BorrowObject

• 超时时间怎么用的？

该方法用于从连接池中获取一个空闲对象，它有可能是从空闲池中直接获取的，或是直接创建出来的，如果第一次从空闲对象中没有获取到，会走创建后重新获取，此时如果对象池目前配置的 BlockWhenExhausted=true，那么就会受 maxWaitMillis 参数所配置的超时时间所控制，如果超过了超时时间，都没拿到一个空闲的对象，则会直接抛出异常。

• testOnBorrow 和 testOnCreate 的使用场景

当获取到一个对象后，由于对象池中往往存放的是诸如数据库连接、Redis 连接等创建时较为耗时的资源，但是因为连接本身是复用的，如果 MySQL/Redis Server 端如果因为某些原因断开/释放了该链接，那么此时拿到的对象就是个无效的对象，因此在 borrowObject 阶段会判定，如果：

testOnBorrow=true || (create && testOnCreate=true)

就会走到：

factory.validateObject

这里如何进行 validateObject 的，是由上层使用对象池的场景所决定的，比如在 Jedis 场景中，会向 Redis Server 发送一个 Ping 命令，如果 Server 返回了 Pong，则认为该连接仍然有效，可以给业务层使用。

但是！！！！！！

线上环境千万不要配置 testOnBorrow=true 或是 testOnCreate=true。

每个对象的获取都需要先校验再拿，会大大增加单次请求的 RT。

ReturnObject

• testOnReturn 的使用场景

实际上 testOnReturn 的使用场景与上述 borrowObject 时的 testOnBorrow 是类似的，只是testOnReturn就是一个归还对象的操作。同理，线上千万不要配置 testOnReturn=true。

• 什么时候归还，什么时候销毁？

对象池中维护了一个结构为 LinkedBlockingDeque，名为 IdleObjects 的对象用于维护空闲对象队列，且是否归或销毁的判断逻辑如下：

final int maxIdleSave = getMaxIdle();
if (isClosed() || maxIdleSave > -1 && maxIdleSave <= idleObjects.size()) {
  ...销毁对象
}else{
  ...返还至idleObjects
}

如果：

对象池已经关闭(只要是程序在运行，且正常使用，不会关闭）

或

配置了 maxIdle 且空闲对象列表数量 >=maxIdle

则对象会被销毁，否则对象会重新回到 IdleObjects 中。

四、内部机制

Evict(定期驱逐/保活机制)

• 周期怎么定？

当 timeBetweenEvictionRunsMillis 配置 >0 时，在 GenericObjectPool 所继承的基类中，会启一个周期性执行的线程，它的执行周期就是 timeBetweenEvictionRunsMillis 的值。

• 为什么要驱逐？

当空闲对象过多，对于客户端或服务端的 TCP 连接维护来讲，本身就是一个开销，因此，需要有一个规则，当有一些对象实在太空闲了，就把它们踢掉。

• 哪些对象应该被驱逐？

首先会从空闲对象列表中挑选出一部分对象，而这个挑选过程本身也有一个规则，它受 numTestsPerEvictionRun 参数控制。

当 numTestsPerEvictionRun>0，会挑选出 numTestsPerEvictionRun 数量的空闲连接进行检查。 当 numTestsPerEvictionRun<0 时，首先会对 numTestsPerEvictionRun 取绝对值，再然后挑选出空闲数量 /numTestsPerEvictionRun 绝对值的数量进行检查，举个例子，如果 numTestsPerEvictionRun=-2，就会挑选出一半进行检查。

• 驱逐检查怎么做？

本身驱逐检查的实现方式是支持自定义的，也就是 evictionPolicy 参数，但是往往只会选择用默认的实现，也就是 DefaultEvictionPolicy，它的驱逐检查策略如下：

if ((config.getIdleSoftEvictTime() < underTest.getIdleTimeMillis() &&
        config.getMinIdle() < idleCount) ||
        config.getIdleEvictTime() < underTest.getIdleTimeMillis()) {
    return true;
}
return false;

underTest 为被检查对象，当存在以下场景时，满足驱逐检查规则，会触发驱逐。

underTest 的空闲时间 > softMinEvictableIdleTimeMillis 且当前空闲对象数量 > minIdle 或 underTest 的空闲时间 > minEvictableIdleTimeMillis。

Tips：有一些好奇的同学可能会问，对象的空闲时间是怎么算的？ 池中的对象本身会维护一个 lastReturnTime 的时间戳，它会随着对象每一次 returnObject 时进行更新，当获取对象空闲时间时，只要它还是在空闲对象中，那么用当前时间戳 -lastReturnTime 就是认为该对象的空闲时间。

• 驱逐与保活的关系是怎么样的？

由于前面提到过，不能配置 testOnBorrow 和 testOnReturn，那么如果 Server 端的链接直接断开了，怎么能保证池中对象的有效性呢？如果让调用端调用时再触发，会不会太晚了呢？这时候就有个参数 testWhileIdle，当此参数打开时，就代表会在对象空闲时进行对象可用性检查，具体代码如下：

if (evict) {
    destroy(underTest);
    destroyedByEvictorCount.incrementAndGet();
} else {
    if (testWhileIdle) {
        try {
            factory.activateObject(underTest);
        } catch (final Exception e) {
            destroy(underTest);
            destroyedByEvictorCount.incrementAndGet();
        }
    }
}

这里隐掉了一些相关的非核心逻辑，这里可以看到 testWhileIdle 的保活机制实际上和 evict 是配套使用的，如果被检查对象需要被驱逐，也就是 evict=true，则会直接 destory 对象，否则它会判定 testWhileIdle 的状态，此时如果 testWhileIdle=true，那么就会激活一下对象，具体激活的方式是由使用对象池的上层工厂所决定的。

Test(检查机制)

本身 GenericObjectPool 为了保证在池子中的对象有效性，会允许上层分别在几个节点进行对象的有效性检查，分别是：

testOnBorrow、testOnReturn、testOnCreate。

这几个基本看名字就知道是什么意思了，在前面讲 borrowObject 和 returnObject 的时候也有提到，还有一个相对比较特别的是：

testWhileIdle。

该参数目的是为了对象在空闲期间可以进行检查，而它的触发实际上是和 evict(定期驱逐机制)联合起来进行使用的。

Abandoned(抛弃机制)

实际上在提到配置参数、BorrowObject 时，还有一个机制，称之为 Abandoned，由于本文的契机是因为 Jedis 的问题分析所写，而 Jedis 连接池并不支持配置 Abandoned，所以本文暂不做解析，或者感兴趣的可以自己到上面讲的源码路径去看一下，本身这个机制的理解也不是特别复杂。

五、排障方式

本身 GenericObjectPool 默认会把自己的一些参数通过 JMX 的方式进行注册，那么我们可以通过 Jvisualvm 进行查看，或是通过 Arthas，输入如下命令：

mbean org.apache.commons.pool2:type=GenericObjectPool,name=pool-redisConnectionFactory

可以获取到对象池当前的一些属性，如下图：

其中对于优化比较有用的就是 CreatedCount（创建对象的数量）、DestoryedCount（对象销毁的对象）、DestoryedByEvictorCount（因为驱逐机制而被销毁的对象数量）。

六、总结

上述文章以 Jedis 为引，分析了 GenericObjectPool 连接池的底层原理以及 Jedis 是如何使用该连接池的，并且结合了 Arthas 分享了一个简单的排障方式，实际上如果知道了 GenericObjectPool 连接池的原理，其他连接池也是大同小异，本文希望抛砖引玉，带大家对于连接池的底层实现有个基本概念，相信以后遇到此类问题也会有分析的思路，不再迷茫~

*文/will

本文属得物技术原创，更多精彩文章请看：得物技术

未经得物技术许可严禁转载，否则依法追究法律责任！