数据库连接池选择及性能比对(hikariCP druid c3p0 dbcp jdbc)

数据库连接池概述

数据库连接的建立是一种耗时、性能低、代价高的操作，频繁的数据库连接的建立和关闭极大的影响了系统的性能。数据库连接池是系统初始化过程中创建一定数量的数据库连接放于连接池中，当程序需要访问数据库时，不再建立一个新的连接，而是从连接池中取出一个已建立的空闲连接，使用完毕后，程序将连接归还到连接池中，供其他请求使用，从而实现的资源的共享，连接的建立、断开都由连接池自身来管理。

数据库连接池为系统的运行带来了以下优势：

昂贵的数据库连接资源得到重用；减少了数据库连接建立和释放的时间开销，提高了系统响应速度；统一的数据库连接管理，避免了连接资源的泄露。

数据库连接池运行机制：

系统初始化时创建连接池，程序操作数据库时从连接池中获取空闲连接，程序使用完毕将连接归还到连接池中，系统退出时，断开所有数据库连接并释放内存资源。

背景

对现有的数据库连接池做调研对比，综合性能，可靠性，稳定性，扩展性等因素选出推荐出最优的数据库连接池 。

各大连接池功能对比

功能	dbcp	druid	c3p0	tomcat-jdbc	HikariCP
是否支持PSCache	是	是	是	否	否
监控	jmx	jmx/log/http	jmx,log	jmx	jmx
扩展性	弱	好	弱	弱	弱
sql拦截及解析	无	支持	无	无	无
代码	简单	中等	复杂	简单	简单
更新维护	否	是	否	否	是
特点	依赖于common-pool	阿里开源，功能全面	历史久远，代码逻辑复杂，且不易维护		优化力度大，功能简单，起源于boneCP
连接池管理	LinkedBlockingDeque	数组、CopyOnWriteArrayList(COW)	队列	FairBlockingQueue	threadlocal+CopyOnWriteArrayList
是否开源	是	是	是	是	是

• 由于boneCP被hikariCP替代，并且已经不再更新，boneCP没有进行调研。
• proxool网上有评测说在并发较高的情况下会出错，proxool便没有进行调研。
• druid的功能比较全面，且扩展性较好，比较方便对jdbc接口进行监控跟踪等。
• c3p0历史悠久，代码及其复杂，不利于维护。并且存在死锁的潜在风险。

性能测试

环境配置:

CPU	Intel® Xeon® CPU E5-2430 v2 @ 2.50GHz，24core
msyql 版本	5.5.46
tomcat-jdbc 版本	8.0.28
HikariCP 版本	2.4.3
c3p0 版本	0.9.5
dbcp版本	2.0.1
druid版本	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	1033	1291
c3p0	4378	5726	7975	10948
dbcp	671	679	897	1380
hikari	96	82	87	78
druid	304	424	690	1130

测试结果：

• 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	2178	1495	1769	1818	1858
c3p0	3237	3451	4488	5994	7906
dbcp	2816	1935	2097	2243	2280
hikari	2299	1546	1682	1751	1772
druid	2297	1551	1800	1977	2032

测试结果：

• 在并发比较少的情况下，每个连接池的响应时间差不多。是由于并发少，基本上没有资源竞争。
• 在并发较高的情况下，随着并发的升高，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的开销。

4: pscache详解

druid的连接池配置中有PreparedStatementCache的配置，该信息解决了sql语句可以被预编译，并且保存在PreparedStatement这个对象中，而这个对象的存储就在PreparedStatementCache，对于oracle可以绕过数据库编译，有很大的提升，但是对于mysql，没有那么明显。

这个值的设置不是越大越好，PSCache会占用jvm，占用量＝连接数＊PSCache设置的大小＊每个PSCache占用的内存。

测试结论

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

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

3：综合性能，扩展性等方面，可考虑使用druid或者hikariCP连接池。

4：可开启prepareStatement缓存，对性能会有大概20%的提升。