转载自：https://www.jianshu.com/p/b9b98ac3e010
一、主流数据库连接池
C3p0: 实现数据源和JNDI绑定，支持JDBC3规范和JDBC2的标准扩展。Hibernate、Spring使用。单线程，性能较差，适用于小型系统，代码600KB左右。
DBCP (Database Connection Pool):Apache的， 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更快的数据库连接池：https://github.com/mauricio/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性能提高一倍。
未来的中间件，一定是和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 客户端进行操作。