Spring常用连接池差异和性能比较
基本配置
基本配置是指连接池进行数据库连接的四个基本必需配置:
传递给JDBC驱动的用于连接数据库的用户名、密码、URL以及驱动类名。
DBCP | c3p0 | Druid | |
用户名 | username | user | username |
密码 | password | password | password |
URL | url | jdbcUrl | jdbcUrl |
驱动类名 | driverClassName | driverClass | driverClassName |
注:在Druid连接池的配置中,driverClassName可配可不配,如果不配置会根据url自动识别dbType(数据库类型),然后选择相应的driverClassName。
关键配置
关键配置:为了发挥数据库连接池的作用,在初始化时将创建一定数量的数据库连接放到连接池中,这些数据库连接的数量是由最小数据库连接数来设定的。无论这些数 据库连接是否被使用,连接池都将一直保证至少拥有这么多的连接数量。连接池的最大数据库连接数量限定了这个连接池能占有的最大连接数,当应用程序向连接池
请求的连接数超过最大连接数量时,这些请求将被加入到等待队列中。
最小连接数:
是数据库一直保持的数据库连接数,所以如果应用程序对数据库连接的使用量不大,将有大量的数据库资源被浪费。
初始化连接数:
连接池启动时创建的初始化数据库连接数量。
最大连接数:
是连接池能申请的最大连接数,如果数据库连接请求超过此数,后面的数据库连接请求被加入到等待队列中。
最大等待时间:
当没有可用连接时,连接池等待连接被归还的最大时间,超过时间则抛出异常,可设置参数为0或者负数使得无限等待(根据不同连接池配置)。
DBCP | c3p0 | Druid | |
最小连接数 | minIdle(0) | minPoolSize(3) | minIdle(0) |
初始化连接数 | initialSize(0) | initialPoolSize(3) | initialSize(0) |
最大连接数 | maxTotal(8) | maxPoolSize(15) | maxActive(8) |
最大等待时间 | maxWaitMillis(毫秒) | maxIdleTime(0秒) | maxWait(毫秒) |
注1:在DBCP连接池的配置中,还有一个maxIdle的属性,表示最大空闲连接数,超过的空闲连接将被释放,默认值为8。对应的该属性在Druid连接池已不再使用,配置了也没有效果,c3p0连接池则没有对应的属性。
注2:数据库连接池在初始化的时候会创建initialSize个连接,当有数据库操作时,会从池中取出一个连接。如果当前池中正在使用的连接数等 于maxActive,则会等待一段时间,等待其他操作释放掉某一个连接,如果这个等待时间超过了maxWait,则会报错;如果当前正在使用的连接数没
有达到maxActive,则判断当前是否空闲连接,如果有则直接使用空闲连接,如果没有则新建立一个连接。在连接使用完毕后,不是将其物理连接关闭,而 是将其放入池中等待其他操作复用。
性能配置:
预缓存设置:
即是PSCache,PSCache对支持游标的数据库性能提升巨大,比如说oracle。JDBC的标准参数,用以控制数据源内加载的 PreparedStatements数量。但由于预缓存的statements属于单个connection而不是整个连接池,所以设置这个参数需要考
虑到多方面的因素。
单个连接拥有的最大缓存数:要启用PSCache,必须配置大于0,当大于0时,poolPreparedStatements自动触发修改为true。在Druid中,不会存在Oracle下PSCache占用内存过多的问题,可以把这个数值配置大一些,比如说100
DBCP | c3p0 | Druid | |
开启缓存功能 | poolPreparedStatements | maxStatements | poolPreparedStatements |
单个连接拥有的最大缓存数 | maxOpenPrepared- Statements |
maxStatementsPer- Connection |
maxOpenPrepared- Statements |
连接有效性检测设置:
连接池内部有机制判断,如果当前的总的连接数少于miniIdle,则会建立新的空闲连接,以保证连接数得到miniIdle。如果当前连接池中某 个连接在空闲了timeBetweenEvictionRunsMillis时间后任然没有使用,则被物理性的关闭掉。有些数据库连接的时候有超时限制
(mysql连接在8小时后断开),或者由于网络中断等原因,连接池的连接会出现失效的情况,这时候设置一个testWhileIdle参数为true, 可以保证连接池内部定时检测连接的可用性,不可用的连接会被抛弃或者重建,最大情况的保证从连接池中得到的Connection对象是可用的。当然,为了 保证绝对的可用性,你也可以使用testOnBorrow为true(即在获取Connection对象时检测其可用性),不过这样会影响性能。
DBCP | c3p0 | Druid | |
申请连接检测 | testOnBorrow | testConnectionOnCheckin | testOnBorrow |
是否超时检测 | testWhileIdle | testWhileIdle | |
空闲时间 | timeBetweenEvictionRunsMillis | idleConnectionTestPeriod | timeBetweenEvictionRunsMillis |
校验用sql语句 | validationQuery | preferredTestQuery | validationQuery |
归还连接检测 | testOnReturn | testConnectionOnCheckout | testOnReturn |
超时连接关闭设置:
removeAbandoned参数,用来检测到当前使用的连接是否发生了连接泄露,所以在代码内部就假定如果一个连接建立连接的时间很长,则将其认定为泄露,继而强制将其关闭掉。
DBCP | c3p0 | Druid | |
是否超时关闭连接 | removeAbandoned | breakAfterAcquireFailure | removeAbandoned |
超时时间 | removeAbandonedTimeout | checkoutTimeout | removeAbandonedTimeout |
是否记录日志 | logAbandoned | logAbandoned |
c3p0重连设置:
设置获取连接失败后,是否重新连接以及间隔时间。
DBCP | c3p0 | Druid | |
重连次数 | acquireRetryAttempts | ||
间隔时间 | acquireRetryDelay |
性能比较
C3P0比较耗费资源,效率方面可能要低一点。 * DBCP在实践中存在BUG,在某些种情会产生很多空连接不能释放,Hibernate3.0已经放弃了对其的支持。 * Proxool的负面评价较少,现在比较推荐它,而且它还提供即时监控连接池状态的功能,便于发现连接泄漏的情况。 * Tomcat JDBC-POOL速度较快,并且支持的功能较多
* 阿里巴巴框架 的druid连接池(建议) * HikariCP , 国外连池优化
测试结论
1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。
2:druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性。
3:综合性能,扩展性等方面,可考虑使用druid或者hikariCP连接池。
4:可开启prepareStatement缓存,对性能会有大概20%的提升。
功能对比
功能 | dbcp | druid | c3p0 | tomcat-jdbc | HikariCP |
是否支持PSCache | 是 | 是 | 是 | 否 | 否 |
监控 | jmx | jmx/log/http | jmx,log | jmx | jmx |
扩展性 | 弱 | 好 | 弱 | 弱 | 弱 |
sql拦截及解析 | 无 | 支持 | 无 | 无 | 无 |
代码 | 简单 | 中等 | 复杂 | 简单 | 简单 |
更新时间 | 2015.8.6 | 2015.10.10 | 2015.12.09 | 2015.12.3 | |
特点 | 依赖于common-pool | 阿里开源,功能全面 | 历史久远,代码逻辑复杂,且不易维护 | 优化力度大,功能简单,起源于boneCP | |
连接池管理 | LinkedBlockingDeque | 数组 | FairBlockingQueue | threadlocal+CopyOnWriteArrayList |
- 由于boneCP被hikariCP替代,并且已经不再更新,boneCP没有进行调研。
- proxool网上有评测说在并发较高的情况下会出错,proxool便没有进行调研。
- druid的功能比较全面,且扩展性较好,比较方便对jdbc接口进行监控跟踪等。
- c3p0历史悠久,代码及其复杂,不利于维护。并且存在deadlock的潜在风险。
性能测试
环境配置:
CPU | Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz,24core |
msyql version | 5.5.46 |
tomcat-jdbc version | 8.0.28 |
HikariCP version | 2.4.3 |
c3p0 Version | 0.9.5-pre8 |
dbcpVersion | 2.0.1 |
druidVersion | 1.0.5 |
1:获取关闭连接性能测试
测试说明:
- 初始连接和最小连接均为5,最大连接为20。在borrow和return均不心跳检测
- 其中打开关闭次数为: 100w次
- 测试用例和mysql在同一台机器上面,尽量避免io的影响
- 使用mock和连接mysql在不同线程并发下的响应时间
图形:
mock性能数据 (单位:ms)
5 | 20 | 50 | 100 | |
tomcat-jdbc | 442 | 447 | 1,013 | 1,264 |
c3p0 | 4,480 | 5,527 | 7,449 | 10,725 |
dbcp | 676 | 689 | 867 | 1,292 |
hikari | 38 | 33 | 38 | 30 |
druid | 291 | 293 | 562 | 985 |
MySQL性能数据 (单位:ms)
5 | 20 | 50 | 100 | |
tomcat-jdbc | 436 | 453 | 1,033 | 1,291 |
c3p0 | 4,378 | 5,726 | 7,975 | 10,948 |
dbcp | 671 | 679 | 897 | 1,380 |
hikari | 96 | 82 | 87 | 78 |
druid | 304 | 424 | 690 | 1,130 |
测试结果:
- mock和mysql连接性能表现差不多,主要是由于初始化的时候建立了连接后期不再建立连接,和使用mock连接逻辑一致。
- 性能表现:hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
- hikariCP 的性能及其优异。hikariCP号称java平台最快的数据库连接池。
- hikariCP在并发较高的情况下,性能基本上没有下降。
- c3p0连接池的性能很差,不建议使用该数据库连接池。
hikariCP性能分析:
- hikariCP通过优化(concurrentBag,fastStatementList )集合来提高并发的读写效率。
- hikariCP使用threadlocal缓存连接及大量使用CAS的机制,最大限度的避免lock。单可能带来cpu使用率的上升。
- 从字节码的维度优化代码。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes )让方法尽量在35个字节码一下,来提升jvm的处理效率。
2:查询一条语句性能测试
测试说明:
- 初始连接和最小连接均为8,最大连接为8。在borrow和return均不心跳检测
- 查询的次数为10w次,查询的语句为 1:打开连接 2:执行 :select 1 3:关闭连接
- 测试用例和mysql在同一台机器上面,尽量避免io的影响
图形:
测试数据:
5 | 8 | 20 | 50 | 100 | |
tomcat-jdbc | 2,178 | 1,495 | 1,769 | 1,818 | 1,858 |
c3p0 | 3,237 | 3,451 | 4,488 | 5,994 | 7,906 |
dbcp | 2,816 | 1,935 | 2,097 | 2,243 | 2,280 |
hikari | 2,299 | 1,546 | 1,682 | 1,751 | 1,772 |
druid | 2,297 | 1,551 | 1,800 | 1,977 | 2,032 |
测试结果:
- 在并发比较少的情况下,每个连接池的响应时间差不多。是由于并发少,基本上没有资源竞争。
- 在并发较高的情况下,随着并发的升高,hikariCP响应时间基本上没有变动。
- c3p0随着并发的提高,性能急剧下降。
3:pscache性能对比
测试说明:
- 通过druid进行设置pscache和不设置pscache的性能对比
- 初始连接和最小连接均为8,最大连接为8。在borrow和return均不心跳检测。并且执行的并发数为8.
- 查询10w次。查询流程为:1:建立连接,2:循环查询preparestatement语句 3:close连接
- 测试用例和mysql在同一台机器上面,尽量避免io的影响
测试数据:
cache | 1,927 |
not cache | 2,134 |
测试结果:
- 开启psCache缓存,性能大概有20%幅度的提升。可考虑开启pscache.
测试说明:
- psCache是connection私有的,所以不存在线程竞争的问题,开启pscache不会存在竞争的性能损耗。
- psCache的key为prepare执行的sql和catalog等,value对应的为prepareStatement对象。开启缓存主要是减少了解析sql的开销。
参考: http://blog.****.net/u011389515/article/details/76578129