commons-pool 解析

标签：

首先抛出一个经典问题：

   都知道连接MySQL的应用中大多会使用框架例如 c3p0 ,dbcp proxool 等来管理数据库连接池。 数据库连接池毫无疑问都是采用长连接方式。 那么MySQL经典八小时问题为何产生?

   我一开始的疑惑是既然是长连接必然有不停的心跳检测机制一直不停的骚扰者服务端, 那么服务端怎么还能检测到一个八个小时毫无动静的连接呢? 其实这就是对API的使用不当造成的（或者说API实现者应该给设置一些默认的值以防止小白们一上手就问题百出）

我们常用的jedis-XXX.jar以及c3p0XX.jar底层都是使用 commons-pool来作为对象池的实现。这些上层的jar应用一般需要实现commons-pool里面的一种XXXPoolableObjectFactory来做具体的池对象的管理(典型的工厂模式)。下面以jedis为例简单说明：

1 对象如何创建

           jedis的JedisFactory继承了org.apache.commons.pool.BasePoolableObjectFactory实现了makeObject()方法   ：

 public Object makeObject() throws Exception {
        final Jedis jedis = new Jedis(this.host, this.port, this.timeout);
        // 开始进行socket连接
        jedis.connect();
        if (null != this.password) {
            jedis.auth(this.password);
        }
        if( database != 0 ) {
            jedis.select(database);
        }
        
        return jedis;
    }

    这段代码很好懂,无非就是底层开启个socket 开始连接对应的服务器, 例如最底层的代码：

 public void connect() {
        if (!isConnected()) {
            try {
                socket = new Socket();
                //->@wjw_add
                socket.setReuseAddress(true);
                socket.setKeepAlive(true);  //Will monitor the TCP connection is valid
                socket.setTcpNoDelay(true);  //Socket buffer Whetherclosed, to ensure timely delivery of data
                socket.setSoLinger(true,0);  //Control calls close () method, the underlying socket is closed immediately
                //<-@wjw_add

                socket.connect(new InetSocketAddress(host, port), timeout);
                socket.setSoTimeout(timeout);
                outputStream = new RedisOutputStream(socket.getOutputStream());
                inputStream = new RedisInputStream(socket.getInputStream());
            } catch (IOException ex) {
                throw new JedisConnectionException(ex);
            }
        }
    }

2  

Apache Commons Pool,  常用于实现各种连接池, 如数据库连接池, 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这样的异常。

最后的解决办法就是将作废时间的定义适当加大。

commons-pool 解析

标签：

原文地址：http://www.cnblogs.com/ruixueyan/p/5377752.html