Apache Commons Pool 故事一则
最近工作中遇到一个由于对commons-pool的使用不当而引发的问题，习得正确的使用姿势后，写下这个简单的故事，帮助理解Apache Commons Pool的工作原理。
Apache Commons Pool, Java界无人不知无人不晓的对象池技术, 常用于实现各种连接池, 如数据库连接池, Redis连接池等
下面以租车公司为例子说明这张图，介绍commons pool的基本工作方式:
GenericObjectPool(租车公司)
作为租车公司，需要提供租车和收回归还的车辆的两个服务，同时它还要管理着所有的那些车辆，随着业务发展壮大，需要买新车；对于已经不能安全驾驶的车辆，需要将其销毁；同时还要定期对车辆进行安全检测等。
PooledObject(租车公司的所有车辆)
租车公司的车辆分为三类：空闲可租用的车辆(Idle Objects)，已借出的车辆(Active Objects)，认为已丢弃的车辆(Anandoned Objects)
Borrow Object(租车)
- A1: 世界那么大，一位年轻人想租辆车出去逛逛
- A2: 老板先看看有没有空闲的车
- A3.1: 如果有，则将最近归还的车借出去，并标记为已借出(Active)，如果没有空闲的车了，就买辆，同时也标记为已借出(这是一家不差钱的公司)
- A3.2: 老板把标记好的车租给年轻人
Return Object(还车)
- B1: 世界那么大，年轻人终于逛完了，回来还车
- B2: 老板把车放回停车场，并把标记改为空闲状态(Idle)，可以再被其他人租用。
TestOnBorrow/TestOnReturn(租出/归还时进行检查)
这家公司不仅不差钱，它对车辆的安全还很负责，对于租出去的车，不管是从空闲车辆里取出的，还是新买回的，都会先检查一遍这车的好坏，总不能坑了年 轻人，如果发现有问题，立马再换一辆。归还的时候，也会检查一遍，如果有问题，就扔掉(真土豪)，除此之外，公司还专门请了一位车辆安检员，定期对闲置了 一段时间的车辆进行安全检测(Evict Thread)，一有问题也扔掉。
有借有还，看上去一切都很美好。
然而现实里总有意外发生:
年轻人借走车后，发现世界越逛越大，久久不愿回家。 安检员定期检查时发现这车子都借出去大半年了，还没还回来，是不是丢了？于是掏出手机，”啪“的按了一下，远程将车子熄了火，标记为报废车辆(Abandoned)，当作报废处理了。
Evict Thread(定期检查的安检人员)
- C1: 对于已归还标记为空闲的车辆，安检员定期对它们抽查，如果超过一段时间没有使用，看看是否坏掉，坏了就及时作废掉(C2).
- D1: 对于标记为已借出的对象，安检员定期检查时发现借出很久都未还，直接作废(D2)。
好了，故事讲完了，希望大家对Commons Pool都理解了。
有兴趣的同学可以继续往下看看我们遇到的那个问题：
我们使用Jedis作为redis客户端操作，在压测环境下，时不时发现Jedis报了这个异常： ClassCastException - [B cannot be cast to java.lang.Long
网上各种google百度，发现大部分网友们说是由于pipeline操作，出现异常时连接没有正确destory掉，而直接放回连接池里，被下个线程拿到后，取到连接中残留的pipeline的操作结果，从而导致类型转换错误。
这个解释听起来很在理，但反复检查代码，发现对于异常的封装都做好了，而且出现问题时也没有使用pipeline操作，应该不是网友们说的情况。
于是怀疑是不是连接池出了问题，多个线程对同一个连接做了不同的操作，获取错了数据导致，但大名鼎鼎的commons-pool出现这样低级的错误，不可能呀？
翻了几遍commons-pool的代码后，发现可能是上面说的那个定期检查的安检员捣的鬼？
对于借出的对象，我们配置成借出后超过10秒不归还则作废，理论上对于redis的操作，10秒确实也足够了，但是我们对JedisPool做了进 一步的封装，在一些特殊情况下，确实会出现持有连接超过10秒的情况(这个就不展开了)，导致连接还在被程序使用，读取redis的数据处理时，被清理线 程无辜的销毁了(调用jedis.quit())，
jedis的quit命令返回值就是一个Byte数组，而我们的操作返回是Long，于是就出现了ClassCastException - [B cannot be cast to java.lang.Long这样的异常。
最后的解决办法就是将作废时间的定义适当加大。
来自：http://neway6655.github.io/commons-pool, java/2015/12/12/ApacheCommonsPool故事一则.html