HikariCP与Druid对比

2015年1月21日，一个印度小哥引发了HikariCP 和Druid之间的“华山论剑”。HikariCP的作者brettwooldridge和Druid的作者温少都参与了这次论剑。
事情的起因是这样的：印度小哥manikantag给HikariCP提交了一个Github issue，大意是他觉得Brett Wooldridge 对于Java数据库连接池的分析非常有用，他碰巧在 GitHub 上发现了阿里巴巴公司开源的数据库连接池Druid，并且自称Druid是最快的数据库连接池。
在快速浏览以后，manikantag 觉得Druid 有很多炫醋的功能，想听听HikariCP 的作者BrettWooldridge的想法。
如图所示，Druid的中文文档里的确声称它是Java语言中最好的数据库连接池，

虽然英文版文档还是比较中庸：Druid is one of the best database connection pools written in Java（Druid 是Java 语言中最好的数据库连接池之一）。

不过印度小哥的短文写得却非常尖锐，他去掉了“之一”，如图 6-2 所示。中文版本的 Druid 官方文档也是声称，“Druid是Java 语言中最好的数据库连接池”
HikariCP的日文意思就是光,“天下武功唯快不破”，它主打的就是快。Brett
Wooldridge 投人了大量的心血致力于 HikariCP 的性能，它的官方首页就用了 benchmark 明确表示比Tomcat、Vibur、c3p0、DBCP2等数据库连接池都要快（可是偏偏没有Druid）。
面对这个挑战，Brett Wooldridge肯定不会回避，在印度小哥发出issue的当天，BrettWooldridge 就给出了在他的台式 PC 上快速运行基准测试产生的结果，如图所示。

Brett Wooldridge 表示，最起码在 HikariCP的benchmark里，Druid 是创建和返回连接最慢的数据库连接池，在创建和关闭statement里排名第三。
在 Brett Wooldridge 的测试中，为了保证基准测试的公平性，Druid 的配置和其他数据库连接池保持了一致，如下所示：

对于这份测试数据，Brett Wooldridge也做了声明：一方面Druid的官方维基的基准页面没有显示他们运行的设置，另外一方面他们也没有像HikariCP那样为测试提供类似benchmark之类的源代码。Brett Wooldridge 甚至怀疑 Druid 为了提高基准数据，禁用了test-on-borrow 连接验证功能。
对于这份数据，Druid的作者温少在一年后做了回复，他解释了Druid 性能不佳的原因是因为测试数据配置了 maxWait 属性，因为这个属性会导致Druid数据库连接池使用公平模式的 ReentrantLocke，如下所示：

设计这个锁的原因是在生产过程中,Druid 遇到了锁的公平和效率的平衡问题，如果配置了 maxWait，在连接不够用或争用时，unfair模式的ReentrantLock.tryLock方法存在严重不公平的现象，个别线程会等到超时了还获取不到连接。
以下是Druid各个版本锁的公平和效率的处理方式及效果。

我们可以手动进行Druid的配置。

dateSourse.setUseUnfairLock(true)

虽然因为公平输了，但Druid 做了很多优化，比如对PreparedStatementCache进行了优化，这对增强MySQL 5.5、Oracle、SQLserver、DB2的性能非常重要。另外Druid有非常稳定的 ExceptionSorter，包括Oracle、MySQL、Alibaba Oceanbase等。Druid 建立了强大的监控，温少认为它不仅仅是一个连接池，它可以做一个非常好的扩展，类似于Filter-Chain扩展。内置过滤器包括WallFilter、StatFilter、LogFilter，WallFilter可以防御SQL注人，
StatFilter可以用于性能监控，LogFilter可以输出SQL日志。温少也强调，在淘宝网大规模的高并发环境中，只有两个连接池能够很好地工作
-Druid和Jboss。在基准测试中，对于Druid或者HikariCP，建议每个池中都不要超过16个连接，在实际使用中不必如此，因为连接更多实际上可能会带来更好的吞吐量。如果做基准测试，在MySQL 中建议设置 useConfigs-maxPerformance。关于当年的“华山论剑”(在当年双方的旧版本上)有以下几点结论:
1）Druid建议不要设置maxWait，因为它会影响性能。但是不配置它意味着客户端可能等待时间没有限制。HikariCP可以毫不费力地在不牺牲性能的情况下获取最长等待时间。
2）Druid 没有实现未提交的连接的回滚归还。这意味着来自一个线程的没有提交的事务，可能会被使用相同连接的线程提交。这可能会为分析问题带来一些麻烦，SQL故障可能发生在代码完全不同的部分，在与原始SQL无关的类中，可能在原始代码运行几分钟后发生。
3）Druid 不会使用Connection重置SQL的警告，Druid也没有采取任何措施来防止网络分区事件。
在这次“华山论剑”中，有一个叫FutureElement的用户不断地帮温少讲话，主要观点是Druid 有阿里大数据量的验证而HikariCP 没有，并且质疑 HikariCP 没有被一些大公司使用过，也没有每天服务数十亿的用户量。
Brett Wooldridge 也做了回复，说明HikariCP在国外的确是被广泛使用的，
所示。他补充道，Wix.com 本身拥有超过1.09亿个网站，每天提供超过10亿个请求。Atlassian的产品拥有数百万客户，但是日常使用数据暂未相关公布。HikariCP 是Play框架、Slick、Joos 构建的应用程序的默认池，现在也是Spring Boot的默认池。HikariCP每月从maven中央仓库拉取超过300000次。
除了国内“海康威视”“51信用卡”“有赞”在使用HikariCP以外，目前Apache孵
化器项目Sharding Sphere也使用了HikariCP,它的 Sharding-Proxy在连接MySQL部分时直接使用了HikariCP作为数据库连接池，没有其他可选项。
HikariCP官方也提供了使用HikariCP的公司
Spring、Twitter、ApacheStorm 、Apache Hive、Hibernate等著名的产品都在使用。其中，Wix.com公司早在 2015 年 4 月的一次演讲中，就表明Wix公司当时就有超过6000万用户，静态存储大于2PB，拥有 3 个数据中心和 3 个云（谷歌、亚马逊、Azure),每天有15亿次HTTP请求。Wix
进行了基准测试,认可HikariCP 的性能，并决定从DBCP 切换到HikariCP。