前言

數據庫連接池在Java數據庫相關中間件產品群中，應該算是底層最基礎的一類產品，作為企業應用開發必不可少的組件，無數天才們為我們貢獻了一個又一個的優秀產品，它們有的隨時代發展，功成身退，有的則還在不斷迭代，老而彌堅，更有新生代產品，或性能無敵，或功能全面。接下來，就讓我們好好聊聊，“那些年，我們用過的數據庫連接池”。

第一代連接池

區分一個數據庫連接池是屬于第一代產品還是第二代產品的一個最重要特征就是看它在架構和設計時采用的線程模型，因為這直接影響的并發環境下存取數據庫連接的性能。一般來講采用單線程同步的架構設計的都屬于第一代連接池，而采用多線程異步架構的則屬于第二代。比較有代表性的就是Apache Commons DBCP，在1.x版本中，一直延續這單線程設計模型，到2.x版本才采用多線程模型。

用版本發布時間來辨別區分兩代產品，則一個偷懶的好方法。以下是這些常見數據庫連接池最新版本的發布時間：

數據庫連接池最新版本發布時間

c3p0	c3p0-0.9.5.2	on 9 Dec 2015
proxool	0.9.x	May 24, 2011
dbcp	2.1.1	2015-08-06
BoneCP	0.8.0	on 23 Oct 2013
TJP	tomcat9	Jan 10 2017
druid	1.0.28	2017-02-05
hikariCP	2.4.11	2017-01-28

從表中我們可以看到，c3p0、DBCP、Proxool和BoneCP都已經很久沒更新了，TJP(Tomcat JDBC Pool)，druid，hikariCPze則仍處于活躍的更新中，后者明顯就是我們所說的二代產品了。

已經徹底死掉的c3p0和proxool

我對c3p0還是很有感情的，因為在它是我使用的第一款數據庫連接池，在很長一段時間內，它一直是Java領域內數據庫連接池的代名詞，當年盛極一時的Hibernate都將其作為內置的數據庫連接池，可見業內對它的穩定行還是認可的。關于c3p0如何使用，可以借助于搜索引擎，這里就不再贅述了。c3p0功能簡單易用，穩定性好這是它的優點，但性能上的缺點卻讓它徹底被打入冷宮。c3p0的性能很差，差到即便是和同時代的產品相比，它也是墊底的（見圖一）。同時代的BoneCP更是直接以干掉它為自己的口號（官網號稱比c3p0快25倍），更不要說和后來的druid和HikariCP相比了。

正常來講，有問題很正常，改就是了，但c3p0最致命的問題就是架構設計過于復雜，讓重構變成了一項不可能完成的任務。隨著國內互聯網大潮的涌起，性能有硬傷的c3p0徹底的退出了歷史舞臺。

如果說c3p0被人嫌棄，是因為它自身架構設計的“原罪”，那proxool的冷門，則是與作者興趣的缺失有關。proxool最初在設計上另辟蹊徑，以JDBC驅動的身份為用戶提供連接池服務，這使得將proxool移植到現有代碼中別的十分容易，而且proxool還開創性的提供了連接池監控功能，讓它迅速的獲得了不少用戶的青睞。

但產品作者興趣的缺失，讓這款本來很有潛力的產品早早夭折。在github的項目首頁，作者寫到：“我從2006年之后就再沒碰過這個項目了，我甚至練Java都不用了…”，也許，proxool本來就是這位天才coder的練手之作，java本身也不是他的主力語言，但不論哪種原因，proxool都已經和c3p0一樣，鮮有人問津了。

This project is no longer actively maintained. I haven't used Proxool myself since 2006 and no longer even use Java. If the project has any chance of survival at all it would need to find a new maintainer. If anyone can recommend a good alternative I would be happy to mention it here. Alternatively, if anyone wants to contribute to this project then please create a pull request.

圖一：第一代連接池性能測試

咸魚翻身的dbcp

dbcp（DataBase Connection Pool）屬于Apache頂級項目Commons中的核心子項目（最早在Jakarta Commons里就有），在Apache的生態圈中的影響里十分廣泛，比如最為大家所熟知的tomcat就在內部集成了dbcp，實現JPA規范的OpenJPA，也是默認集成dbcp的。但dbcp并不是獨立實現連接池功能的，它內部依賴于Commons中的另一個子項目pool，連接池最核心的“池”，就是由pool組件提供的，因此，dbcp的性能實際上就是pool的性能，dbcp和pool的依賴關系如下表：

