一、主流数据库连接池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 ConnectionBoneCP：高效、免费设计提高性能，速度最快，高度可扩展：集成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-asyncscala生态圈的用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)总行数:7960DruidDataSource3000行，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 客户端进行操作硬编码scalaSharding-JDBCJNDI绑定，JDBC3规范和JDBC2的标准，用netty实现mysql协议，没用mysql官方connector。
二方库
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。