数据库连接池剖析3-1

 背景

之前公司内部分享，所以整理数据库连接池相关的剖析

1、连接池简史

1.1 数据库连接池演化

图1

图2

图3

1.2 连接池介绍

数据库连接池：数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是再重新建立一个。

1.2.1 连接池作用

1.资源重用

2.更快的系统响应速度

3.控制资源的使用

1.2.2 连接池核心参数

1. maxActive 连接池支持的最大连接数。

2. maxIdle 连接池中最多可空闲maxIdle个连接。

3. minIdle 连接池中最小空闲连接数，当连接数少于此值时，连接池会创建连接来补充到该值的数量

4. initialSize 初始化连接数目

5. maxWait 连接池中连接用完时,新的请求等待时间（毫秒）

1.3 数据库连接池更新换代

1.3.1 第一代连接池

已经彻底死掉的c3p0和proxool

咸鱼翻身的dbcp

甘心赴死的BoneCP

1.3.2 站在巨人肩膀上的第二代连接池

性能无敌的HikariCP

功能全面的druid

1.3.3 连接池描述

c3p0

c3p0：作为第一代连接池，在很长一段时间内，它一直是Java领域内数据库连接池的代名词，当年盛极一时的Hibernate都将其作为内置的数据库连接池，可见业内对它的稳定行还是认可的，c3p0功能简单易用，稳定性好这是它的优点，但性能上的缺点却让它彻底被打入冷宫。c3p0的性能很差，差到即便是和同时代的产品相比，它也是垫底的。

proxool

如果说c3p0被人嫌弃，是因为它自身架构设计的“原罪”，那proxool的冷门，则是与作者兴趣的缺失有关。proxool最初在设计上另辟蹊径，以JDBC驱动的身份为用户提供连接池服务，这使得将proxool移植到现有代码中别的十分容易，而且proxool还开创性的提供了连接池监控功能，让它迅速的获得了不少用户的青睐。

但产品作者兴趣的缺失，让这款本来很有潜力的产品早早夭折。在github的项目首页，作者写到：“我从2006年之后就再没碰过这个项目了，我甚至连Java都不用了…”，也许，proxool本来就是这位天才coder的练手之作，java本身也不是他的主力语言，但不论哪种原因，proxool都已经和c3p0一样，鲜有人问津了。

咸鱼翻身的dbcp

dbcp（DataBase Connection Pool）属于Apache顶级项目Commons中的核心子项目（最早在Jakarta Commons里就有），在Apache的生态圈中的影响力十分广泛，比如最为大家所熟知的tomcat就在内部集成了dbcp，实现JPA规范的OpenJPA，也是默认集成dbcp的。

dbcp并不是独立实现连接池功能的，它内部依赖于Commons中的另一个子项目pool，连接池最核心的“池”，就是由pool组件提供的，因此，dbcp的性能实际上就是pool的性能

甘心赴死的BoneCP

作者原话：俺是一个高性能的数据库连接池，俺之所以这么牛逼是因为俺在实现的时候减少了锁的使用，想当年，什么c3p0啊DBCP啊都被老子干趴了，但是现在为了支持HikariCP，俺选择退出！

也就是说，BoneCP的退出是它自己的选择，但它又不像proxool是被抛弃的，它是作者经过深思熟虑后，做出的选择。

先说性能，BoneCP自称性能是c3p0的25倍，并提供了依照自己定义的测试案例，提供了一组图片

单线程（1,000,000获得及释放数据库连接请求，连接池大小20-50）

多线程（500线程分别获取释放100个链接，连接池大小50-200）

性能无敌的HikariCP

（后续有HikariCP详细介绍）

性能对比

连接周期操作/毫秒

在池的上下文中，我们试图仅测量池操作的速度 - 因此使用不执行实际连接或SQL的“无操作”DataSource。 连接周期测量从池中获取连接的速度，然后返回。 基本上，这个：

Connection conn = dataSource.getConnection(); conn.close();

语句周期操作/毫秒

因为连接池使用代理包装Statement （及其子类），并跟踪它们以便在Connection关闭时可以关闭它们，所以跟踪Statement和调用它有相关的开销。 这个微观基准测量两者。

Statement statement = connection.createStatement(); statement.execute(); statement.close();

稳定性

功能全面的druid

（后面有druid详细介绍）

druid，是阿里众多优秀开源项目中的一个。它除了提供性能卓越的连接池功能外，还集成了sql监控，黑名单拦截等功能，用它自己的话说，druid是“为监控而生”。

1.3.4连接池对比说明

功能对比

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连接池的性能很差，不建议使用该数据库连接池。

1.3.5 HiKariCP与Druid比较

HiKariCP

1）字节码精简：优化代码，编译后字节码最少，这样的话，CPU就能加载更多代码了；

（2）优化代理和拦截器：减少代码；

（3）自定义数据类型（FastStatementList）代替ArrayList：避免每次get()都要range check，remove()都要从头到尾扫描一遍；

（4）自定义集合类型（ConcurrentBag）：提高并发读写效率；

（5）一些针对BoneCP缺陷的优化。

（6） Springboot2默认数据库连接池选择了HikariCP！！

Druid

（1）连接池性能好，丰富的功能，如SQL监控、黑名单拦截等，最大的特点就是他的监控。

（2）方便扩展，自定义插件；

（3）可防止SQL注入。（WallFilter）

druid

不评论哪个好，一个追求性能，一个偏向监控

ea

参考文档

git源码：

alibaba/druid pool analysis · Issue #232 · brettwooldridge/HikariCP · GitHub

https://github.com/alibaba/druid

技术博客

HikariCP 实现原理与源码解析系统 —— 精品合集 | 芋道源码 —— 纯源码解析博客