HiKariCP是數(shù)據(jù)庫連接池的一個后起之秀怔软，號稱性能最好螟蒸，可以完美地PK掉其他連接池茅坛。
官網(wǎng)：https://github.com/brettwooldridge/HikariCP
為何要使用HiKariCP观挎？這要先從BoneCP說起：
什么挪凑？不是有C3P0/DBCP這些成熟的數(shù)據(jù)庫連接池嗎荠瘪？一直用的好好的液样，為什么又搞出一個BoneCP來？因為巧还，傳說中BoneCP在快速這個特點上做到了極致鞭莽，官方數(shù)據(jù)是C3P0等的25倍左右。不相信麸祷？其實我也不怎么信澎怒。可是阶牍，有圖有真相芭缑妗（圖片來自BoneCP官網(wǎng)：http://jolbox.com/benchmarks.html）：
而且，網(wǎng)上對于BoneCP是好評如潮啊走孽，推薦的文章一搜一大堆惧辈。
然而，上Maven Repository網(wǎng)站（http://mvnrepository.com/artifact/com.jolbox/bonecp）查找有沒有最新版本的時候磕瓷，你會發(fā)現(xiàn)最新的是2013年10月份的（這么久沒新版本出來了盒齿？）。于是困食，再去BoneCP的Githut（https://github.com/wwadge/bonecp）上看看最近有沒有提交代碼边翁。卻發(fā)現(xiàn)，BoneCP的作者對于這個項目貌似已經(jīng)心灰意冷硕盹，說是要讓步給HikariCP了（有圖有真相）：
……什么符匾？又來一個CP？……什么是Hikari瘩例？
Hikari來自日文啊胶，是“光”（陽光的光，不是光禿禿的光）的意思垛贤。作者估計是為了借助這個詞來暗示這個CP速度飛快焰坪。不知作者是不是日本人，不過日本也有很多優(yōu)秀的碼農(nóng)南吮，聽說比特幣據(jù)說日本人搞出來的琳彩。。。
這個產(chǎn)品的口號是“快速露乏、簡單碧浊、可靠”。實際情況跟這個口號真的匹配嗎瘟仿？又是有圖有真相（Benchmarks又來了）：
這個圖箱锐，也間接地、再一次地證明了boneCP比c3p0強大很多劳较，當然驹止，跟“光”比起來，又弱了不少啊观蜗。
那么臊恋，這么好的P是怎么做到的呢？官網(wǎng)詳細地說明了HikariCP所做的一些優(yōu)化墓捻，總結如下：
字節(jié)碼精簡：優(yōu)化代碼抖仅，直到編譯后的字節(jié)碼最少，這樣砖第，CPU緩存可以加載更多的程序代碼撤卢；
優(yōu)化代理和攔截器：減少代碼，例如HikariCP的Statement proxy只有100行代碼梧兼，只有BoneCP的十分之一放吩；
自定義數(shù)組類型（FastStatementList）代替ArrayList：避免每次get()調(diào)用都要進行range check，避免調(diào)用remove()時的從頭到尾的掃描羽杰；
自定義集合類型（ConcurrentBag）：提高并發(fā)讀寫的效率渡紫；
其他針對BoneCP缺陷的優(yōu)化，比如對于耗時超過一個CPU時間片的方法調(diào)用的研究（但沒說具體怎么優(yōu)化）忽洛。
很多優(yōu)化的對比都是針對BoneCP的……哈哈腻惠。
（參考文章：https://github.com/brettwooldridge/HikariCP/wiki/Down-the-Rabbit-Hole）
幾個連接池的代碼量對比（代碼量越少，一般意味著執(zhí)行效率越高欲虚、發(fā)生bug的可能性越低）：
可是咏瑟，“黃婆賣瓜牧抵，自催自擂”這個俗語日本人也是懂得，于是歼秽，用戶的好評如潮也是有圖有真相：
還有第三方關于速度的測試：
也許你會說腌零，速度高梯找，如果不穩(wěn)定也是硬傷啊。于是益涧，關于穩(wěn)定性的圖也來了：
另外锈锤，關于可靠性方面，也是有實驗和數(shù)據(jù)支持的。對于數(shù)據(jù)庫連接中斷的情況久免，通過測試getConnection()浅辙，各種CP的不相同處理方法如下：
（所有CP都配置了跟connectionTimeout類似的參數(shù)為5秒鐘）
HikariCP：等待5秒鐘后，如果連接還是沒有恢復阎姥，則拋出一個SQLExceptions 異常记舆；后續(xù)的getConnection()也是一樣處理；
C3P0：完全沒有反應呼巴，沒有提示泽腮，也不會在“CheckoutTimeout”配置的時長超時后有任何通知給調(diào)用者；然后等待2分鐘后終于醒來了衣赶，返回一個error诊赊；
Tomcat：返回一個connection，然后……調(diào)用者如果利用這個無效的connection執(zhí)行SQL語句……結果可想而知府瞄；大約55秒之后終于醒來了豪筝，這時候的getConnection()終于可以返回一個error，但沒有等待參數(shù)配置的5秒鐘摘能，而是立即返回error续崖；
BoneCP：跟Tomcat的處理方法一樣；也是大約55秒之后才醒來团搞，有了正常的反應严望，并且終于會等待5秒鐘之后返回error了；
可見逻恐，HikariCP的處理方式是最合理的像吻。根據(jù)這個測試結果，對于各個CP處理數(shù)據(jù)庫中斷的情況复隆，評分如下：
參考文章：https://github.com/brettwooldridge/HikariCP/wiki/Bad-Behavior:-Handling-Database-Down
說得這么好拨匆，用起來會不會很麻煩啊，會不會有很多參數(shù)要配置才能有這樣的效果巴旆鳌惭每？答案是：不會。
如果之前用的是BoneCP配置的數(shù)據(jù)源亏栈，那么台腥，就簡單了，只需要把dataSource換一下绒北，稍微調(diào)整一下參數(shù)就行了：
BoneCP的數(shù)據(jù)源配置：
<!-- 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的數(shù)據(jù)源配置：
<!-- Hikari Datasource -->
<bean id="dataSourceHikari" class="com.zaxxer.hikari.HikariDataSource" destroy-method="shutdown">
<!-- <property name="driverClassName" value="${db.driverClass}" /> --> <!-- 無需指定黎侈，除非系統(tǒng)無法自動識別 -->
<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}" />
<!-- 連接只讀數(shù)據(jù)庫時配置為true， 保證安全 -->
<property name="readOnly" value="false" />
<!-- 等待連接池分配連接的最大時長（毫秒）闷游，超過這個時長還沒可用的連接則發(fā)生SQLException峻汉， 缺省:30秒 -->
<property name="connectionTimeout" value="30000" />
<!-- 一個連接idle狀態(tài)的最大時長（毫秒）贴汪，超時則被釋放（retired），缺省:10分鐘 -->
<property name="idleTimeout" value="600000" />
<!-- 一個連接的生命時長（毫秒）休吠，超時而且沒被使用則被釋放（retired）扳埂，缺省:30分鐘，建議設置比數(shù)據(jù)庫超時時長少30秒蛛碌，參考MySQL wait_timeout參數(shù)（show variables like '%timeout%';） -->
<property name="maxLifetime" value="1800000" />
<!-- 連接池中允許的最大連接數(shù)聂喇。缺省值：10；推薦的公式：((core_count * 2) + effective_spindle_count) -->
<property name="maximumPoolSize" value="15" />
</bean>
其中蔚携，很多配置都使用缺省值就行了希太，除了maxLifetime和maximumPoolSize要注意自己計算一下。
其他的配置（sqlSessionFactory酝蜒、MyBatis MapperScannerConfigurer誊辉、transactionManager等）統(tǒng)統(tǒng)不用變。
其他關于Datasource配置參數(shù)的建議：
Configure your HikariCP idleTimeout and maxLifeTime settings to be one minute less than the wait_timeout of MySQL.
對于有Java連接池的系統(tǒng)亡脑，建議MySQL的wait_timeout使用缺省的8小時（http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server）堕澄。
另外：對于web項目，記得要配置：destroy-method="shutdown"
