一、主流 数据库连接池

C3p0 : 实现 数据源和JNDI绑定 ，支持 JDBC3规范和JDBC2的标准 扩展。 Hibernate 、Spring使用。单线程，性能较差，适用于小型系统，代码600KB左右。

DBCP (Database Connection Pool) :Apache的， Jakarta commons-pool对象池机制 ， Tomcat 使用。单独使用dbcp需要3个包：common-dbcp.jar,common-pool.jar,common-collections.jar，预先将数据库连接放内存中，建立数据库连接时，直接到连接池中申请，用完放回。单线程，并发量低，性能不好，适用于小型系统。

Tomcat Jdbc Pool ：Tomcat在7.0以前都是使用，单线程，保证线程安全会锁整个连接池， 性能差 ，超过60个类 复杂 。Tomcat从7.0开始叫做Tomcat jdbc pool，基于 Tomcat JULI ，使用Tomcat日志框架， 完全兼容dbcp ， 异步 方式获取连接，支持高并发应用环境，核心文件 8个 ，支持 JMX ，支持XA Connection。

BoneCP ：高效、免费。设计提高性能，速度最快，高度可扩展：集成Hibernate和DataNucleus中。连接状态切换的回调机制；允许直接访问连接；自动化重置能力；JMX支持；懒加载能力；支持XML和属性文件配置方式；较好的 Java 代码组织，100%单元测试分支代码覆盖率；代码40KB左右。

Druid ： Java中最好 ，强大 监控和扩展 ，可用于大数据实时 查询和分析 的 高容错、高性能 分布式系统，尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，100%正常运行。主要特色：分析监控；交互式查询快；高可用；可扩展；

主流连接池各项功能对比如下 ：

有HikariCP的

二、HikariCP性能分析：

HikariCP通过优化 (concurrentBag，fastStatementList )集合来提高并发的读写效率。

使用threadlocal缓存连接及大量使用CAS的机制，最大限度的避免lock。可能带来cpu使用率的上升。

字节码 的维度 优化代码 。 (default inline threshold for a JVM running the Server Hotspot compiler is 35 bytecodes ）让方法尽量在35个字节码一下， 提升jvm 的处理 效率 。HikariCP做的优化补充如下：

MySQL connecter 源码里用的就是 ping命令

比HikariCP更快的数据库连接池： postgresql-async

scala 生态圈的。用 netty 实现mysql协议，没用mysql官方connector， 纯异步 ，连接池写的随便，性能依然很好。

三、前瞻，未来到底是HikariCP还是Druid的天下？

容器调度加编排 的 云操作系统 取而代单机的操作系统。 裸机或者虚拟机 的运行时也将会被 容器取代 。 通信 方面将会使用 Service Mesh 。

中间件 趋势是弱化到 无感知 。 maven 依赖问题，把二方库写在 pom 里， 监控 等代码的 硬编码 进应用里都将逐渐弱化到不复存在，取而代之的那些 java agent （如 pinpoint 、skywalking之类），或是service mesh这种 side car 模式都是可以做中间件（包括连接池）的监控的。

有赞用HikariCP替换durid后，RT出现断崖式下滑（1.5ms ～ 1.2ms） 并且持续稳定毛刺少。性能测试与压测之后，比druid性能提高一倍。

阿飞基于最新tag统计java、xml文件，druid(alibaba-druid)总行数:430289，HikariCP(brettwooldridge-HikariCP)总行数:18372。

只统计java代码，druid(alibaba-druid)总行数:428749，HikariCP(brettwooldridge-HikariCP)总行数:17556。

再过滤一下test目录，(alibaba-druid)总行数:215232，(brettwooldridge-HikariCP)总行数:7960。

DruidDataSource 3000行 ， druid 是在jdbc的基础上，自己编码做得增强。druid生活在第一、二代连接池的面向过程的年代，忘了松耦合， 监控 和数据库 连接池 做在一个项目里（紧耦合没隔离）。监控在service mesh的。

未来的中间件，一定是和spring生态圈、servich mesh一样，大道至简，越来越薄，升级中间件不再是需要用户强行升级maven依赖解决依赖冲突，而是通过 mesh的方式 极致到升级让业务方 无感知 。热部署、潘多拉boot、容器隔离等解决依赖冲突的妥协方式也将可能大概率 被置换掉 。

四、从Sharding-jdbc架构演进看未来

Database Mesh（ 搭乘 Service Mesh 新词 ）： 用 啮合层 将数据库（散落系统各个角落） 统一治理 。

首要目标：啮合应用与数据库 间的交互（这样的 交互网络 像蜘蛛网一样 复杂而有序 ），不是啮合db中的数据，将 分布式 数据访问 应用 与 数据库 有机 串联。 Sharding-JDBC 以 JDBC 层分片架构图如下：

Sharding-JDBC 分别实现 Driver、Server 、Sidecar 三个不同版本，组成 Sharding-JDBC 的生态圈，为不同的 需求与环境 提供 差异化服务 。

Sharding-JDBC-Server 使原来 DBA 通过 Sharding-JDBC-Driver 无法对数据进行操作 的缺憾得到了 补偿 。由于 Sharding-JDBC-Driver 无需通过代理层进行二次转发 ，因此线上性能更佳，可通过以下的 混合部署方案 使用 Sharding-JDBC:

Sharding-JDBC-Driver：

线上 应用使用 ，直连数据库 以获取 最优性能 ；

用 MySQL 命令行 或 UI 客户端 ， 连接 Sharding-JDBC- Server 方便的 查询数据 和 执行各种 DDL 语句 。

同一 注册中心 集群 ，通过 管理端配置 注册中心中的 数据 ， 注册中心自 动将 配置 变更 推送 至 Driver 和 Server 应用。若数据库拆分的过多而导致 连接数会暴涨 ，则可以考虑直接在线上使用 Sharding-JDBC- Server ，以达到 有效控制连接数 的目的。

Sharding-JDBC-Sidecar 将问世，部署架构：

基于 Sharding-JDBC 的 Database Mesh 与 Service Mesh 互不干扰 ，相得益彰。 服务之间 的交互由 Service Mesh Sidecar 接管，基于 SQL 的 数据库访问 由 Sharding-JDBC-Sidecar 接管（随着宿主机的生命周期创建和消亡的）。

非静态 IP ，完全动态和弹性的存在，无中心节点。数据运维等操作，启动 Sharding-JDBC-Server 进程 作为静态 IP 入口 ，通过各种 命令行或 UI 客户端 进行操作。

硬编码

scala

Sharding-JDBC

JNDI绑定，JDBC3规范和JDBC2的标准，

用netty实现mysql协议，没用mysql官方connector

二方库