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

posted @ 2017-01-25 14:22  wingsless  阅读(2039)  评论(0编辑  收藏  举报