数据库及连接池若干问题特集-yaya888-ChinaUnix博客

connection耗尽不一定就是由connection leak引起，如果你的执行队列中线程数设置的比connection pool大，而且你的某些程序占用connection时间过长，致使执行队列中的线程已经把connection pool中的所有的connection都申请出来了，此时如果再有新的执行线程响应请求申请connection，pool中已经告罄，connection就无从得到了，只有等待。这从控制台的connection监控中是看得出的。这种情况下，如果程序能正确关闭connection，connection还是会被释放的，不会泄露。

还有一种情况是已获得connection的线程间发生了死锁，没法去释放connection，使得connection被一直占用。这要去重点检查一下应用中的synchronize代码段和涉及数据库锁的代码。同时可以定时，尤其是系统挂了后作一下thread dump,重点看看运行中和等待资源的线程在忙什么和等什么。

如果要查connection leak，还是得从应用入手，仔细检查connection的分配与释放。确保connection的释放代码放在finally段中。还有就是重点检查connection有没有被一些static对象引用。泄露往往就发生在这里。JVM的GC对付一般的Connection leak还是很有效的，比如说未关闭的connection只是函数中的局部变量且并未被其它对象引用。但GC对被Static对象引用的connection是有心无力。

用profiling工具可以辅助侦测connection leak，具体做法是在CPU的代码执行视图的代码执行树里，检查get connection与close connection的执行次数是否相同？如果get connection执行次数大于close connection，这就要重点检查一下了。这一类的工具有很多，常见的有：JProfiler，JProbe，OptimizeIt

------------------------------------------------------------------------

DBCP代码研读以及就数据库连接失效的解决

问题

网上很多评论说DBCP有很多BUG，但是都没有指明是什么BUG，只有一部分人说数据库如果因为某种原因断掉后再DBCP取道的连接都是失效的连接，而没有重新取。就此研读了一下DBCP的代码，共享之。

分析

DBCP使用apache的对象池ObjectPool作为连接池的实现，有以下主要的方法

Object borrowObject() throws Exception;从对象池取得一个有效对象

void returnObject(Object obj) throws Exception;使用完的对象放回对象池

void invalidateObject(Object obj) throws Exception;使对象失效

void addObject() throws Exception;生成一个新对象

ObjectPool的一个实现就是GenericObjectPool，这个类使用对象工厂PoolableObjectFactory实现对象的生成，失效检查等等功能，以其实现数据库连接工厂PoolableConnectionFactory做以说明，主要方法：

     Object makeObject() throws Exception; 使用ConnectionFactory生成新连接

     void destroyObject(Object obj) throws Exception;关闭连接

     boolean validateObject(Object obj); 验证连接是否有效，如果_validationQuery不空，则使用该属性作为验证连接是否有效的sql语句，查询数据库

     void activateObject(Object obj) throws Exception;激活连接对象

     void passivateObject(Object obj) throws Exception; 关闭连接生成过的Statement和ResultSet，使连接处于非活动状态

而GenericObjectPool有几个主要属性

     _timeBetweenEvictionRunsMillis：失效检查线程运行时间间隔，默认-1

     _maxIdle：对象池中对象最大个数

     _minIdle：对象池中对象最小个数

     _maxActive：可以从对象池中取出的对象最大个数，为0则表示没有限制，默认为8

在构造GenericObjectPool时，会生成一个内嵌类Evictor，实现自Runnable接口。如果_timeBetweenEvictionRunsMillis大于0，每过_timeBetweenEvictionRunsMillis毫秒Evictor会调用evict()方法，检查对象的闲置时间是否大于 _minEvictableIdleTimeMillis毫秒（_minEvictableIdleTimeMillis小于等于0时则忽略，默认为30分钟），是则销毁此对象，否则就激活并校验对象，然后调用ensureMinIdle方法检查确保池中对象个数不小于_minIdle。在调用returnObject方法把对象放回对象池，首先检查该对象是否有效，然后调用PoolableObjectFactory 的passivateObject方法使对象处于非活动状态。再检查对象池中对象个数是否小于_maxIdle，是则可以把此对象放回对象池，否则销毁此对象

还有几个很重要的属性，_testOnBorrow、_testOnReturn、_testWhileIdle，这些属性的意义是取得、返回对象和空闲时是否进行验证，检查对象是否有效，默认都为false即不验证。所以当使用DBCP时，数据库连接因为某种原因断掉后，再从连接池中取得连接又不进行验证，这时取得的连接实际已经时无效的数据库连接了。网上很多说DBCP的bug应该都是如此吧，只有把这些属性设为true，再提供_validationQuery语句就可以保证数据库连接始终有效了，oracle数据库可以使用SELECT COUNT(*) FROM DUAL，不过DBCP要求_validationQuery语句查询的记录集必须不为空，可能这也可以算一个小小的BUG，其实只要_validationQuery语句执行通过就可以了。

注意事项

所以使用DBCP连接池放必须注意构造GenericObjectPool对象时

     validationQuery：SELECT COUNT(*) FROM DUAL

       _testOnBorrow、_testOnReturn、_testWhileIdle：最好都设为true

       _minEvictableIdleTimeMillis：大于0 ，进行连接空闲时间判断，或为0，对空闲的连接不进行验证

     _timeBetweenEvictionRunsMillis：失效检查线程运行时间间隔，如果小于等于0，不会启动检查线程

------------------------------------------------------------------------
1) maxActive 连接池的最大数据库连接数。设为0表示无限制。
2) maxIdle 数据库连接的最大空闲时间。超过此空闲时间，数据库连接将被标记为不可用，然后被释放。设为0表示无限制。
3) maxWait 最大建立连接等待时间。如果超过此时间将接到异常。设为－1表示无限制。
4) removeAbandoned 回收被遗弃的（一般是忘了释放的）数据库连接到连接池中。
5) removeAbandonedTimeout 数据库连接过多长时间不用将被视为被遗弃而收回连接池中。
6) logAbandoned 将被遗弃的数据库连接的回收记入日志。

weblogic数据库连接池被耗尽的原因分析