摘要: 本文非原創，是筆者蒐集了一些HikariCP相關的資料整理給大家的介紹，主要講解了爲什麼sb2選擇了HikariCP以及HikariCP爲什麼這麼快。
Springboot2默認數據庫連接池選擇了HikariCP爲何選擇HikariCP理由一、代碼量理由二、口碑理由三、速度理由四、穩定性理由五、可靠性HikariCP爲什麼這麼快優化並精簡字節碼更好的併發集合類實現使用FastList替代ArrayListHikariCP與Druid相比哪個更好？Springboot2快速上手參考資料
Spring Boot 2默認數據庫連接池選擇了HikariCP
默認的數據庫連接池由Tomcat換成HikariCP. 如果在一個Tomcat應用中用spring.datasource.type來強制使用Hikari連接池, 則可以去掉這個override.
爲何選擇HikariCP
HiKariCP是數據庫連接池的一個後起之秀，號稱性能最好，可以完美地PK掉其他連接池，是一個高性能的JDBC連接池，基於BoneCP做了不少的改進和優化。其作者還有另外一個開源作品——高性能的JSON解析器HikariJSON。
它，超快，快到連Spring Boot 2都宣佈支持了。
代碼體積更是少的可憐，130kb。
https://github.com/brettwooldridge/HikariJSON
爲何要使用HiKariCP？這要先從BoneCP說起：
什麼？不是有C3P0/DBCP這些成熟的數據庫連接池嗎？一直用的好好的，爲什麼又搞出一個BoneCP來？因爲，傳說中BoneCP在快速這個特點上做到了極致，官方數據是C3P0等的25倍左右。不相信？其實我也不怎麼信。可是，有圖有真相啊（圖片來自BoneCP官網：http://jolbox.com/benchmarks.html）：
從上述結果可以看出HikariCP的性能遠高於c3p0、tomcat等連接池，以致後來BoneCP作者都放棄了維護，在Github項目主頁推薦大家使用HikariCP。另外，Spring Boot將在2.0版本中把HikariCP作爲其默認的JDBC連接池。
PS:需要指出的是，上圖中的數據是HikariCP作者對各個連接池調用DataSource.getConnection()、Connection.close()、Connection.prepareStatement()、Statement.execute()、Statement.close()方法的性能測試結果。
而且，網上對於BoneCP是好評如潮啊，推薦的文章一搜一大堆。
然而，上Maven Repository網站（http://mvnrepository.com/artifact/com.jolbox/bonecp）查找有沒有最新版本的時候，你會發現最新的是2013年10月份的（這麼久沒新版本出來了？）。於是，再去BoneCP的Githut（https://github.com/wwadge/bonecp）上看看最近有沒有提交代碼。卻發現，BoneCP的作者對於這個項目貌似已經心灰意冷，說是要讓步給HikariCP了（有圖有真相）：
……什麼？又來一個CP？……什麼是Hikari？
Hikari來自日文，是“光”（陽光的光，不是光禿禿的光）的意思。作者估計是爲了藉助這個詞來暗示這個CP速度飛快。不知作者是不是日本人，不過日本也有很多優秀的碼農，聽說比特幣據說日本人搞出來的。。。
這個產品的口號是“快速、簡單、可靠”。實際情況跟這個口號真的匹配嗎？又是有圖有真相（Benchmarks又來了）：
這個圖，也間接地、再一次地證明了boneCP比c3p0強大很多，當然，跟“光”比起來，又弱了不少啊。
那麼，這麼好的是怎麼做到的呢？官網詳細地說明了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的可能性越低）：
理由二、口碑
可是，“黃婆賣瓜，自催自擂”這個俗語日本人也是懂得，於是，用戶的好評如潮也是有圖有真相：
理由三、速度
還有第三方關於速度的測試：
理由四、穩定性
也許你會說，速度高，如果不穩定也是硬傷啊。於是，關於穩定性的圖也來了：
理由五、可靠性
另外，關於可靠性方面，也是有實驗和數據支持的。對於數據庫連接中斷的情況，通過測試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
HikariCP爲什麼這麼快
JDBC連接池的實現並不複雜，主要是對JDBC中幾個核心對象Connection、Statement、PreparedStatement、CallableStatement以及ResultSet的封裝與動態代理。接下來從幾個方面來看看HikariCP爲什麼這麼快：
優化並精簡字節碼
HikariCP利用了一個第三方的Java字節碼修改類庫Javassist來生成委託實現動態代理。動態代理的實現在ProxyFactory類，源碼如下：
發現這些代理方法中只有一行直接拋異常的代碼，註釋寫着“Body is replaced (injected) by JavassistProxyFactory”，其實方法body中的代碼是在編譯時調用JavassistProxyFactory才生成的，主要代碼見下圖：
之所以使用Javassist生成動態代理，是因爲其速度更快，相比於JDK Proxy生成的字節碼更少，精簡了很多不必要的字節碼。
ConcurrentBag：更好的併發集合類實現
ConcurrentBag的實現借鑑於C#中的同名類，是一個專門爲連接池設計的lock-less集合，實現了比LinkedBlockingQueue、LinkedTransferQueue更好的併發性能。ConcurrentBag內部同時使用了ThreadLocal和CopyOnWriteArrayList來存儲元素，其中CopyOnWriteArrayList是線程共享的。ConcurrentBag採用了queue-stealing的機制獲取元素：首先嚐試從ThreadLocal中獲取屬於當前線程的元素來避免鎖競爭，如果沒有可用元素則再次從共享的CopyOnWriteArrayList中獲取。此外，ThreadLocal和CopyOnWriteArrayList在ConcurrentBag中都是成員變量，線程間不共享，避免了僞共享(false sharing)的發生。
使用FastList替代ArrayList
FastList是一個List接口的精簡實現，只實現了接口中必要的幾個方法。JDK ArrayList每次調用get()方法時都會進行rangeCheck檢查索引是否越界，FastList的實現中去除了這一檢查，只要保證索引合法那麼rangeCheck就成爲了不必要的計算開銷(當然開銷極小)。此外，HikariCP使用List來保存打開的Statement，當Statement關閉或Connection關閉時需要將對應的Statement從List中移除。通常情況下，同一個Connection創建了多個Statement時，後打開的Statement會先關閉。ArrayList的remove(Object)方法是從頭開始遍歷數組，而FastList是從數組的尾部開始遍歷，因此更爲高效。
HikariCP與Druid相比哪個更好？
有些用戶給了druid這樣的評論：
不評論，一個追求性能，一個偏向監控，直接看之前有人給HikariCP提的關於跟Druid對比分析的issue吧。HikariCP作者對Druid做了測試並給出了測試結果數據，Druid作者溫少也對此作了評論。Issue鏈接：
https://github.com/brettwooldridge/HikariCP/issues/232
筆者個人的觀點是，hikariCP可以提供監控功能的，比如metrics，可以參見筆者的這篇文章 【追光者系列】HikariCP連接池監控指標實戰。
另外，監控方面，skywalking、pinpoint、mycat這些agent也是可以做到的，以後service mesh普及了更加可以監控了，比如sharding-jdbc也可以做監控，datamesh，sidecar也可以做監控的。
Springboot2快速上手
說得這麼好，用起來會不會很麻煩啊，會不會有很多參數要配置纔能有這樣的效果啊？答案是：不會。
springboot 2.0 默認連接池就是Hikari了，所以引用parents後不用專門加依賴
配置一下就好
# jdbc_config datasource spring.datasource.driver-class-name=com.mysql.jdbc.Driver spring.datasource.url=jdbc:mysql://127.0.0.1:3306/datebook?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&useSSL=false&zeroDateTimeBehavior=convertToNull spring.datasource.username=root spring.datasource.password=root # Hikari will use the above plus the following to setup connection pooling spring.datasource.type=com.zaxxer.hikari.HikariDataSource spring.datasource.hikari.minimum-idle=5 spring.datasource.hikari.maximum-pool-size=15 spring.datasource.hikari.auto-commit=true spring.datasource.hikari.idle-timeout=30000 spring.datasource.hikari.pool-name=DatebookHikariCP spring.datasource.hikari.max-lifetime=1800000 spring.datasource.hikari.connection-timeout=30000 spring.datasource.hikari.connection-test-query=SELECT 1 |
直接啓動即可 如圖
參考資料
https://blog.csdn.net/clementad/article/details/46928621
原文地址：