为什么HikariCP被号称为性能最好的Java数据库连接池，怎样配置使用

HiKariCP是数据库连接池的一个后起之秀。号称性能最好。能够完美地PK掉其它连接池。

原文地址：http://blog.csdn.net/clementad/article/details/46928621

官网：https://github.com/brettwooldridge/HikariCP

为何要使用HiKariCP？这要先从BoneCP说起：

什么？不是有C3P0/DBCP这些成熟的数据库连接池吗？一直用的好好的。为什么又搞出一个BoneCP来？由于。传说中BoneCP在高速这个特点上做到了极致，官方数据是C3P0等的25倍左右。不相信？事实上我也不怎么信。但是。有图有真相啊（图片来自BoneCP官网：http://jolbox.com/benchmarks.html）：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

并且。网上对于BoneCP是好评如潮啊，推荐的文章一搜一大堆。

然而，上Maven Repository站点（http://mvnrepository.com/artifact/com.jolbox/bonecp）查找有没有最新版本号的时候。你会发现最新的是2013年10月份的（这么久没新版本号出来了？）。

于是。再去BoneCP的Githut（https://github.com/wwadge/bonecp）上看看近期有没有提交代码。却发现。BoneCP的作者对于这个项目貌似已经心灰意冷，说是要让步给HikariCP了（有图有真相）：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

……什么？又来一个CP？……什么是Hikari？

Hikari来自日文。是“光”（阳光的光，不是光秃秃的光）的意思。作者预计是为了借助这个词来暗示这个CP速度飞快。

不知作者是不是日本人，只是日本也有非常多优秀的码农，听说比特币据说日本人搞出来的。

。。

这个产品的口号是“高速、简单、可靠”。实际情况跟这个口号真的匹配吗？又是有图有真相（Benchmarks又来了）：

这个图，也间接地、再一次地证明了boneCP比c3p0强大非常多。当然。跟“光”比起来，又弱了不少啊。

那么，这么好的P是怎么做到的呢？官网具体地说明了HikariCP所做的一些优化，总结例如以下：

• 字节码精简：优化代码，直到编译后的字节码最少，这样，CPU缓存能够载入很多其它的程序代码。
• 优化代理和拦截器：降低代码，比如HikariCP的Statement proxy仅仅有100行代码，仅仅有BoneCP的十分之中的一个；
• 自己定义数组类型（FastStatementList）取代ArrayList：避免每次get()调用都要进行range check，避免调用remove()时的从头到尾的扫描；
• 自己定义集合类型（ConcurrentBag）：提高并发读写的效率；
• 其它针对BoneCP缺陷的优化，比方对于耗时超过一个CPU时间片的方法调用的研究（但没说详细怎么优化）。

非常多优化的对照都是针对BoneCP的……哈哈。

（參考文章：https://github.com/brettwooldridge/HikariCP/wiki/Down-the-Rabbit-Hole）

几个连接池的代码量对照（代码量越少。一般意味着运行效率越高、发生bug的可能性越低）：

但是，“黄婆卖瓜，自催自擂”这个俗语日本人也是懂得，于是。用户的好评如潮也是有图有真相：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

还有第三方关于速度的測试：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

或许你会说，速度高。假设不稳定也是硬伤啊。于是，关于稳定性的图也来了：

另外，关于可靠性方面，也是有实验和数据支持的。对于数据库连接中断的情况。通过測试getConnection()，各种CP的不同样处理方法例如以下：

（全部CP都配置了跟connectionTimeout类似的參数为5秒钟）

HikariCP：等待5秒钟后，假设连接还是没有恢复。则抛出一个SQLExceptions 异常。兴许的getConnection()也是一样处理；

C3P0：全然没有反应。没有提示，也不会在“CheckoutTimeout”配置的时长超时后有不论什么通知给调用者；然后等待2分钟后最终醒来了，返回一个error；

