對現(xiàn)有的數(shù)據(jù)庫連接池做調(diào)研對比，綜合性能，可靠性，穩(wěn)定性，擴(kuò)展性等因素選出推薦出最優(yōu)的數(shù)據(jù)庫連接池 。
NOTE: 本文所有測試均是MySQL庫
1：性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免鎖競爭。
2：druid功能最為全面，sql攔截等功能，統(tǒng)計數(shù)據(jù)較為全面，具有良好的擴(kuò)展性。
3：綜合性能，擴(kuò)展性等方面，可考慮使用druid或者h(yuǎn)ikariCP連接池。
4：可開啟prepareStatement緩存，對性能會有大概20%的提升。
| 功能 | dbcp | druid | c3p0 | tomcat-jdbc | HikariCP |
| 是否支持PSCache | 是 | 是 | 是 | 否 | 否 |
| 監(jiān)控 | jmx | jmx/log/http | jmx,log | jmx | jmx |
| 擴(kuò)展性 | 弱 | 好 | 弱 | 弱 | 弱 |
| sql攔截及解析 | 無 | 支持 | 無 | 無 | 無 |
| 代碼 | 簡單 | 中等 | 復(fù)雜 | 簡單 | 簡單 |
| 更新時間 | 2015.8.6 | 2015.10.10 | 2015.12.09 | 2015.12.3 | |
| 特點 | 依賴于common-pool | 阿里開源，功能全面 | 歷史久遠(yuǎn)，代碼邏輯復(fù)雜，且不易維護(hù) | 優(yōu)化力度大，功能簡單，起源于boneCP | |
| 連接池管理 | LinkedBlockingDeque | 數(shù)組 | FairBlockingQueue | threadlocal+CopyOnWriteArrayList |
由于boneCP被hikariCP替代，并且已經(jīng)不再更新，boneCP沒有進(jìn)行調(diào)研。
proxool網(wǎng)上有評測說在并發(fā)較高的情況下會出錯，proxool便沒有進(jìn)行調(diào)研。
druid的功能比較全面，且擴(kuò)展性較好，比較方便對jdbc接口進(jìn)行監(jiān)控跟蹤等。
c3p0歷史悠久，代碼及其復(fù)雜，不利于維護(hù)。并且存在deadlock的潛在風(fēng)險。
環(huán)境配置：
| CPU | Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz，24core |
| msyql version | 5.5.46 |
| tomcat-jdbc version | 8.0.28 |
| HikariCP version | 2.4.3 |
| c3p0 Version | 0.9.5-pre8 |
| dbcpVersion | 2.0.1 |
| druidVersion | 1.0.5 |
1：獲取關(guān)閉連接性能測試
測試說明：
初始連接和最小連接均為5，最大連接為20。在borrow和return均不心跳檢測
其中打開關(guān)閉次數(shù)為: 100w次
測試用例和mysql在同一臺機(jī)器上面，盡量避免io的影響
使用mock和連接mysql在不同線程并發(fā)下的響應(yīng)時間
圖形：
mock性能數(shù)據(jù) (單位:ms)
| 5 | 20 | 50 | 100 | |
| tomcat-jdbc | 442 | 447 | 1,013 | 1,264 |
| c3p0 | 4,480 | 5,527 | 7,449 | 10,725 |
| dbcp | 676 | 689 | 867 | 1,292 |
| hikari | 38 | 33 | 38 | 30 |
| druid | 291 | 293 | 562 | 985 |
mysql性能數(shù)據(jù) (單位:ms)
| 5 | 20 | 50 | 100 | |
| tomcat-jdbc | 436 | 453 | 1,033 | 1,291 |
| c3p0 | 4,378 | 5,726 | 7,975 | 10,948 |
| dbcp | 671 | 679 | 897 | 1,380 |
| hikari | 96 | 82 | 87 | 78 |
| druid | 304 | 424 | 690 | 1,130 |
測試結(jié)果：
mock和mysql連接性能表現(xiàn)差不多，主要是由于初始化的時候建立了連接后期不再建立連接，和使用mock連接邏輯一致。
性能表現(xiàn)：hikariCP>druid>tomcat-jdbc>dbcp>c3p0。
hikariCP 的性能及其優(yōu)異。hikariCP號稱java平臺最快的數(shù)據(jù)庫連接池。
hikariCP在并發(fā)較高的情況下，性能基本上沒有下降。
c3p0連接池的性能很差，不建議使用該數(shù)據(jù)庫連接池。
hikariCP性能分析：
hikariCP通過優(yōu)化(concurrentBag，fastStatementList )集合來提高并發(fā)的讀寫效率。
hikariCP使用threadlocal緩存連接及大量使用CAS的機(jī)制，最大限度的避免lock。單可能帶來cpu使用率的上升。
從字節(jié)碼的維度優(yōu)化代碼。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）讓方法盡量在35個字節(jié)碼一下，來提升jvm的處理效率。
2：查詢一條語句性能測試
測試說明：
初始連接和最小連接均為8，最大連接為8。在borrow和return均不心跳檢測
查詢的次數(shù)為10w次，查詢的語句為 1：打開連接 2：執(zhí)行 ：select 1 3：關(guān)閉連接
測試用例和mysql在同一臺機(jī)器上面，盡量避免io的影響
圖形：
測試數(shù)據(jù)：
| 5 | 8 | 20 | 50 | 100 | |
| tomcat-jdbc | 2,178 | 1,495 | 1,769 | 1,818 | 1,858 |
| c3p0 | 3,237 | 3,451 | 4,488 | 5,994 | 7,906 |
| dbcp | 2,816 | 1,935 | 2,097 | 2,243 | 2,280 |
| hikari | 2,299 | 1,546 | 1,682 | 1,751 | 1,772 |
| druid | 2,297 | 1,551 | 1,800 | 1,977 | 2,032 |
測試結(jié)果：
在并發(fā)比較少的情況下，每個連接池的響應(yīng)時間差不多。是由于并發(fā)少，基本上沒有資源競爭。
在并發(fā)較高的情況下，隨著并發(fā)的升高，hikariCP響應(yīng)時間基本上沒有變動。
c3p0隨著并發(fā)的提高，性能急劇下降。
3：pscache性能對比
測試說明：
通過druid進(jìn)行設(shè)置pscache和不設(shè)置pscache的性能對比
初始連接和最小連接均為8，最大連接為8。在borrow和return均不心跳檢測。并且執(zhí)行的并發(fā)數(shù)為8.
查詢10w次。查詢流程為：1：建立連接，2：循環(huán)查詢preparestatement語句 3：close連接
測試用例和mysql在同一臺機(jī)器上面，盡量避免io的影響
測試數(shù)據(jù)：
| cache | 1,927 |
| not cache | 2,134 |
測試結(jié)果：
開啟psCache緩存,性能大概有20%幅度的提升?？煽紤]開啟pscache.
測試說明：
psCache是connection私有的，所以不存在線程競爭的問題，開啟pscache不會存在競爭的性能損耗。
psCache的key為prepare執(zhí)行的sql和catalog等，value對應(yīng)的為prepareStatement對象。開啟緩存主要是減少了解析sql的開銷。
聯(lián)系客服
