boneCP的链接管理

转载请标明连接：http://www.cnblogs.com/wingsless/p/6349434.html

boneCP链接的实现

boneCP本身实现了标准的java.sql.Connection接口，除了会持有Connection对象以外，还会拥有一些属性用于标记链接的建立时间，空闲时间等。

比较重要的时间概念代码以下：

if (!recreating){
  //上次使用时间戳
    connectionLastUsedInMs = System.currentTimeMillis();
  //上次重置时间戳
  connectionLastResetInMs = System.currentTimeMillis();
  //链接建立时间
  connectionCreationTimeInMs = System.currentTimeMillis();
}

boneCP对链接的管理

MySQL对链接有最大空闲时间的限制，默认是8小时，所以链接池在将链接分配给客户端时，应该保证链接的可用性。

通常会有两种作法：分配时测试和定时测试。

分配时测试：在收到客户端请求时，链接池首先对向数据库发送一条简单的SQL，判断链接是否可用。

定时测试：启动一个测试线程（ConnectionTesterThread），定时每隔一段时间向数据库发送命令，判断链接是否可用。

boneCP采用定时测试的方式保证链接的可用。为了实现该方式，boneCP规定了两个重要的参数：idleConnectionTestPeriodInSeconds（默认4小时）和idleMaxAgeInSeconds（默认1小时），分别表示空闲链接探测周期和链接最大可空闲时间。

默认状况下，boneCP启动的keepalive线程每一个1小时会启动一次，用于检查链接是否达到了空闲时间的上限：

代码片断1：

if (connection.isPossiblyBroken() || 
    ((this.idleMaxAgeInMs > 0) && ( System.currentTimeMillis()-connection.getConnectionLastUsedInMs() > this.idleMaxAgeInMs))){
    // kill off this connection - it's broken or it has been idle for too long
    closeConnection(connection);
    continue;
}

若是一个线程距离上次使用已通过去了1小时以上，则会在这段逻辑中被close掉，而后继续循环扫描其余的链接。

一个链接被close掉以后，boneCP会有其余的线程负责新建链接。所以表如今MySQL客户端上，能够看到每隔1小时，就会关闭一些链接并出现一些新的链接（极端状况下，全部的链接都被关闭，并一次性重建全部链接）。注意新建链接的MySQL分配id和旧链接彻底不一样。

须要注意的是，在默认状况下，并无观察到逻辑执行到这里的现象：

代码片断2：

if (this.idleConnectionTestPeriodInMs > 0 && (currentTimeInMs-connection.getConnectionLastUsedInMs() > this.idleConnectionTestPeriodInMs) &&
    (currentTimeInMs-connection.getConnectionLastResetInMs() >= this.idleConnectionTestPeriodInMs)) {
    // send a keep-alive, close off connection if we fail.
    if (!this.pool.isConnectionHandleAlive(connection)){
        closeConnection(connection);
        continue; 
    }
    // calculate the next time to wake up
    tmp = this.idleConnectionTestPeriodInMs;
    if (this.idleMaxAgeInMs > 0){ // wake up earlier for the idleMaxAge test?
        tmp = Math.min(tmp, this.idleMaxAgeInMs);
        }
}

这段逻辑主要判断是否有链接的上一次重置时间距如今超过4小时，若是有，则向MySQL发一个探测命令，而且将链接的最后一次重置时间设为当前时间，若是链接alive，返回true，不对链接进行close操做。

上一段代码也是ConnectionTesterThread的逻辑，推断应该是由于每隔1小时，链接就会被关闭重建一次，所以不会存在知足这段逻辑条件的链接存在。

若是修改默认值，将idleConnectionTestPeriodInSeconds和idleMaxAgeInSeconds的值对调，那么boneCP仍会每隔1小时（即idleConnectionTestPeriodInSeconds时间）定时调度keepalive线程。

此时能够发现上述两段逻辑都会被执行，每次执行的时候，都会首先执行代码片断2中的逻辑，所以每次都会更新ConnectionHandler的最后一次重置时间，可是链接仍然不会生存超过4小时，每4小时，逻辑就会进入代码片断1中，将链接close掉。

jdbc驱动的NonRegistingDriver分析

如今发现系统运行一段时间之后就会出现fullGC，从内存分析上看，大部份内存都被com.mysql.jdbc.NonRegistingDriver占去。经过跟踪jdbc代码发现，当connection创建的时候，jdbc总会将该connection交给NonRegistingDriver，创建一个虚引用，并将该虚引用放在一个ConcurrentHashMap中。

代码片断3：

protected static void trackConnection(Connection newConn) {
    ConnectionPhantomReference phantomRef = new ConnectionPhantomReference((ConnectionImpl) newConn, refQueue);
    connectionPhantomRefs.put(phantomRef, phantomRef);
}

内存分析中发现不少内存正是被NonRegistingDriver中的ConcurrentHashMap占去，所以能够推断，应该是新建了大量的Connection致使了大量的NonRegistingDriver对象被新建，从而引起了内存问题。

综合上面对boneCP的分析，应该是boneCP定时的将链接close掉再重建致使的，若是在不是很繁忙的系统上，该状况应该会比较严重。

boneCP探测链接可用的方式

在没有设置探测SQL的状况下，boneCP利用jdbc的getMetaData方法，获取connection的元数据，从其Javadoc上看，元数据应该包括了数据库的表，SQL语法，存储过程等等信息：

The metadata includes information about the database's tables, its supported SQL grammar, its stored procedures, the capabilities of this connection, and so on.

通过抓包分析，实际上getMetaData方法向MySQL 发送了一条简单的show tables命令，若是收到response则认为链接是alive的。

转载请标明连接：http://www.cnblogs.com/wingsless/p/6349434.html