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

從上述結果可以看出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時間片的方法呼叫的研究（但沒說具體怎麼優化）。

理由一、程式碼量

幾個連線池的程式碼量對比（程式碼量越少，一般意味著執行效率越高、發生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處理資料庫中斷的情況，評分如下：

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

直接啟動即可 如圖

參考資料

原文地址：