DBCP鏈接池配置參數詳解

initialSize="10"     

     初始化鏈接，鏈接池啓動時建立的初始化鏈接數量（默認值爲0）

maxActive="80"     
     最大活動鏈接，鏈接池中可同時鏈接的最大的鏈接數（默認值爲8）

minIdle="10"     
     最小空閒鏈接，鏈接池中最小的空閒的鏈接數，低於這個數量會被建立新的鏈接（默認爲0，該參數越接近maxIdle，性能越好，由於鏈接的建立和銷燬，都是須要消耗資源的；可是不能太大，由於在機器很空閒的時候，也會建立低於minidle個數的鏈接，相似於jvm參數中的Xmn設置）

maxIdle="60"     
     最大空閒鏈接，鏈接池中最大的空閒的鏈接數，超過的空閒鏈接將被釋放，若是設置爲負數表示不限制（默認爲8個，maxIdle不能設置過小，由於假如在高負載的狀況下，鏈接的打開時間比關閉的時間快，會引發鏈接池中idle的個數上升超過maxIdle，而形成頻繁的鏈接銷燬和建立，相似於jvm參數中的Xmx設置)

maxWait="3000"     
     從池中取鏈接的最大等待時間，單位ms.當沒有可用鏈接時，鏈接池等待鏈接釋放的最大時間，超過該時間限制會拋出異常，若是設置-1表示無限等待（默認爲無限）

validationQuery = "SELECT 1"     
     驗證使用的SQL語句

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

testOnBorrow = "false"     
     借出鏈接時不要測試，不然很影響性能。必定要配置，由於它的默認值是true。false表示每次從鏈接池中取出鏈接時，不須要執行validationQuery = "SELECT 1" 中的SQL進行測試。若配置爲true,對性能有很是大的影響，性能會降低7-10倍。

timeBetweenEvictionRunsMillis = "30000"
     每30秒運行一次空閒鏈接回收器，配置timeBetweenEvictionRunsMillis = "30000"後，每30秒運行一次空閒鏈接回收器（獨立線程）。並每次檢查3個鏈接，若是鏈接空閒時間超過30分鐘就銷燬。銷燬鏈接後，鏈接數量就少了，若是小於minIdle數量，就新建鏈接，維護數量很多於minIdle，過行了新老更替。

minEvictableIdleTimeMillis = "1800000"
     池中的鏈接空閒30分鐘後被回收

numTestsPerEvictionRun="3"
     在每次空閒鏈接回收器線程(若是有)運行時檢查的鏈接數量

removeAbandoned="true"
     鏈接泄漏回收參數，當可用鏈接數少於3個時才執行

removeAbandonedTimeout="180"
     鏈接泄漏回收參數，180秒，泄露的鏈接能夠被刪除的超時值

 

注意事項

maxIdle值與maxActive值應配置的接近
     當鏈接數超過maxIdle值後，剛剛使用完的鏈接（剛剛空閒下來）會當即被銷燬。而不是想要的空閒M秒後再銷燬起一個緩衝做用。若maxIdle與maxActive相差較大，在高負載的系統中會致使頻繁的建立、銷燬鏈接，鏈接數在maxIdle與maxActive間快速頻繁波動，這不是想要的。高負載系統的maxIdle值能夠設置爲與maxActive相同或設置爲-1(-1表示不限制)，讓鏈接數量在minIdle與maxIdle間緩衝慢速波動。

timeBetweenEvictionRunsMillis建議設置值
minIdle要與timeBetweenEvictionRunsMillis配合使用纔有用,單獨使用minIdle不會起做用。

initialSize="5"，會在tomcat一啓動時，建立5條鏈接，效果很理想。但同時咱們還配置了minIdle="10"，也就是說，最少要保持10條鏈接，那如今只有5條鏈接，哪何時再建立少的5條鏈接呢？
     一、等業務壓力上來了， DBCP就會建立新的鏈接。
     二、配置timeBetweenEvictionRunsMillis=「時間」,DBCP會啓用獨立的工做線程定時檢查，補上少的5條鏈接。銷燬多餘的鏈接也是同理。

 

 

鏈接銷燬的邏輯

DBCP的鏈接數會在initialSize - 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，並進行着新老更替。