什么是連接池
數(shù)據(jù)庫連接池負責分配、管理和釋放數(shù)據(jù)庫連接鸥咖，它允許應用程序重復使用一個現(xiàn)有的數(shù)據(jù)庫連接芋浮，而不是再重新建立一個。
為什么要使用連接池
數(shù)據(jù)庫連接是一種關鍵的有限的昂貴的資源贤惯，這一點在多用戶的網(wǎng)頁應用程序中體現(xiàn)得尤為突出。 一個數(shù)據(jù)庫連接對象均對應一個物理數(shù)據(jù)庫連接棒掠，每次操作都打開一個物理連接孵构，使用完都關閉連接，這樣造成系統(tǒng)的 性能低下烟很。
數(shù)據(jù)庫連接池的解決方案是在應用程序啟動時建立足夠的數(shù)據(jù)庫連接颈墅，并講這些連接組成一個連接池(簡單說：在一個“池”里放了好多半成品的數(shù)據(jù)庫聯(lián)接對象)棒假，由應用程序動態(tài)地對池中的連接進行申請、使用和釋放精盅。對于多于連接池中連接數(shù)的并發(fā)請求帽哑，應該在請求隊列中排隊等待。并且應用程序可以根據(jù)池中連接的使用率叹俏，動態(tài)增加或減少池中的連接數(shù)妻枕。
連接池技術盡可能多地重用了消耗內(nèi)存地資源，大大節(jié)省了內(nèi)存粘驰，提高了服務器地服務效率屡谐，能夠支持更多的客戶服務。通過使用連接池蝌数，將大大提高程序運行效率愕掏，同時，我們可以通過其自身的管理機制來監(jiān)視數(shù)據(jù)庫連接的數(shù)量顶伞、使用情況等饵撑。
傳統(tǒng)的連接機制與數(shù)據(jù)庫連接池的運行機制區(qū)別
不使用連接池流程
下面以訪問MySQL為例，執(zhí)行一個SQL命令唆貌，如果不使用連接池滑潘，需要經(jīng)過哪些流程。
不使用數(shù)據(jù)庫連接池的步驟：
TCP建立連接的三次握手
MySQL認證的三次握手
真正的SQL執(zhí)行
MySQL的關閉
TCP的四次握手關閉
可以看到锨咙，為了執(zhí)行一條SQL语卤，卻多了非常多我們不關心的網(wǎng)絡交互。
優(yōu)點：
實現(xiàn)簡單
缺點：
網(wǎng)絡IO較多
數(shù)據(jù)庫的負載較高
響應時間較長及QPS較低
應用頻繁的創(chuàng)建連接和關閉連接酪刀，導致臨時對象較多粹舵，GC頻繁
在關閉連接后，會出現(xiàn)大量TIME_WAIT 的TCP狀態(tài)（在2個MSL之后關閉）
使用連接池流程
使用數(shù)據(jù)庫連接池的步驟：
第一次訪問的時候骂倘，需要建立連接眼滤。 但是之后的訪問，均會復用之前創(chuàng)建的連接稠茂，直接執(zhí)行SQL語句柠偶。
優(yōu)點：
- 較少了網(wǎng)絡開銷
- 系統(tǒng)的性能會有一個實質(zhì)的提升
- 沒了麻煩的TIME_WAIT狀態(tài)
數(shù)據(jù)庫連接池的工作原理
連接池的工作原理主要由三部分組成情妖，分別為
- 連接池的建立
- 連接池中連接的使用管理
- 連接池的關閉
第一睬关、連接池的建立。一般在系統(tǒng)初始化時毡证，連接池會根據(jù)系統(tǒng)配置建立电爹，并在池中創(chuàng)建了幾個連接對象，以便使用時能從連接池中獲取料睛。連接池中的連接不能隨意創(chuàng)建和關閉丐箩，這樣避免了連接隨意建立和關閉造成的系統(tǒng)開銷摇邦。Java中提供了很多容器類可以方便的構(gòu)建連接池，例如Vector屎勘、Stack等施籍。
第二、連接池的管理概漱。連接池管理策略是連接池機制的核心丑慎，連接池內(nèi)連接的分配和釋放對系統(tǒng)的性能有很大的影響。其管理策略是：
當客戶請求數(shù)據(jù)庫連接時瓤摧，首先查看連接池中是否有空閑連接竿裂，如果存在空閑連接，則將連接分配給客戶使用照弥；如果沒有空閑連接腻异，則查看當前所開的連接數(shù)是否已經(jīng)達到最大連接數(shù)，如果沒達到就重新創(chuàng)建一個連接給請求的客戶这揣；如果達到就按設定的最大等待時間進行等待悔常，如果超出最大等待時間，則拋出異常給客戶给赞。
當客戶釋放數(shù)據(jù)庫連接時这嚣，先判斷該連接的引用次數(shù)是否超過了規(guī)定值，如果超過就從連接池中刪除該連接塞俱，否則保留為其他客戶服務姐帚。
該策略保證了數(shù)據(jù)庫連接的有效復用，避免頻繁的建立障涯、釋放連接所帶來的系統(tǒng)資源開銷罐旗。
第三、連接池的關閉唯蝶。當應用程序退出時九秀，關閉連接池中所有的連接，釋放連接池相關的資源粘我，該過程正好與創(chuàng)建相反鼓蜒。
連接池主要參數(shù)
使用連接池時，要配置一下參數(shù)
- 最小連接數(shù)：是連接池一直保持的數(shù)據(jù)庫連接,所以如果應用程序?qū)?shù)據(jù)庫連接的使用量不大,將會有大量的數(shù)據(jù)庫連接資源被浪費.
- 最大連接數(shù)：是連接池能申請的最大連接數(shù),如果數(shù)據(jù)庫連接請求超過次數(shù),后面的數(shù)據(jù)庫連接請求將被加入到等待隊列中,這會影響以后的數(shù)據(jù)庫操作
- 最大空閑時間
- 獲取連接超時時間
- 超時重試連接次數(shù)
連接池需要注意的點
1征字、并發(fā)問題
為了使連接管理服務具有最大的通用性都弹，必須考慮多線程環(huán)境，即并發(fā)問題匙姜。這個問題相對比較好解決畅厢，因為各個語言自身提供了對并發(fā)管理的支持，像java, c#等等氮昧，使用synchronized(java) lock(C#)關鍵字即可確保線程是同步的框杜。
2浦楣、事務處理
我們知道，事務具有原子性咪辱，此時要求對數(shù)據(jù)庫的操作符合“ALL-OR-NOTHING”原則,即對于一組SQL語句要么全做振劳，要么全不做。
我們知道當2個線程共用一個連接Connection對象油狂，而且各自都有自己的事務要處理時候澎迎，對于連接池是一個很頭疼的問題，因為即使Connection類提供了相應的事務支持选调，可是我們?nèi)匀徊荒艽_定那個數(shù)據(jù)庫操作是對應那個事務的夹供，這是由于我們有２個線程都在進行事務操作而引起的。為此我們可以使用每一個事務獨占一個連接來實現(xiàn)仁堪，雖然這種方法有點浪費連接池資源但是可以大大降低事務管理的復雜性哮洽。
3、連接池的分配與釋放
連接池的分配與釋放弦聂，對系統(tǒng)的性能有很大的影響鸟辅。合理的分配與釋放，可以提高連接的復用度莺葫，從而降低建立新連接的開銷匪凉，同時還可以加快用戶的訪問速度。
對于連接的管理可使用一個List捺檬。即把已經(jīng)創(chuàng)建的連接都放入List中去統(tǒng)一管理再层。每當用戶請求一個連接時，系統(tǒng)檢查這個List中有沒有可以分配的連接堡纬。如果有就把那個最合適的連接分配給他（如何能找到最合適的連接文章將在關鍵議題中指出）聂受；如果沒有就拋出一個異常給用戶，List中連接是否可以被分配由一個線程來專門管理捎后我會介紹這個線程的具體實現(xiàn)烤镐。
４蛋济、連接池的配置與維護
連接池中到底應該放置多少連接，才能使系統(tǒng)的性能最佳炮叶？系統(tǒng)可采取設置最小連接數(shù)（minConnection）和最大連接數(shù)（maxConnection）等參數(shù)來控制連接池中的連接碗旅。比方說，最小連接數(shù)是系統(tǒng)啟動時連接池所創(chuàng)建的連接數(shù)镜悉。如果創(chuàng)建過多祟辟，則系統(tǒng)啟動就慢，但創(chuàng)建后系統(tǒng)的響應速度會很快积瞒；如果創(chuàng)建過少川尖，則系統(tǒng)啟動的很快登下，響應起來卻慢茫孔。這樣叮喳，可以在開發(fā)時，設置較小的最小連接數(shù)缰贝，開發(fā)起來會快馍悟，而在系統(tǒng)實際使用時設置較大的，因為這樣對訪問客戶來說速度會快些剩晴。最大連接數(shù)是連接池中允許連接的最大數(shù)目锣咒，具體設置多少，要看系統(tǒng)的訪問量赞弥，可通過軟件需求上得到毅整。
如何確保連接池中的最小連接數(shù)呢？有動態(tài)和靜態(tài)兩種策略绽左。動態(tài)即每隔一定時間就對連接池進行檢測悼嫉，如果發(fā)現(xiàn)連接數(shù)量小于最小連接數(shù)，則補充相應數(shù)量的新連接,以保證連接池的正常運轉(zhuǎn)拼窥。靜態(tài)是發(fā)現(xiàn)空閑連接不夠時再去檢查戏蔑。
數(shù)據(jù)庫對比
第一、二代連接池
區(qū)分一個數(shù)據(jù)庫連接池是屬于第一代產(chǎn)品還是代二代產(chǎn)品有一個最重要的特征就是看它在架構(gòu)和設計時采用的線程模型鲁纠，因為這直接影響的是并發(fā)環(huán)境下存取數(shù)據(jù)庫連接的性能总棵。
一般來講采用單線程同步的架構(gòu)設計都屬于第一代連接池，二采用多線程異步架構(gòu)的則屬于第二代改含。比較有代表性的就是Apache Commons DBCP情龄，在1.x版本中，一直延續(xù)著單線程設計模式捍壤，到2.x才采用多線程模型刃唤。
用版本發(fā)布時間來辨別區(qū)分兩代產(chǎn)品，則一個偷懶的好方法白群。以下是這些常見數(shù)據(jù)庫連接池最新版本的發(fā)布時間：
從表中可以看出尚胞，C3P0已經(jīng)很久沒有更新了。DBCP更新速度很慢帜慢，基本處于不活躍狀態(tài)笼裳，而Druid和HikariCP處于活躍狀態(tài)的更新中，這就是我們說的二代產(chǎn)品了粱玲。
二代產(chǎn)品對一代產(chǎn)品的超越是顛覆性的躬柬，除了一些“歷史原因”，你很難再找到第二條理由說服自己不選擇二代產(chǎn)品抽减，但任何成功都不是偶然的允青，二代產(chǎn)品的成功很大程度上得益于前代產(chǎn)品們打下的基礎，站在巨人的肩膀上卵沉，新一代的連接池的設計師們將這一項“工具化”的產(chǎn)品颠锉，推向了極致法牲。其中，最具代表性的兩款產(chǎn)品是：
- HikariCP
- Druid
徹底死掉的C3P0
C3P0是我使用的第一款數(shù)據(jù)庫連接池琼掠，在很長一段時間內(nèi)拒垃，它一直是Java領域內(nèi)數(shù)據(jù)庫連接池的代名詞，當年盛極一時的Hibernate都將其作為內(nèi)置的數(shù)據(jù)庫連接池瓷蛙，可以業(yè)內(nèi)對它的穩(wěn)定性還是認可的悼瓮。C3P0功能簡單易用，穩(wěn)定性好這是它的優(yōu)點艰猬，但是性能上的缺點卻讓它徹底被打入冷宮横堡。C3P0的性能很差，差到即便是同時代的產(chǎn)品相比它也是墊底的冠桃，更不用和Druid翅萤、HikariCP等相比了。正常來講腊满，有問題很正常套么，改就是了，但c3p0最致命的問題就是架構(gòu)設計過于復雜碳蛋，讓重構(gòu)變成了一項不可能完成的任務胚泌。隨著國內(nèi)互聯(lián)網(wǎng)大潮的涌起，性能有硬傷的c3p0徹底的退出了歷史舞臺肃弟。
咸魚翻身的DBCP
DBCP（DataBase Connection Pool）屬于Apache頂級項目Commons中的核心子項目（最早在Jakarta Commons里就有）,在Apache的生態(tài)圈中的影響里十分廣泛玷室，比如最為大家所熟知的Tomcat就在內(nèi)部集成了DBCP，實現(xiàn)JPA規(guī)范的OpenJPA笤受，也是默認集成DBCP的穷缤。但DBCP并不是獨立實現(xiàn)連接池功能的，它內(nèi)部依賴于Commons中的另一個子項目Pool箩兽，連接池最核心的“池”津肛，就是由Pool組件提供的，因此汗贫，DBCP的性能實際上就是Pool的性能身坐，DBCP和Pool的依賴關系如下表：
可以看到，因為核心功能依賴于Pool落包，所以DBCP本身只能做小版本的更新部蛇，真正大版本的更迭則完全依托于pool。有很長一段時間咐蝇，pool都還是停留在1.x版本涯鲁，這直接導致DBCP也更新乏力。很多依賴DBCP的應用在遇到性能瓶頸之后涮俄，別無選擇僧凤，只能將其替換掉，DBCP忠實的擁躉tomcat就在其tomcat 7.0版本中镜粤，自己重新設計開發(fā)出了一套連接池（Tomcat JDBC Pool）幢踏。好在髓需，在2013年事情終于迎來轉(zhuǎn)機许师，13年9月Commons-Pool 2.0版本發(fā)布房蝉，14年2月份，DBCP也終于迎來了自己的2.0版本微渠，基于新的線程模型全新設計的“池”讓DBCP重煥青春搭幻，雖然和新一代的連接池相比仍有一定差距，但差距并不大逞盆，DBCP2.x版本已經(jīng)穩(wěn)穩(wěn)達到了和新一代產(chǎn)品同級別的性能指標（見下圖）檀蹋。
DBCP終于靠Pool咸魚翻身，打了一個漂亮的翻身仗云芦，但長時間的等待已經(jīng)完全消磨了用戶的耐心俯逾，與新一代的產(chǎn)品項目相比，DBCP沒有任何優(yōu)勢舅逸，試問桌肴，誰會在有選擇的前提下，去選擇那個并不優(yōu)秀的呢琉历？也許坠七，現(xiàn)在還選擇DBCP2的唯一理由，就是情懷吧旗笔。
性能無敵的HikariCP
HikariCP號稱“性能殺手”（It’s Faster）彪置，它的表現(xiàn)究竟如何呢，先來看下官網(wǎng)提供的數(shù)據(jù)：
不光性能強勁蝇恶，穩(wěn)定性也不差：
那它是怎么做到如此強勁的呢拳魁？官網(wǎng)給出的說明如下：
- 字節(jié)碼精簡：優(yōu)化代碼，直到編譯后的字節(jié)碼最少撮弧，這樣的猛，CPU緩存可以加載更多的程序代碼；
- 優(yōu)化代理和攔截器：減少代碼想虎，例如HikariCP的Statement proxy只有100行代碼卦尊；
- 自定義數(shù)組類型（FastStatementList）代替ArrayList：避免每次get()調(diào)用都要進行range check，避免調(diào)用remove()時的從頭到尾的掃描舌厨；
- 自定義集合類型（ConcurrentBag）：提高并發(fā)讀寫的效率岂却；
- 其他缺陷的優(yōu)化，比如對于耗時超過一個CPU時間片的方法調(diào)用的研究（但沒說具體怎么優(yōu)化）。
可以看到躏哩，上述這幾點優(yōu)化署浩，和現(xiàn)在能找到的資料來看，HakariCP在性能上的優(yōu)勢應該是得到共識的扫尺，再加上它自身小巧的身形筋栋，在當前的“云時代、微服務”的背景下正驻，HakariCP一定會得到更多人的青睞弊攘。
功能全面的Druid
近幾年，阿里在開源項目上動作頻頻姑曙，除了有像fastJson襟交、dubbo這類項目，更有像AliSQL這類的大型軟件伤靠，今天說的Druid捣域，就是阿里眾多優(yōu)秀開源項目中的一個。它除了提供性能卓越的連接池功能外宴合，還集成了SQL監(jiān)控焕梅，黑名單攔截等功能，用它自己的話說卦洽，Druid是“為監(jiān)控而生”贞言。借助于阿里這個平臺的號召力，產(chǎn)品一經(jīng)發(fā)布就贏得了大批用戶的擁躉逐样，從用戶使用的反饋來看蜗字，Druid也確實沒讓用戶失望。
相較于其他產(chǎn)品脂新，Druid另一個比較大的優(yōu)勢挪捕，就是中文文檔比較全面（畢竟是國人的項目么），在github的wiki頁面争便，列舉了日常使用中可能遇到的問題级零，對一個新用戶來講，上面提供的內(nèi)容已經(jīng)足夠指導它完成產(chǎn)品的配置和使用了滞乙。
下圖為Druid自己提供的性能測試數(shù)據(jù)：
現(xiàn)在項目開發(fā)中奏纪，我還是比較傾向于使用Durid，它不僅僅是一個數(shù)據(jù)庫連接池斩启，它還包含一個ProxyDriver序调，一系列內(nèi)置的JDBC組件庫，一個SQL Parser兔簇。
Druid 相對于其他數(shù)據(jù)庫連接池的優(yōu)點
強大的監(jiān)控特性发绢，通過Druid提供的監(jiān)控功能硬耍，可以清楚知道連接池和SQL的工作情況。
a. 監(jiān)控SQL的執(zhí)行時間边酒、ResultSet持有時間经柴、返回行數(shù)、更新行數(shù)墩朦、錯誤次數(shù)坯认、錯誤堆棧信息；
b. SQL執(zhí)行的耗時區(qū)間分布氓涣。什么是耗時區(qū)間分布呢牛哺？比如說，某個SQL執(zhí)行了1000次春哨，其中01毫秒?yún)^(qū)間50次荆隘，110毫秒800次恩伺，10100毫秒100次赴背，1001000毫秒30次，1~10秒15次晶渠，10秒以上5次凰荚。通過耗時區(qū)間分布，能夠非常清楚知道SQL的執(zhí)行耗時情況褒脯；
c. 監(jiān)控連接池的物理連接創(chuàng)建和銷毀次數(shù)便瑟、邏輯連接的申請和關閉次數(shù)、非空等待次數(shù)番川、PSCache命中率等到涂。方便擴展。Druid提供了Filter-Chain模式的擴展API颁督，可以自己編寫Filter攔截JDBC中的任何方法践啄，可以在上面做任何事情，比如說性能監(jiān)控沉御、SQL審計屿讽、用戶名密碼加密、日志等等吠裆。
Druid集合了開源和商業(yè)數(shù)據(jù)庫連接池的優(yōu)秀特性伐谈，并結(jié)合阿里巴巴大規(guī)模苛刻生產(chǎn)環(huán)境的使用經(jīng)驗進行優(yōu)化试疙。
總結(jié)
時至今日诵棵，雖然每個應用（需要RDBMS的）都離不開連接池，但在實際使用的時候祝旷，連接池已經(jīng)可以做到“隱形”了履澳。也就是說在通常情況下柱徙，連接池完成項目初始化配置之后，就再不需要再做任何改動了奇昙。不論你是選擇Druid或是HikariCP护侮，甚至是DBCP，它們都足夠穩(wěn)定且高效储耐！之前討論了很多關于連接池的性能的問題羊初，但這些性能上的差異，是相較于其他連接池而言的什湘，對整個系統(tǒng)應用來說长赞，第二代連接池在使用過程中體會到的差別是微乎其微的，基本上不存在因為連接池的自身的配飾和使用導致系統(tǒng)性能下降的情況闽撤，除非是在單點應用的數(shù)據(jù)庫負載足夠高的時候（壓力測試的時候）得哆，但即便是如此，通用的優(yōu)化的方式也是單點改集群哟旗，而不是在單點的連接池上死扣贩据。
參考：
http://rainbowhorse.site/2018/02/06/%E5%A4%A7%E8%AF%9D%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%9E%E6%8E%A5%E6%B1%A0/
https://blog.csdn.net/frightingforambition/article/details/25464129
https://juejin.im/entry/58fb03220ce4630061233c98