Tomcat：返回一个connection。然后……调用者假设利用这个无效的connection运行SQL语句……结果可想而知。大约55秒之后最终醒来了，这时候的getConnection()最终能够返回一个error，但没有等待參数配置的5秒钟，而是马上返回error；

BoneCP：跟Tomcat的处理方法一样。也是大约55秒之后才醒来，有了正常的反应，而且最终会等待5秒钟之后返回error了；

可见，HikariCP的处理方式是最合理的。

依据这个測试结果，对于各个CP处理数据库中断的情况，评分例如以下：

參考文章：https://github.com/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down

说得这么好。用起来会不会非常麻烦啊。会不会有非常多參数要配置才干有这种效果啊？答案是：不会。

假设之前用的是BoneCP配置的数据源，那么，就简单了。仅仅须要把dataSource换一下。略微调整一下參数即可了：

BoneCP的数据源配置：

 <!-- BoneCp Datasource -->
 <bean id="dataSourceBoneCp" class="com.jolbox.bonecp.BoneCPDataSource" destroy-method="close">
  <property name="driverClass" value="${db.driverClass}" />
  <property name="jdbcUrl" value="${db.url}" />
  <property name="username" value="${db.username}" />
  <property name="password" value="${db.password}" />
  <property name="idleConnectionTestPeriodInMinutes" value="2" />
  <property name="idleMaxAgeInMinutes" value="2" />
  <property name="maxConnectionsPerPartition" value="2" />
  <property name="minConnectionsPerPartition" value="0" />
  <property name="partitionCount" value="2" />
  <property name="acquireIncrement" value="1" />
  <property name="statementsCacheSize" value="100" />
  <property name="lazyInit" value="true"/>
  <property name="maxConnectionAgeInSeconds" value="20"/>
  <property name="defaultReadOnly" value="true"/>
 </bean>

HiKariCP的数据源配置：

 <!-- Hikari Datasource -->
 <bean id="dataSourceHikari" class="com.zaxxer.hikari.HikariDataSource"  destroy-method="shutdown">
  <!-- <property name="driverClassName" value="${db.driverClass}" /> --> <!-- 无需指定，除非系统无法自己主动识别 -->
  <property name="jdbcUrl" value="jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8" />
  <property name="username" value="${db.username}" />
  <property name="password" value="${db.password}" />
   <!-- 连接仅仅读数据库时配置为true。 保证安全 -->
  <property name="readOnly" value="false" />
  <!-- 等待连接池分配连接的最大时长（毫秒），超过这个时长还没可用的连接则发生SQLException。 缺省:30秒 -->
  <property name="connectionTimeout" value="30000" />
  <!-- 一个连接idle状态的最大时长（毫秒），超时则被释放（retired），缺省:10分钟 -->
  <property name="idleTimeout" value="600000" />
  <!-- 一个连接的生命时长（毫秒），超时并且没被使用则被释放（retired），缺省:30分钟。建议设置比数据库超时时长少30秒，參考MySQL wait_timeout參数（show variables like '%timeout%';） -->
  <property name="maxLifetime" value="1800000" />
  <!-- 连接池中同意的最大连接数。

缺省值：10；推荐的公式：((core_count * 2) + effective_spindle_count) -->
  <property name="maximumPoolSize" value="15" />
 </bean>

当中，非常多配置都使用缺省值即可了，除了maxLifetime和maximumPoolSize要注意自己计算一下。

其它的配置（sqlSessionFactory、MyBatis MapperScannerConfigurer、transactionManager等）统统不用变。

其它关于Datasource配置參数的建议：

Configure your HikariCP idleTimeout and maxLifeTime settings
to be one minute less than the wait_timeout of MySQL.

对于有Java连接池的系统，建议MySQL的wait_timeout使用缺省的8小时（http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server）。

另外：对于web项目，记得要配置：destroy-method="shutdown"

（原创文章，转载请注明转自Clement-Xu的csdn博客：http://blog.csdn.net/clementad/article/details/46928621）