druid 数据库链接池

转自：http://blog.csdn.net/jiangguilong2000/article/details/68483886

根据综合性能，可靠性，稳定性，扩展性，易用性等因素替换成最优的数据库链接池。

Druid:druid-1.0.29

数据库  MySQL.5.6.17

替换目标:替换掉C3P0,用druid来替换

替换缘由:

 

一、性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。

二、druid功能最为全面，sql拦截等功能，统计数据较为全面，具备良好的扩展性。

三、综合性能，扩展性等方面，可考虑使用druid或者hikariCP链接池，比较方便对jdbc接口进行监控跟踪等。

四、可开启prepareStatement缓存，对性能会有大概20%的提高。

 

• psCache是connection私有的，因此不存在线程竞争的问题，开启pscache不会存在竞争的性能损耗。
• psCache的key为prepare执行的sql和catalog等，value对应的为prepareStatement对象。开启缓存主要是减小了解析sql的开销。

 

五、3p0历史悠久，代码及其复杂，不利于维护。而且存在deadlock的潜在风险。

六、Druid能够打印SQL，慢查询方面的日志

Druid 参数

 

配置参数	缺省值	游戏服设置的值	参数说明
initialSize	0	4	初始化链接数量
minIdle	0	4	最小空闲链接数
maxActive	8	8	最大并发链接数
maxWait	-1L	60000	获取链接时最大等待时间，单位毫秒。配置了maxWait以后， 缺省启用公平锁，并发效率会有所降低， 若是须要能够经过配置useUnfairLock属性为true使用非公平锁。
timeBetweenEvictionRunsMillis	60000	60000	配置间隔多久才进行一次检测，检测须要关闭的空闲链接，单位是毫秒 Destroy线程会检测链接的间隔时间
minEvictableIdleTimeMillis	1800000	1800000	配置一个链接在池中最小生存的时间，单位是毫秒
validationQuery	null	select 1	用来检测链接是否有效的sql，要求是一个查询语句
testOnBorrow	FALSE	FALSE	申请链接时执行validationQuery检测链接是否有效，作了这个配置会下降性能。
testOnReturn	FALSE	FALSE	归还链接时执行validationQuery检测链接是否有效，作了这个配置会下降性能
testWhileIdle	TRUE	TRUE	建议配置为true，不影响性能，而且保证安全性。 申请链接的时候检测，若是 空闲时间大于 timeBetweenEvictionRunsMillis， 执行validationQuery检测链接是否有效。
poolPreparedStatements	FALSE	TRUE	false 是否缓存preparedStatement，也就是PSCache。 PSCache对支持游标的数据库性能提高巨大，好比说oracle。 在mysql5.5如下的版本中没有PSCache功能，建议关闭掉。 5.5及以上版本有PSCache，建议开启。
maxPoolPreparedStatementPerConnectionSize	10	100	要启用PSCache，必须配置大于0，当大于0时， poolPreparedStatements自动触发修改成true。 单个connnection独享一个statement cache，也就是说maxOpenPreparedStatements是针对单个connection连接的

 

 

运行原理:

数据库链接池在初始化的时候会建立initialSize个链接，当有数据库操做时，会从池中取出一个链接。若是当前池中正在使用的链接数等于maxActive，则会等待一段时间，等待其余操做释放掉某一个链接，若是这个等待时间超过了maxWait，则会报错；若是当前正在使用的链接数没有达到maxActive，则判断当前是否空闲链接，若是有则直接使用空闲链接，若是没有则新创建一个链接。在链接使用完毕后，不是将其物理链接关闭，而是将其放入池中等待其余操做复用。 同时链接池内部有机制判断，若是当前的总的链接数少于miniIdle，则会创建新的空闲链接，以保证链接数获得miniIdle。若是当前链接池中某个链接在空闲了timeBetweenEvictionRunsMillis时间后仍然没有使用，则被物理性的关闭掉。有些数据库链接的时候有超时限制（mysql链接在8小时后断开），或者因为网络中断等缘由，链接池的链接会出现失效的状况，这时候设置一个testWhileIdle参数为true，能够保证链接池内部定时检测链接的可用性，不可用的链接会被抛弃或者重建，最大状况的保证从链接池中获得的Connection对象是可用的。固然，为了保证绝对的可用性，你也可使用testOnBorrow为true（即在获取Connection对象时检测其可用性），不过这样会影响性能。

若是要进行SQL监控，能够加入如下代码:

 

Log4j2Filter log4j2 = new Log4j2Filter();
log4j2.setResultSetLogEnabled(false);
log4j2.setStatementSqlPrettyFormat(false);
log4j2.setStatementExecutableSqlLogEnable(true);

log4j2.setDataSourceLogEnabled(false);
log4j2.setConnectionLogEnabled(false);
log4j2.setStatementLogEnabled(false);
log4j2.setResultSetLogEnabled(false);
ret.setProxyFilters(Arrays.asList(log4j2));

 

闲置检测，建立链接，废弃链接清理由这三线程管理

Daemon Thread [Abandoned connection cleanup thread] 
Daemon Thread [Druid-ConnectionPool-Create-1184124073] 
Daemon Thread [Druid-ConnectionPool-Destroy-1184124073] 

 

参考文章:数据库链接池性能比对(hikari druid c3p0 dbcp jdbc)