共计 10541 个字符，预计需要花费 27 分钟才能阅读完成。
一、前言
咱们常常会接触各种池化的技术或者概念，包含对象池、连接池、线程池等，池化技术最大的益处就是实现对象的反复利用，尤其是创立和应用大对象或者贵重资源（HTTP 连贯对象，MySQL 连贯对象）等方面的时候可能大大节俭零碎开销，对晋升零碎整体性能也至关重要。
在并发申请下，如果须要同时为几百个 query 操作创立 / 敞开 MySQL 的连贯或者是为每一个 HTTP 申请创立一个解决线程或者是为每一个图片或者 XML 解析创立一个解析对象而不应用池化技术，将会给零碎带来极大的负载挑战。
本文次要是剖析 commons-pool2 池化技术的实现计划，心愿通过本文能让读者对 commons-pool2 的实现原理一个更全面的理解。
二、commons-pool2 池化技术分析
越来越多的框架在抉择应用 apache commons-pool2 进行池化的治理，如 jedis-cluster，commons-pool2 工作的逻辑如下图所示：
2.1 外围三元素
2.1.1 ObjectPool
对象池，负责对对象进行生命周期的治理，并提供了对对象池中沉闷对象和闲暇对象统计的性能。
2.1.2 PooledObjectFactory
对象工厂类，负责具体对象的创立、初始化，对象状态的销毁和验证。commons-pool2 框架自身提供了默认的形象实现 BasePooledObjectFactory，业务方在应用的时候只须要继承该类，而后实现 warp 和 create 办法即可。
2.1.3 PooledObject
池化对象，是须要放到 ObjectPool 对象的一个包装类。增加了一些附加的信息，比如说状态信息，创立工夫，激活工夫等。commons-pool2 提供了 DefaultPooledObject 和 PoolSoftedObject 2 种实现。其中 PoolSoftedObject 继承自 DefaultPooledObject，不同点是应用 SoftReference 实现了对象的软援用。获取对象的时候应用也是通过 SoftReference 进行获取。
2.2 对象池逻辑剖析
2.2.1 对象池接口阐明
1）咱们在应用 commons-pool2 的时候，应用程序获取或开释对象的操作都是基于对象池进行的，对象池外围接口次要包含如下：
/**
* 向对象池中减少对象实例
*/
void addObject() throws Exception, IllegalStateException,
UnsupportedOperationException;
/**
* 从对象池中获取对象
*/
T borrowObject() throws Exception, NoSuchElementException,
IllegalStateException;
/**
* 生效非法的对象
*/
void invalidateObject(T obj) throws Exception;
/**
* 开释对象至对象池
*/
void returnObject(T obj) throws Exception;除了接口自身之外，对象池还反对对对象的最大数量，保留工夫等等进行设置。对象池的外围参数项包含 maxTotal，maxIdle，minIdle，maxWaitMillis，testOnBorrow 等。
2.2.2 对象创立解耦
对象工厂是 commons-pool2 框架中用于生成对象的外围环节，业务方在应用过程中须要本人去实现对应的对象工厂实现类，通过工厂模式，实现了对象池与对象的生成与实现过程细节的解耦，每一个对象池应该都有对象工厂的成员变量，如此实现对象池自身和对象的生成逻辑解耦。
能够通过代码进一步验证咱们的思路：
public GenericObjectPool(final PooledObjectFactory<T> factory) {this(factory, new GenericObjectPoolConfig<T>());
}
public GenericObjectPool(final PooledObjectFactory<T> factory,
final GenericObjectPoolConfig<T> config) {
super(config, ONAME_BASE, config.getJmxNamePrefix());
if (factory == null) {jmxUnregister(); // tidy up
throw new IllegalArgumentException("factory may not be null");
}
this.factory = factory;
idleObjects = new LinkedBlockingDeque<>(config.getFairness());
setConfig(config);
}
public GenericObjectPool(final PooledObjectFactory<T> factory,
final GenericObjectPoolConfig<T> config, final AbandonedConfig abandonedConfig) {this(factory, config);
setAbandonedConfig(abandonedConfig);
}能够看到对象池的构造方法，都依赖于对象结构工厂 PooledObjectFactory，在生成对象的时候，基于对象池中定义的参数和对象结构工厂来生成。
/**
* 向对象池中减少对象，个别在预加载的时候会应用该性能
*/
@Override
public void addObject() throws Exception {assertOpen();
if (factory == null) {
throw new IllegalStateException("Cannot add objects without a factory.");
}
final PooledObject<T> p = create();
addIdleObject(p);
}create() 办法基于对象工厂来生成的对象，持续往下跟进代码来确认逻辑；
final PooledObject<T> p;
try {p = factory.makeObject();
if (getTestOnCreate() && !factory.validateObject(p)) {createCount.decrementAndGet();
return null;
}
} catch (final Throwable e) {createCount.decrementAndGet();
throw e;
} finally {synchronized (makeObjectCountLock) {
makeObjectCount--;
makeObjectCountLock.notifyAll();}
}此处确认了 factory.makeObject() 的操作，也印证了上述的揣测，基于对象工厂来生成对应的对象。
为了更好的可能实现对象池中对象的应用以及跟踪对象的状态，commons-pool2 框架中应用了池化对象 PooledObject 的概念，PooledObject 自身是泛型类，并提供了 getObject() 获取理论对象的办法。
2.2.3 对象池源码剖析
通过上述剖析咱们晓得了对象池承载了对象的生命周期的治理，包含整个对象池中对象数量的管制等逻辑，接下来咱们通过 GenericObjectPool 的源码来剖析到底是如何实现的。
对象池中应用了双端队列 LinkedBlockingDeque 来存储对象，LinkedBlockingDeque 对列反对 FIFO 和 FILO 两种策略，基于 AQS 来实现队列的操作的协同。
LinkedBlockingDeque 提供了队尾和队头的插入和移除元素的操作，相干操作都进行了退出重入锁的加锁操作队列中设置 notFull 和 notEmpty 两个状态变量，当对队列进行元素的操作的时候会触发对应的执行 await 和 notify 等操作。
/**
* 第一个节点
* Invariant: (first == null && last == null) ||
* (first.prev == null && first.item != null)
*/
private transient Node<E> first; // @GuardedBy("lock")
/**
* 最初一个节点
* Invariant: (first == null && last == null) ||
* (last.next == null && last.item != null)
*/
private transient Node<E> last; // @GuardedBy("lock")
/** 以后队列长度 */
private transient int count; // @GuardedBy("lock")
/** 队列最大容量 */
private final int capacity;
/** 主锁 */
private final InterruptibleReentrantLock lock;
/** 队列是否为空状态锁 */
private final Condition notEmpty;
/** 队列是否满状态锁 */
private final Condition notFull;队列外围点为：
1. 队列中所有的移入元素、移出、初始化结构元素都是基于主锁进行加锁操作。
2. 队列的 offer 和 pull 反对设置超时工夫参数，次要是通过两个状态 Condition 来进行协调操作。如在进行 offer 操作的时候，如果操作不胜利，则基于 notFull 状态对象进行期待。
public boolean offerFirst(final E e, final long timeout, final TimeUnit unit)
throws InterruptedException {Objects.requireNonNull(e, "e");
long nanos = unit.toNanos(timeout);
lock.lockInterruptibly();
try {while (!linkFirst(e)) {if (nanos <= 0) {return false;}
nanos = notFull.awaitNanos(nanos);
}
return true;
} finally {lock.unlock();
}
}如进行 pull 操作的时候，如果操作不胜利，则对 notEmpty 进行期待操作。
public E takeFirst() throws InterruptedException {lock.lock();
try {
E x;
while ((x = unlinkFirst()) == null) {notEmpty.await();
}
return x;
} finally {lock.unlock();
}
}反之当操作胜利的时候，则进行唤醒操作，如下所示：
private boolean linkLast(final E e) {// assert lock.isHeldByCurrentThread();
if (count >= capacity) {return false;}
final Node<E> l = last;
final Node<E> x = new Node<>(e, l, null);
last = x;
if (first == null) {first = x;} else {l.next = x;}
++count;
notEmpty.signal();
return true;
}2.3 外围业务流程
2.3.1 池化对象状态变更
上图是 PooledObject 的状态机图，蓝色示意状态，红色示意与 ObjectPool 相干的办法.PooledObject 的状态为：IDLE、ALLOCATED、RETURNING、ABANDONED、INVALID、EVICTION、EVICTION\_RETURN\_TO_HEAD
所有状态是在 PooledObjectState 类中定义的，其中一些是临时未应用的，此处不再赘述。
2.3.2 对象池 browObject 过程
第一步、依据配置确定是否要为标签删除调用 removeAbandoned 办法。
第二步、尝试获取或创立一个对象，源码过程如下：
//1、尝试从双端队列中获取对象，pollFirst 办法是非阻塞办法
p = idleObjects.pollFirst();
if (p == null) {p = create();
if (p != null) {create = true;}
}
if (blockWhenExhausted) {if (p == null) {if (borrowMaxWaitMillis < 0) {
//2、没有设置最大阻塞等待时间，则有限期待
p = idleObjects.takeFirst();} else {
//3、设置最大等待时间了，则阻塞期待指定的工夫
p = idleObjects.pollFirst(borrowMaxWaitMillis,
TimeUnit.MILLISECONDS);
}
}
} 示意图如下所示：
第三步、调用 allocate 使状态更改为 ALLOCATED 状态。
第四步、调用工厂的 activateObject 来初始化对象，如果产生谬误，请调用 destroy 办法来销毁对象，例如源代码中的六个步骤。
第五步、调用 TestFactory 的 validateObject 进行基于 TestOnBorrow 配置的对象可用性剖析，如果不可用，则调用 destroy 办法销毁对象。3- 7 步骤的源码过程如下所示：
// 批改对象状态
if (!p.allocate()) {p = null;}
if (p != null) {
try {
// 初始化对象
factory.activateObject(p);
} catch (final Exception e) {
try {destroy(p, DestroyMode.NORMAL);
} catch (final Exception e1) {}}
if (p != null && getTestOnBorrow()) {
boolean validate = false;
Throwable validationThrowable = null;
try {
// 验证对象的可用性状态
validate = factory.validateObject(p);
} catch (final Throwable t) {PoolUtils.checkRethrow(t);
validationThrowable = t;
}
// 对象不可用，验证失败，则进行 destroy
if (!validate) {
try {destroy(p, DestroyMode.NORMAL);
destroyedByBorrowValidationCount.incrementAndGet();} catch (final Exception e) {// Ignore - validation failure is more important}
}
}
}2.3.3 对象池 returnObject 的过程执行逻辑
第一步、调用 markReturningState 办法将状态更改为 RETURNING。
第二步、基于 testOnReturn 配置调用 PooledObjectFactory 的 validateObject 办法以进行可用性查看。如果查看失败，则调用 destroy 耗费该对象，而后确保调用 idle 以确保池中有 IDLE 状态对象可用，如果没有，则调用 create 办法创立一个新对象。
第三步、调用 PooledObjectFactory 的 passivateObject 办法进行反初始化操作。
第四步、调用 deallocate 将状态更改为 IDLE。
第五步、检测是否已超过最大闲暇对象数，如果超过，则销毁以后对象。
第六步、依据 LIFO（后进先出）配置将对象搁置在队列的结尾或结尾。
2.4 拓展和思考
2.4.1 对于 LinkedBlockingDeque 的另种实现
上文中剖析到 commons-pool2 中应用了双端队列以及 java 中的 condition 来实现队列中对象的治理和不同线程对对象获取和开释对象操作之间的协调，那是否有其余计划能够实现相似成果呢？答案是必定的。
应用双端队列进行操作，其实是想将闲暇对象和沉闷对象进行隔离，实质上将咱们用两个队列来别离存储闲暇队列和以后沉闷对象，而后再对立应用一个对象锁，也是能够达成雷同的指标的，大略的思路如下：
1、双端队列改为两个单向队列别离用于存储闲暇的和沉闷的对象，队列之间的同步和协调能够通过对象锁的 wait 和 notify 实现。
public class PoolState {protected final List<PooledObject> idleObjects = new ArrayList<>();
protected final List<PooledObject> activeObjects = new ArrayList<>();
//...
}2、在获取对象时候，本来对双端队列的 LIFO 或者 FIFO 变成了从闲暇队列 idleObjects 中获取对象，而后在获取胜利并对象状态非法后，将对象增加到沉闷对象汇合 activeObjects 中，如果获取对象须要期待，则 PoolState 对象锁应该通过 wait 操作，进入期待状态。
3、在开释对象的时候，则首先从沉闷对象汇合 activeObjects 删除元素，删除实现后，将对象减少到闲暇对象汇合 idleObjects 中，须要留神的是，在开释对象过程中也须要去校验对象的状态。当对象状态不非法的时候，对象应该进行销毁，不应该增加到 idleObjects 中。开释胜利后则 PoolState 通过 notify 或者 notifyAll 唤醒期待中的获取操作。
4、为保障对沉闷队列和闲暇队列的操作线程安全性，获取对象和开释对象须要进行加锁操作，和 commons2-pool 中的统一。
2.4.2 对象池的自我爱护机制
咱们在应用 commons-pool2 中获取对象的时候，会从双端队列中阻塞期待获取元素 (或者是创立新对象)，然而如果是应用程序的异样，始终未调用 returnObject 或者 invalidObject 的时候，那可能就会呈现对象池中的对象始终回升，达到设置的上线之后再去调用 borrowObject 的时候就会呈现始终期待或者是期待超时而无奈获取对象的状况。
commons-pool2 为了防止上述剖析的问题的呈现，提供了两种自我爱护机制：
2.4.2.1 基于阈值的检测
从对象池中获取对象的时候会校验以后对象池的沉闷对象和闲暇对象的数量占比，当闲暇独享非常少，沉闷对象十分多的时候，会触发闲暇对象的回收，具体校验规定为：如果以后对象池中少于 2 个 idle 状态的对象或者 active 数量 > 最大对象数 -3 的时候，在 borrow 对象的时候启动透露清理。通过 AbandonedConfig.setRemoveAbandonedOnBorrow 为 true 进行开启。
// 依据配置确定是否要为标签删除调用 removeAbandoned 办法
final AbandonedConfig ac = this.abandonedConfig;
if (ac != null && ac.getRemoveAbandonedOnBorrow() && (getNumIdle() < 2) && (getNumActive() > getMaxTotal() - 3) ) {removeAbandoned(ac);
}2.4.2.2 异步调度线程检测
AbandonedConfig.setRemoveAbandonedOnMaintenance 设置为 true 当前，在保护工作运行的时候会进行透露对象的清理，通过设置 setTimeBetweenEvictionRunsMillis 来设置保护工作执行的工夫距离。
检测和回收实现逻辑剖析：
在构造方法外部逻辑的最初调用了 startEvictor 办法。这个办法的作用是在结构完对象池后，启动回收器来监控回收闲暇对象。startEvictor 定义在 GenericObjectPool 的父类 BaseGenericObjectPool（形象）类中，咱们先看一下这个办法的源码。
在结构器中会执行如下的设置参数；
public final void setTimeBetweenEvictionRunsMillis(final long timeBetweenEvictionRunsMillis) {
this.timeBetweenEvictionRunsMillis = timeBetweenEvictionRunsMillis;
startEvictor(timeBetweenEvictionRunsMillis);
}当且仅当设置了 timeBetweenEvictionRunsMillis 参数后才会开启定时清理工作。
final void startEvictor(final long delay) {synchronized (evictionLock) {EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis, TimeUnit.MILLISECONDS);
evictor = null;
evictionIterator = null;
// 如果 delay<= 0 则不会开启定时清理工作
if (delay > 0) {evictor = new Evictor();
EvictionTimer.schedule(evictor, delay, delay);
}
}
}持续跟进代码能够发现，调度器中设置的清理办法的实现逻辑理论在对象池中定义的，也就是由 GenericObjectPool 或者 GenericKeyedObjectPool 来实现，接下来咱们持续探索对象池是如何进行对象回收的。
a)、外围参数：
minEvictableIdleTimeMillis：指定闲暇对象最大保留工夫，超过此工夫的会被回收。不配置则不过期回收。
softMinEvictableIdleTimeMillis：一个毫秒数值，用来指定在闲暇对象数量超过 minIdle 设置，且某个闲暇对象超过这个闲暇工夫的才能够会被回收。
minIdle：对象池里要保留的最小空间对象数量。
b)、回收逻辑
以及一个对象回收策略接口 EvictionPolicy，能够预料到对象池的回收会和上述的参数项及接口 EvictionPolicy 产生关联，持续跟进代码会发现如下的内容，能够看到在判断对象池能够进行回收的时候，间接调用了 destroy 进行回收。
boolean evict;
try {
evict = evictionPolicy.evict(evictionConfig, underTest,
idleObjects.size());
} catch (final Throwable t) {
// Slightly convoluted as SwallowedExceptionListener
// uses Exception rather than Throwable
PoolUtils.checkRethrow(t);
swallowException(new Exception(t));
// Don't evict on error conditions
evict = false;
}
if (evict) {
// 如果能够被回收则间接调用 destroy 进行回收
destroy(underTest);
destroyedByEvictorCount.incrementAndGet();}为晋升回收的效率，在回收策略判断对象的状态不是 evict 的时候，也会进行进一步的状态判断和解决，具体逻辑如下：
1. 尝试激活对象，如果激活失败则认为对象曾经不再存活，间接调用 destroy 进行销毁。
2. 在激活对象胜利的状况下，会通过 validateObject 办法取校验对象状态，如果校验失败，则阐明对象不可用，须要进行销毁。
boolean active = false;
try {
// 调用 activateObject 激活该闲暇对象，实质上不是为了激活，// 而是通过这个办法能够断定是否还存活，这一步外面可能会有一些资源的开拓行为。factory.activateObject(underTest);
active = true;
} catch (final Exception e) {
// 如果激活的时候，产生了异样，就阐明该闲暇对象曾经失联了。// 调用 destroy 办法销毁 underTest
destroy(underTest);
destroyedByEvictorCount.incrementAndGet();}
if (active) {
// 再通过进行 validateObject 校验有效性
if (!factory.validateObject(underTest)) {
// 如果校验失败，阐明对象曾经不可用了
destroy(underTest);
destroyedByEvictorCount.incrementAndGet();} else {
try {
/*
* 因为校验还激活了闲暇对象，调配了额定的资源，那么就通过 passivateObject 把在 activateObject 中开拓的资源开释掉。*/
factory.passivateObject(underTest);
} catch (final Exception e) {
// 如果 passivateObject 失败，也能够阐明 underTest 这个闲暇对象不可用了
destroy(underTest);
destroyedByEvictorCount.incrementAndGet();}
}
}三、写在最初
连接池可能给程序开发者带来一些便利性，前言中咱们剖析了应用池化技术的益处和必要性，然而咱们也能够看到 commons-pool2 框架在对象的创立和获取上都进行了加锁的操作，这会在并发场景下肯定水平的影响应用程序的性能，其次池化对象的对象池中对象的数量也是须要进行正当的设置，否则也很难起到真正的应用对象池的目标，这给咱们也带来了肯定的挑战。
作者：vivo 互联网服务器团队 -Huang Xiaoqun
