數(shù)據(jù)庫(kù)連接池的原理是什么

背景介紹

數(shù)據(jù)庫(kù)連接池和線程池等池技術(shù)存在的意義都是為了解決資源的重復(fù)利用問題。在計(jì)算機(jī)里，創(chuàng)建一個(gè)新的資源往往開銷是非常大的。而池技術(shù)可以統(tǒng)一分配，管理某一類資源，它允許我們的程序可以重復(fù)的使用這個(gè)資源，只有在極端情況下（比如連接池滿）才會(huì)創(chuàng)建新的資源。

數(shù)據(jù)庫(kù)連接這種資源尤其昂貴，它的創(chuàng)建開銷很大，大量的創(chuàng)建連接和釋放操作對(duì)程序的影響非常明顯。

數(shù)據(jù)庫(kù)連接池正是針對(duì)這個(gè)問題提出來(lái)的。

實(shí)現(xiàn)原理

需要注意的是，我們下面提供的幾種實(shí)現(xiàn)方式都是基于簡(jiǎn)單的原型，目的是帶你了解連接池實(shí)現(xiàn)的一些基本原理。真實(shí)的數(shù)據(jù)庫(kù)連接池技術(shù)需要考慮更多復(fù)雜的細(xì)節(jié)。

所以下面這些代碼都是不能在生產(chǎn)上直接使用的。

實(shí)現(xiàn)的時(shí)候會(huì)用到java.sql.Connection，由于這個(gè)只是一個(gè)接口無(wú)法創(chuàng)建實(shí)例，為了演示方便，我繼承這個(gè)接口寫了一個(gè)簡(jiǎn)單的測(cè)試類，只是在commit方法里加了延時(shí)模擬提交。

實(shí)現(xiàn)方式1

很容易馬上想到的一種方案，我們用一個(gè)map存放連接對(duì)象，需要的時(shí)候從map里拿來(lái)用就可以了。

這里需要主要，盡管我們使用了線程安全的ConcurrentHashMap來(lái)存放連接資源，getConnection方法依然要加上synchronized關(guān)鍵字來(lái)避免并發(fā)問題。這一點(diǎn)是最容易忽略的。

試想一下，假設(shè)在某個(gè)場(chǎng)景下，我們希望某個(gè)應(yīng)用的多個(gè)線程共享連接資源。

假設(shè)有2個(gè)線程同時(shí)執(zhí)行到了pool.containsKey(key)，然后都返回false，那這兩個(gè)線程都會(huì)創(chuàng)建連接。雖然ConcurrentHashMap的put方法只會(huì)加入其中一個(gè)，但還是生成了1個(gè)多余的連接。

原因在于，盡管ConcurrentHashMap本身每個(gè)操作都是線程安全的，但是當(dāng)這些操作組合在一起使用的時(shí)候，就無(wú)法保證原子性了，所以有可能帶來(lái)并發(fā)的問題。

這里友情提示下，面試經(jīng)常會(huì)遇到這個(gè)考點(diǎn)哦。

實(shí)現(xiàn)方式2

第二種實(shí)現(xiàn)方式是在1的基礎(chǔ)上進(jìn)行的優(yōu)化。1的方案有個(gè)問題就是每次訪問getConnection都要加鎖，釋放鎖，效率比較低。

第二種方案是利用java并發(fā)包里的Future機(jī)制來(lái)解決并發(fā)場(chǎng)景創(chuàng)建多余連接的問題。

我們來(lái)捋一捋這個(gè)實(shí)現(xiàn)會(huì)不會(huì)有并發(fā)的問題。假設(shè)兩個(gè)線程同時(shí)進(jìn)入else分支，在代碼的28行ConcurrentHashMap可以確保只有一個(gè)線程會(huì)執(zhí)行，也就是只會(huì)加入一個(gè)task。其它的線程都不會(huì)加入成功。

所以只有一個(gè)線程connectionFutureTask == null，這個(gè)線程開始異步執(zhí)行創(chuàng)建連接的任務(wù)，而其它的線程則會(huì)調(diào)用FutureTask的get方法直接獲取結(jié)果。

實(shí)現(xiàn)方式3

1和2的實(shí)現(xiàn)方式還存在一個(gè)問題， 多個(gè)線程獲取到的其實(shí)同一個(gè)連接。這種方案在某些場(chǎng)景下是不允許的。比如spring數(shù)據(jù)庫(kù)的事務(wù)管理器對(duì)于每個(gè)事務(wù)的處理線程都要求獨(dú)立的連接資源。

下面的方案基于鏈表結(jié)構(gòu)，有比較完整的獲取，釋放的操作，不同的線程可以拿到獨(dú)立的連接資源。

注意到這個(gè)方案我們?cè)讷@取連接的時(shí)候引入了超時(shí)時(shí)間，如果該方法能夠在一段時(shí)間內(nèi)獲取到結(jié)果，那么將結(jié)果立刻返回，反之，超時(shí)返回默認(rèn)結(jié)果。

druid連接池的實(shí)現(xiàn)原理

了解了實(shí)現(xiàn)連接池的大概思路，我們可以來(lái)繼續(xù)學(xué)習(xí)下市面上比較成熟的連接池產(chǎn)品。這其中阿里巴巴開源的druid開源連接池就是一個(gè)代表。

Druid作為java領(lǐng)域最好的連接池技術(shù)之一，連接池本身只是它的一部分功能。除此之外，它還還要配套的監(jiān)控功能。當(dāng)然這個(gè)不是我們本文的重點(diǎn)。

先來(lái)看看在代碼中如何使用Druid連接池，

所以繼續(xù)深入到是DataSource里的getConnection方法，

init方法主要的功能是根據(jù)配置文件初始化連接池，它內(nèi)部會(huì)生成一些真正的物理連接然后放入一個(gè)數(shù)組里。當(dāng)然這個(gè)方法要保證只會(huì)被調(diào)用一次。

繼續(xù)往下看，最終會(huì)調(diào)用到getConnectionInternal這個(gè)私有方法，

紅色圈出的部分是核心，根據(jù)傳入的等待時(shí)間走不同的分支，我們來(lái)看看takeLast方法。

代碼邏輯也比較清楚，poolCount是連接池的目前的可用連接數(shù)量。

如果為0，就通過emptySignal喚醒生產(chǎn)者線程創(chuàng)建新的連接，同時(shí)當(dāng)前線程掛起等待notEmpty的信號(hào)。notEmptyWaitCount維護(hù)的就是正在等待的消費(fèi)者數(shù)量。

如果不為0，就從數(shù)組中取出最后一個(gè)連接返回。有人可能會(huì)有疑問，這里返回的是DruidConnectionHolder，不是Connection啊？

其實(shí)看下前者的定義你就明白了，

DruidConnectionHolder封裝了Connection以及連接的datasource信息，還有多個(gè)statement等，方面進(jìn)行統(tǒng)一管理。