之前使用commons-pool2实现了一个对Thrift连接对象进行池化的连接池，后来出现了一个问题，现在记录一下。
问题表现
在对基于commons-pool2实现了对Thrift连接进行池化以后，上线运行了一段时间后发现，最终出现了在从池中取连接的时候无限等待的情况。
问题解决
最长等待时间的设置
首先想到的是，对池的参数配置。由于当时未考虑周全，盲目地使用了池的默认配置，如下所示：
// 初始化连接工厂
ThriftPooledObjectFactory thriftPooledObjectFactory
= new ThriftPooledObjectFactory(thriftServiceConfigItem);
// 初始化连接池
GenericObjectPool objectPool
= new GenericObjectPool<>(thriftPooledObjectFactory);
而可以看下面commons-pool2的源码中，对这个构造方法的实现是初始化了一个默认的GenericObjectPoolConfig对象作为参数：
public GenericObjectPool(PooledObjectFactory factory) {
this(factory, new GenericObjectPoolConfig());
}
GenericObjectPoolConfig的配置
GenericObjectPoolConfig是用于配置池的对象，重点关注以下配置项：
DEFAULT_MAX_WAIT_MILLIS：默认最大等待毫秒数。也就是指当从池中取对象的时候，如果池里现在没有空闲对象，那么这个线程的等待多久。默认的值为-1，表示无限等待。
这里贴出这部分逻辑的关键代码：
@Override
public T borrowObject() throws Exception {
return borrowObject(getMaxWaitMillis());
}
public T borrowObject(long borrowMaxWaitMillis) throws Exception {
...
if (borrowMaxWaitMillis < 0) {
p = idleObjects.takeFirst();
} else {
p = idleObjects.pollFirst(borrowMaxWaitMillis, TimeUnit.MILLISECONDS);
}
if (p == null) {
throw new NoSuchElementException(
"Timeout waiting for idle object");
}
...
}
public E takeFirst() throws InterruptedException {
lock.lock();
try {
E x;
while ( (x = unlinkFirst()) == null) {
notEmpty.await();
}
return x;
} finally {
lock.unlock();
}
}
DEFAULT_MAX_TOTAL：默认最大总数。池中最多能够存在的对象，包括借出去后还未还回来的。
-
DEFAULT_MAX_IDLE：默认最大空闲数。池中最多能够存在的空闲对象，即所有未被借出去的。 -
DEFAULT_MIN_IDLE：默认最小空闲数。池中至少应该存在的空闲对象。假如，最小空闲数为1，最大总数为10，那么当一个线程从池中借对象，而池中只有一个空闲对象的时候，池会在创建一个对象，并借出一个对象，从而保证池中最小空闲数为1。（TODO：待验证）
到这里至少可以判断，默认的无限等待的策略对大多数的场景是不适用的，权衡的做法是设置一个合适的DEFAULT_MAX_WAIT_MILLIS，而非默认的-1。
借还逻辑的问题
为什么会出现池中对象耗尽的问题呢？可以想到是借还逻辑有问题。有可能是池中对象被借出去后并没有保证能还回来。下面是从池中借还对象的逻辑：
// 从池中借对象
TProtocol tProtocol = connectionProvider.getConnection();
// 使用对象
ThriftProxy.Client client = new ThriftProxy.Client(tProtocol);
RegionResponseData regionResponseData = client.GetSugRegion(region_request);
// 将对象还回池中
connectionProvider.returnConnection(tProtocol);
问题就出现在使用对象的这两行：如果这两行正常的执行，那么将对象还回池中这一行也是能正常执行的。然而，如果使用对象的过程中（这里是Thrift调用）发生了异常，那么就不能保证对象能还回池中了。因此，就出现了池中对象只有借没有还的问题。
对异常的解决办法当然是实用try...catch...finally来捕获，下面是修改后的代码：
RegionResponseData regionResponseData = null;
// 从池中获取连接
TProtocol tProtocol = connectionProvider.getConnection();
if(tProtocol != null) {
try {
// 使用对象
ThriftProxy.Client client = new ThriftProxy.Client(tProtocol);
regionResponseData = client.GetSugRegion(region_request);
} catch (Exception e) {
// TODO: 按需要处理异常，这里简单返回null
return null;
} finally {
// 保证最后将对象还回池中
connectionProvider.returnConnection(tProtocol);
}
}else{
// TODO: 空的连接，按需要进行下一步的逻辑，这里简单返回null
return null;
}
问题总结
- 在对资源进行操作时，取得资源后，中间不管进行了何种操作，最终一定要确保资源最终被释放。否则，就很可能出现资源被耗尽的情况。教科书在讲解try...catch...finally的时候已经反复地强调了这一点，直到此时问题发生的时候才深有体会。（实践经验很重要）
- 线程等待资源的时候一定要设置超时时间，无限等待的策略对多数应用来讲是愚蠢的选择。对于实现系统而言，即使返回空结果也比让用户无限等待返回结果要明智（不要磨炼用户的耐心）。