轉載自公眾號：工匠小豬豬的技術世界

摘要: 本文非原創，是筆者搜集了一些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

---

總結

以上是生活随笔為你收集整理的Springboot 2.0选择HikariCP作为默认数据库连接池的五大理由的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。