DBCP連接池介紹
-----------------------------
目前 DBCP 有兩個版本分別是 1.3 和 1.4。
DBCP 1.3 版本需要運行於 JDK 1.4-1.5 ，支持 JDBC 3。
DBCP 1.4 版本需要運行於 JDK 1.6 ，支持 JDBC 4。
1.3和1.4基於同一套源代碼，含有所有的bug修復和新特性。因此在選擇DBCP版本的時候，要看你用的是什么JDK版本。
DBCP1.2版本性能一般，比c3p0差挺多。DBCP1.4和1.3，配合（依賴）commons pool 1.6的jar包,各方面功能、性能推進到新的高峰。相對1.2版本提高不少。超越(或相當)了c3p0.建議使用DBCP1.4或1.3 + commons pool 1.6
Tomcat7 中保留DBCP連接池，以兼容已有應用。並提供了新的Tomcat JDBC pool作為DBCP的可選替代。新出的Tomcat JDBC pool，據說比DBCP 1.4要好，未接觸，也不在本文討論范圍內。
DBCP連接池配置參數講解
-----------------------------
一、Apache官方DBCP文檔給出的配置示例：
可參見：http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
<Context>
<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
username="javauser" password="javadude" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/javatest"/>
</Context>
tomcat JDBC連接池配置示例，自動檢查連接的可用性，dbcp定時檢測連接，dbcp自動重連的配置
- <Resource
- name="jdbc/TestDB" JNDI數據源的name，查找時用：java:comp/env/jdbc/TestDB
- type="javax.sql.DataSource"
- factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
- driverClassName="com.mysql.jdbc.Driver" JDBC驅動類
- url="jdbc:mysql://localhost:3306/test?
- characterEncoding=UTF-8&autoReconnectForPools=true&rewriteBatchedStatements=true&useCursorFetch=true&defaultFetchSize=20" 數據庫URL地址
- username="xxx" 訪問數據庫用戶名
- password="xxx" 訪問數據庫的密碼
- maxWait="3000" 從池中取連接的最大等待時間，單位ms.
- initialSize="10" 初始化連接
- maxIdle="60" 最大空閑連接
- minIdle="10" 最小空閑連接
- maxActive="80" 最大活動連接
- validationQuery = "SELECT 1" 驗證使用的SQL語句
- testWhileIdle = "true" 指明連接是否被空閑連接回收器(如果有)進行檢驗.如果檢測失敗,則連接將被從池中去除.
- testOnBorrow = "false" 借出連接時不要測試，否則很影響性能
- timeBetweenEvictionRunsMillis = "30000" 每30秒運行一次空閑連接回收器
- minEvictableIdleTimeMillis = "1800000" 池中的連接空閑30分鍾后被回收
- numTestsPerEvictionRun="10" 在每次空閑連接回收器線程(如果有)運行時檢查的連接數量
- removeAbandoned="true" 連接泄漏回收參數，當可用連接數少於3個時才執行
- removeAbandonedTimeout="180" 連接泄漏回收參數，180秒，泄露的連接可以被刪除的超時值
- />
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" 借出連接時不要測試，否則很影響性能
timeBetweenEvictionRunsMillis = "30000" 每30秒運行一次空閑連接回收器
minEvictableIdleTimeMillis = "1800000" 池中的連接空閑30分鍾后被回收,默認值就是30分鍾。
numTestsPerEvictionRun="3" 在每次空閑連接回收器線程(如果有)運行時檢查的連接數量，默認值就是3.
解釋：
配置timeBetweenEvictionRunsMillis = "30000"后，每30秒運行一次空閑連接回收器（獨立線程）。並每次檢查3個連接，如果連接空閑時間超過30分鍾就銷毀。銷毀連接后，連接數量就少了，如果小於minIdle數量，就新建連接，維護數量不少於minIdle，過行了新老更替。
testWhileIdle = "true" 表示每30秒，取出3條連接，使用validationQuery = "SELECT 1" 中的SQL進行測試 ，測試不成功就銷毀連接。銷毀連接后，連接數量就少了，如果小於minIdle數量，就新建連接。
testOnBorrow = "false" 一定要配置，因為它的默認值是true。false表示每次從連接池中取出連接時，不需要執行validationQuery = "SELECT 1" 中的SQL進行測試。若配置為true,對性能有非常大的影響，性能會下降7-10倍。所在一定要配置為false.
每30秒，取出numTestsPerEvictionRun條連接（本例是3，也是默認值），發出"SELECT 1" SQL語句進行測試 ，測試過的連接不算是“被使用”了，還算是空閑的。連接空閑30分鍾后會被銷毀。
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不會起作用。
Tomcat中配置DBCP連接池
-----------------------------
Tomcat自帶DBCP的包，是$CATALINA_HOME/lib/tomcat-dbcp.jar。
tomcat-dbcp.jar含有commons pool、commons DBCP兩個包的內容。但只含有與連接池有關的類。
數據源配置在context.xml文件中， 要在tomcat的lib目錄中放jdbc 驅動包
數據源配置在server.xml的host中，不需要在tomcat的lib目錄中放jdbc 驅動包，只使用工程中的jdbc驅動包
JNDI配置:更改tomcat的server.xml或context.xml
全局的數據源：
如果需要配置全局的 Resource，則在server.xml的GlobalNamingResources節點里加入Resource，再在Context節點里加入ResourceLink的配置。
全局的resource只是為了重用，方便所有該tomcat下的web工程的數據源管理，但如果你的tomcat不會同時加載多個web工程，也就是說一個tomcat只加載一個web工程時，是沒有必要配置全局的resource的。
每個web工程一個數據源：
在$CATALINA_HOME/conf/context.xml的根節點Context里加入Resource配置。這種配置方法，你在context.xml配置了一個數據源，但Tomcat中有同時運行着5個工程，那了就壞事兒了，這個在Tomcat啟動時數據源被創建了5份，每個工程1份數據源。連接數會是你配置的參數的5倍。
只有在你的Tomcat只加載一個web工程時,才可以直接以context.xml配置數據源。
<Resource name="jdbc/testDB" //指定的jndi名稱，會用於spring數據源bean的配置和ResourceLink的配置
type="javax.sql.DataSource" //數據源類型，使用標准的javax.sql.DataSource
driverClassName="com.mysql.jdbc.Driver" //JDBC驅動器
url="jdbc:mysql://localhost:3306/test" //數據庫URL地址
username="test" //數據庫用戶名
password="test" //數據庫密碼
maxIdle="40" //最大的空閑連接數
maxWait="4000" //當池的數據庫連接已經被占用的時候，最大等待時間（單位：毫秒）
maxActive="40" //連接池當中最大的數據庫連接
removeAbandoned="true"
removeAbandonedTimeout="180"
logAbandoned="true" //被丟棄的數據庫連接是否做記錄，以便跟蹤
factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" />
這里的factory指的是該Resource 配置使用的是哪個數據源配置類，這里使用的是tomcat自帶的標准數據源Resource配置類，這個類也可以自己寫，實現javax.naming.spi.ObjectFactory 接口即可。某些地方使用的commons-dbcp.jar中的org.apache.commons.dbcp.BasicDataSourceFactory，如果使用這個就需把commons-dbcp.jar及其依賴的jar包，都放在tomcat的lib下，光放在工程的WEB-INF/lib下是不夠的。
ResourceLink 的配置有多種：
1)tomcat安裝目錄下的conf/context.xml，把全局的resource直接公開給該tomcat下的所有web工程，在Context節點中加入：
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
不建議在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置數據源，原因上面已說明了。
2)tomcat安裝目錄下的conf/server.xml，該方法可以指定把哪些source綁定到哪個web工程下。
<!-- 新增，第一行為加載的工程配置，第二行是該工程需要的ResourceLink配置 -->
<context docBase="/web/webapps/phoenix" path="" reloadable="false">
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
</context>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置數據源。
3)安裝目錄下的conf/localhost/下建立一個xml文件，文件名是<yourAppName>.xml。比如工程名為test，則該xml名為test.xml。
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
</context>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置數據源。
4)tomcat安裝目錄下的\webapps\test\META-INF\context.xml的Context節點中增加:
<ResourceLink global="jdbc/testMDB" name="jdbc/testMDB" type="javax.sql.DataSource"/>
也可在此文件中，不使用<ResourceLink/>，而使用<Resource/>直接配置數據源。
本文內容都在tomcat6.0上運行測試過，還下載了commons DBCP的源碼，加入了跟蹤日志，用於驗證本文的理論。
連接池排名（純個人看法）
-----------------------------
Tomcat JDBC pool
DBCP 1.4
c3p0 速度不錯
BoneCP 速度不錯，但會啟用很多附加線程做回收、關閉工作。
Proxool 在高並發時出現異常
DBCP 1.2
DBPool 最差，墊底。
參考文檔《Java連接池評估報告》