boneCP的连接管理

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的。