Apache Commons DBCPApache Commons Pool

v1.2.2	v1.3
v1.3	v1.5.4
v1.4	v1.5.4
v2.0.x	v2.2
v2.1.x	v2.4.2

可以看到，因為核心功能依賴于pool，所以dbcp本身只能做小版本的更新，真正大版本的更迭則完全依托于pool。有很長一段時間，pool都還是停留在1.x版本，這直接導致dbcp也更新乏力。很多依賴dbcp的應用在遇到性能瓶頸之后，別無選擇，只能將其替換掉，dbcp忠實的擁躉tomcat就在其tomcat 7.0版本中，自己重新設計開發出了一套連接池（Tomcat JDBC Pool）。好在，在2013年事情終于迎來轉機，13年9月Commons-Pool 2.0版本發布，14年2月份，dbcp也終于迎來了自己的2.0版本，基于新的線程模型全新設計的“池”讓dbcp重煥青春，雖然和新一代的連接池相比仍有一定差距，但差距并不大，dbcp 2.x版本已經穩穩達到了和新一代產品同級別的性能指標（見下圖）。

圖二：DBCP 2.x與新一代產品的性能對比

dbcp終于靠pool咸魚翻身，打了一個漂亮的翻身仗，但長時間的等待已經完全消磨了用戶的耐心，與新一代的產品項目相比，dbcp沒有任何優勢，試問，誰會在有選擇的前提下，去選擇那個并不優秀的呢？也許，現在還選擇dbcp2的唯一理由，就是情懷吧。

甘心赴死的BoneCP

在討論BoneCP這塊的內容之前，我們還是先來看看BoneCP作者自己是這么評價這款產品的：

BoneCP is a Java JDBC connection pool implementation that is tuned for high performance by minimizing lock contention to give greater throughput for your applications. It beats older connection pools such as C3P0 and DBCP but should now be considered deprecated in favour of HikariCP.

用我自己的話翻譯一下就是：俺是一個高性能的數據庫連接池，俺之所以這么牛逼是因為俺在實現的時候減少了鎖的使用，想當年，什么c3p0啊DBCP啊都被老子干趴了，但是現在為了支持HikariCP，俺選擇退出！也就是說，BoneCP的退出是它自己的選擇，但它又不像proxool是被拋棄的，它是作者經過深思熟慮后，做出的選擇，可以說BoneCP是“甘心赴死，殺身成仁”。那么問題來了，BoneCP究竟是不是像它自己形容的那樣牛逼？BoneCP和HikariCP之間究竟有啥聯系，能引得它主動“金盆洗手”？

先說性能，BoneCP自稱性能是c3p0的25倍，并提供了依照自己定義的測試案例，提供了一組圖片

單線程（1,000,000獲得及釋放數據庫連接請求，連接池大小20-50）

單線程

?

多線程（500線程分別獲取釋放100個鏈接，連接池大小50-200）

多線程1

?

多線程（500個線程每個100次獲得/釋放，連接池大小20-500）

多線程2

?

當然，以上圖片僅供參考，因為不同的參數配置，不同的應用環境，不同的測試案例，得到的結果肯定也不會相同，官網提供的數據，肯定是在最有利于自己表現的環境下得到的。但結合另外一份測試數據（第一幅圖），可以看到BoneCP的性能在第一代產品中，確實是屬于領先地位的。高性能的表現的秘訣也并不高深，一是極簡的設計，整個產品只有幾百k大小，二是重構內部pool的設計，減少鎖的使用，而這兩點優化原則，幾乎適用于所以的連接池產品。

值得一提的是，BoneCP本身并不“健全”，它的很多特征都依賴于Guava，因此也就和dbcp一樣，面臨更新乏力的問題。但現在，這些問題都不重要了，因為它賴以為傲的性能被HikariCP全面超越。HikariCP可以說是BoneCP的二代產品（HikariCP自己在官網上聲稱在BoneCP的基礎上，做了很多優化），它在設計思路上和BoneCP完全一致，主打的特征也是超強的性能表現，關于HikariCP的詳細內容，我將在下一章節介紹。

站在巨人肩膀上的第二代連接池

