数据库连接池性能⽐对（hikaridruidc3p0dbcpjdbc）背景
对现有的连接池做调研对⽐，综合性能，可靠性，稳定性，扩展性等因素选出推荐出最优的数据库连接池。
NOTE: 本⽂所有测试均是库
测试结论
1：性能⽅⾯ hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的⾼性能得益于最⼤限度的避免锁竞争。
2：druid功能最为全⾯，sql拦截等功能，统计数据较为全⾯，具有良好的扩展性。
3：综合性能，扩展性等⽅⾯，可考虑使⽤druid或者hikariCP连接池。
4：可开启prepareStatement缓存，对性能会有⼤概20%的提升。
功能对⽐
功能dbcp druid c3p0tomcat-jdbc HikariCP
是否⽀持
PSCache
是是是否否
监控jmx jmx/log/http jmx,log jmx jmx
扩展性弱好弱弱弱
sql拦截及解析⽆⽀持⽆⽆⽆
代码简单中等复杂简单简单
更新时间2015.8.62015.10.10 2015.12.092015.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 version8.0.28
HikariCP version  2.4.3
c3p0 Version0.9.5-pre8
dbcpVersion  2.0.1
druidVersion  1.0.5
1：获取关闭连接性能测试
测试说明：
初始连接和最⼩连接均为5，最⼤连接为20。在borrow和return均不⼼跳检测
其中打开关闭次数为: 100w次
测试⽤例和mysql在同⼀台机器上⾯，尽量避免io的影响
使⽤mock和连接mysql在不同线程并发下的响应时间
图形：
mock性能数据 (单位:ms)
52050100 tomcat-jdbc4424471,0131,264 c3p04,4805,5277,44910,725 dbcp6766898671,292 hikari38333830 druid291293562985 mysql性能数据 (单位:ms)
52050100 tomcat-jdbc4364531,0331,291 c3p04,3785,7267,97510,948 dbcp6716798971,380 hikari96828778 druid3044246901,130测试结果：
mock和mysql连接性能表现差不多，主要是由于初始化的时候建⽴了连接后期不再建⽴连接，和使⽤mock连接逻辑⼀致。
性能表现：hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
hikariCP 的性能及其优异。hikariCP号称java平台最快的数据库连接池。
hikariCP在并发较⾼的情况下，性能基本上没有下降。
c3p0连接池的性能很差，不建议使⽤该数据库连接池。
hikariCP性能分析：druid连接池配置详解
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的影响
图形：
测试数据：
582050100
tomcat-jdbc2,1781,4951,7691,8181,858
c3p03,2373,4514,4885,9947,906
dbcp2,8161,9352,0972,2432,280
hikari2,2991,5461,6821,7511,772
druid2,2971,5511,8001,9772,032
测试结果：
在并发⽐较少的情况下，每个连接池的响应时间差不多。是由于并发少，基本上没有资源竞争。
在并发较⾼的情况下，随着并发的升⾼，hikariCP响应时间基本上没有变动。
c3p0随着并发的提⾼，性能急剧下降。
3：pscache性能对⽐
测试说明：
通过druid进⾏设置pscache和不设置pscache的性能对⽐
初始连接和最⼩连接均为8，最⼤连接为8。在borrow和return均不⼼跳检测。并且执⾏的并发数为8.
查询10w次。查询流程为：1：建⽴连接，2：循环查询preparestatement语句 3：close连接
测试⽤例和mysql在同⼀台机器上⾯，尽量避免io的影响
测试数据：
cache1,927
not cache2,134
测试结果：
开启psCache缓存，性能⼤概有20%幅度的提升。可考虑开启pscache.
测试说明：
psCache是connection私有的，所以不存在线程竞争的问题，开启pscache不会存在竞争的性能损耗。
psCache的key为prepare执⾏的sql和catalog等，value对应的为prepareStatement对象。开启缓存主要是减少了解析sql的开销。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。