DBCP連接池介紹

# 初始化連接:連接池啟動時創建的初始化連接數量
initialSize=1
# 最小空閑連接:連接池中容許保持空閑狀態的最小連接數量,低于這個數量將創建新的連接,如果設置為0則不創建
minIdle=1
# 最大空閑連接:連接池中容許保持空閑狀態的最大連接數量,超過的空閑連接將被釋放,如果設置為負數表示不限制
maxIdle=2
# 最大活動連接:連接池在同一時間能夠分配的最大活動連接的數量,如果設置為非正數則表示不限制
maxActive=3
# 借出連接時不要測試，否則很影響性能  
testOnBorrow=false
# 指明連接是否被空閑連接回收器(如果有)進行檢驗.如果檢測失敗,則連接將被從池中去除.  
testWhileIdle=true
# 每X秒運行一次空閑連接回收器
timeBetweenEvictionRunsMillis=30000
# 在校驗線程完成校驗時會移除被遺漏的鏈接
removeAbandonedOnMaintenance=true
# 查詢校驗
validationQuery=SELECT 1

-----------------------------

DBCP連接池的自我檢測

-----------------------------

默認配置的DBCP連接池，是不對池中的連接做測試的，有時連接已斷開了，但DBCP連接池不知道，還以為連接是好的呢。

應用從池中取出這樣的連接訪問數據庫一定會報錯。這也是好多人不喜歡DBCP的原因。

問題例一：

MySQL8小時問題，Mysql服務器默認連接的“wait_timeout”是8小時，也就是說一個connection空閑超過8個小時，Mysql將自動斷開該 connection。

但是DBCP連接池并不知道連接已經斷開了，如果程序正巧使用到這個已經斷開的連接，程序就會報錯誤。

問題例二：

    以前還使用Sybase數據庫，由于某種原因，數據庫死了后重啟、或斷網后恢復。

    等了約10分鐘后，DBCP連接池中的連接還都是不能使用的（斷開的），訪問數據應用一直報錯，最后只能重啟Tomcat問題才解決 。

解決方案：

    方案1、定時對連接做測試，測試失敗就關閉連接。

    方案2、控制連接的空閑時間達到N分鐘，就關閉連接，（然后可再新建連接）。

    以上兩個方案使用任意一個就可以解決以述兩類問題。如果只使用方案2，建議 N <= 5分鐘。連接斷開后最多5分鐘后可恢復。

    也可混合使用兩個方案，建議 N = 30分鐘。

    下面就是DBCP連接池，同時使用了以上兩個方案的配置配置

    validationQuery = "SELECT 1"  驗證連接是否可用，使用的SQL語句

    testWhileIdle = "true"      指明連接是否被空閑連接回收器(如果有)進行檢驗.如果檢測失敗,則連接將被從池中去除.

    testOnBorrow = "false"   借出連接時不要測試，否則很影響性能

-----------------------------

DBCP連接池配置參數注意事項   

-----------------------------

maxIdle值與maxActive值應配置的接近。

因為，當連接數超過maxIdle值后，剛剛使用完的連接（剛剛空閑下來）會立即被銷毀。而不是我想要的空閑M秒后再銷毀起一個緩沖作用。這一點DBCP做的可能與你想像的不一樣。

若maxIdle應與maxActive相差較大，在高負載的系統中會導致頻繁的創建、銷毀連接，連接數在maxIdle與maxActive間快速頻繁波動，這不是我想要的。

高負載的系統的maxIdle值可以設置為與maxActive相同或設置為-1(-1表示不限制)，讓連接數量在minIdle與maxIdle間緩沖慢速波動。

timeBetweenEvictionRunsMillis建議設置值

initialSize="5"，會在tomcat一啟動時，創建5條連接，效果很理想。

但同時我們還配置了minIdle="10"，也就是說，最少要保持10條連接，那現在只有5條連接，哪什么時候再創建少的5條連接呢？

1、等業務壓力上來了， DBCP就會創建新的連接。

2、配置timeBetweenEvictionRunsMillis=“時間”,DBCP會啟用獨立的工作線程定時檢查，補上少的5條連接。銷毀多余的連接也是同理。

------------------------------

連接銷毀的邏輯

------------------------------

DBCP的連接數會在  0 - minIdle - maxIdle - maxActive  之間變化。變化的邏輯描述如下：

默認未配置initialSize(默認值是0)和timeBetweenEvictionRunsMillis參數時，剛啟動tomcat時，連接數是0。當應用有一個并發訪問數據庫時DBCP創建一個連接。

目前連接數量還未達到minIdle，但DBCP也不自動創建新連接已使數量達到minIdle數量（沒有一個獨立的工作線程來檢查和創建）。

隨著應用并發訪問數據庫的增多，連接數也增多，但都與minIdle值無關，很快minIdle被超越，minIdle值一點用都沒有。

直到連接的數量達到maxIdle值，這時的連接都是只增不減的。 再繼續發展，連接數再增多并超過maxIdle時，使用完的連接（剛剛空閑下來的）會立即關閉，總體連接的數量穩定在maxIdle但不會超過maxIdle。

但活動連接（在使用中的連接）可能數量上瞬間超過maxIdle，但永遠不會超過maxActive。

這時如果應用業務壓力小了，訪問數據庫的并發少了，連接數也不會減少（沒有一個獨立的線程來檢查和銷毀），將保持在maxIdle的數量。

默認未配置initialSize(默認值是0)，但配置了timeBetweenEvictionRunsMillis=“30000”（30秒）參數時，剛啟動tomcat時，連接數是0。馬上應用有一個并發訪問數據庫時DBCP創建一個連接。

目前連接數量還未達到minIdle，每30秒DBCP的工作線程檢查連接數是否少于minIdle數量，若少于就創建新連接直到達到minIdle數量。

隨著應用并發訪問數據庫的增多，連接數也增多，直到達到maxIdle值。這期間每30秒DBCP的工作線程檢查連接是否空閑了30分鐘，若是就銷毀。但此時是業務的高峰期，是不會有長達30分鐘的空閑連接的，工作線程查了也是白查，但它在工作。到這里連接數量一直是呈現增長的趨勢。

當連接數再增多超過maxIdle時，使用完的連接(剛剛空閑下來)會立即關閉，總體連接的數量穩定在maxIdle。停止了增長的趨勢。但活動連接（在使用中的連接）可能數量上瞬間超過maxIdle，但永遠不會超過maxActive。

這時如果應用業務壓力小了，訪問數據庫的并發少了，每30秒DBCP的工作線程檢查連接(默認每次查3條)是否空閑達到30分鐘(這是默認值)，若連接空閑達到30分鐘，就銷毀連接。這時連接數減少了，呈下降趨勢，將從maxIdle走向minIdle。當小于minIdle值時，則DBCP創建新連接已使數量穩定在minIdle，并進行著新老更替。

配置initialSize=“10”時，tomcat一啟動就創建10條連接。其它同上。

minIdle要與timeBetweenEvictionRunsMillis配合使用才有用,單獨使用minIdle不會起作用。