在數據庫連接池的產品群中，二代產品對一代產品的超越是顛覆性的，除了一些“歷史原因”，你很難再找到第二條理由說服自己不選擇二代產品，但任何成功都不是偶然的，二代產品的成功很大程度上得益于前代產品們打下的基礎，站在巨人的肩膀上，新一代的連接池的設計師們將這一項“工具化”的產品，推向了極致。其中，最具代表性的兩款產品是：

• HikariCP

• druid

性能無敵的HikariCP

剛剛在介紹BoneCP的時候多少已經提到過HikariCP了，作為連接池產品中的“性能殺手”，它的表現究竟如何呢，先來看下官網提供的數據：

圖三：HikariCP官網配圖1

不光性能強勁，穩定性也不差：

圖四：HikariCP官方配圖2

那它是怎么做到如此強勁的呢？官網給出的說明如下：

• 字節碼精簡：優化代碼，直到編譯后的字節碼最少，這樣，CPU緩存可以加載更多的程序代碼；

• 優化代理和攔截器：減少代碼，例如HikariCP的Statement proxy只有100行代碼，只有BoneCP的十分之一；

• 自定義數組類型（FastStatementList）代替ArrayList：避免每次get()調用都要進行range check，避免調用remove()時的從頭到尾的掃描；

• 自定義集合類型（ConcurrentBag）：提高并發讀寫的效率；

• 其他針對BoneCP缺陷的優化，比如對于耗時超過一個CPU時間片的方法調用的研究（但沒說具體怎么優化）。

可以看到，上述這幾點優化，針對的都是BoneCP現有的缺陷，優化到這份上，也難怪BoneCP的作者不想玩了。綜合現在能找到的資料來看，HakariCP在性能上的優勢應該是得到共識的，再加上它自身小巧的身形，在當前的“云時代、微服務”的背景下，HakariCP一定會得到更多人的青睞。

功能全面的druid

近幾年，阿里在開源項目上動作頻頻，除了有像fastJson這類工具型項目，更有像AliSQL這類的大型軟件，今天說的druid，就是阿里眾多優秀開源項目中的一個。它除了提供性能卓越的連接池功能外，還集成了sql監控，黑名單攔截等功能，用它自己的話說，druid是“為監控而生”。借助于阿里這個平臺的號召力，產品一經發布就贏得了大批用戶的擁躉，從用戶使用的反饋來看，druid也確實沒讓用戶失望。

相較于其他產品，druid另一個比較大的優勢，就是中文文檔比較全面（畢竟是國人的項目么），在github的wiki頁面，列舉了日常使用中可能遇到的問題，對一個新用戶來講，上面提供的內容已經足夠指導它完成產品的配置和使用了。

下圖為druid自己提供的性能測試數據：

圖五：druid提供的性能測試數據

最后，隱身的連接池

時至今日，雖然每個應用（需要RDBMS的）都離不開連接池，但在實際使用的時候，連接池已經可以做到“隱形”了。也就是說在通常情況下，連接池完成項目初始化配置之后，就再不需要再做任何改動了。不論你是選擇druid或是HikariCP，甚至是DBCP，它們都足夠穩定且高效！我們之前討論了很多關于連接池的性能的問題，但這些性能上的差異，是相交于其他連接池而言的，對整個系統應用來說，第二代連接池在使用過程中體會到的差別是微乎其微的，基本上不存在因為連接池的自身的配飾和使用導致系統性能下降的情況，除非是在單點應用的數據庫負載足夠高的時候（壓力測試的時候），但即便是如此，通用的優化的方式也是單點改集群，而不是在單點的連接池上死扣。

與我而言，連接池是我打開自己技術棧（Java存儲層相關）的起點，它有著作為起點的一切優點：使用廣泛，入門簡單，同時核心思想和實踐又足夠有料。本篇文章僅是一個開端，既是幫助我（和大家）理清楚市面上這些產品的現狀，同時也為為接下來馬上開始的“深入研究”鋪點底子。如果一定要說點什么感悟的話，那我只能再一次感嘆開源的力量以及社區對Java技術推廣的巨大助力。開源是一種精神，分享是一種態度，而這，正是Java語言幾十年依舊屹立不倒的原因。

總結

以上是生活随笔為你收集整理的大话数据库连接池简史，你都用过几个？的全部內容，希望文章能夠幫你解決所遇到的問題。

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