幾個主流的Java連接池整理
池(Pool)技術在一定程度上可以明顯優化服務器應用程序的性能，提高程序執行效率和降低系統資源開銷。這裏所說的池是一種廣義上的池，比如數據庫連接池、線程池、內存池、對象池等。其中，對象池可以看成保存對象的容器，在進程初始化時創建一定數量的對象。需要時直接從池中取出一個空閒對象，用完後並不直接釋放掉對象，而是再放到對象池中以方便下一次對象請求可以直接複用。其他幾種池的設計思想也是如此，池技術的優勢是，可以消除對象創建所帶來的延遲，從而提高系統的性能。
要了解Java連接池我們先要了解數據庫連接池（connection pool）的原理，Java連接池正是數據庫連接池在Java上的應用。——我們知道，對於共享資源，有一個很著名的設計模式：資源池（Resource Pool）。
該模式正是爲了解決資源的頻繁分配﹑釋放所造成的問題。爲解決上述問題，可以採用數據庫連接池技術。數據庫連接池的基本思想就是爲數據庫連接建立一個“緩衝池”。預先在緩衝池中放入一定數量的連接，當需要建立數據庫連接時，只需從“緩衝池”中取出一個，使用完畢之後再放回去。我們可以通過設定連接池最大連接數來防止系統無盡的與數據庫連接。更爲重要的是我們可以通過連接池的管理機制監視數據庫的連接的數量﹑使用情況，爲系統開發﹑測試及性能調整提供依據。
C3P0是一個開放源代碼的JDBC連接池，它在lib目錄中與Hibernate一起發佈,包括了實現jdbc3和jdbc2擴展規範說明的Connection 和Statement 池的DataSources 對象。（主頁：http://sourceforge.net/projects/c3p0/）
BoneCP 是一個開源的快速的 JDBC 連接池。BoneCP很小，只有四十幾K（運行時需要log4j和Google Collections的支持，這二者加起來就不小了），而相比之下 C3P0 要六百多K。另外個人覺得 BoneCP 有個缺點是，JDBC驅動的加載是在連接池之外的，這樣在一些應用服務器的配置上就不夠靈活。當然，體積小並不是 BoneCP 優秀的原因，BoneCP 到底有什麼突出的地方呢，請看看性能測試報告。（主頁：http://jolbox.com/）
DBCP （Database Connection Pool）是一個依賴Jakarta commons-pool對象池機制的數據庫連接池，Tomcat的數據源使用的就是DBCP。目前 DBCP 有兩個版本分別是 1.3 和 1.4。1.3 版本對應的是 JDK 1.4-1.5 和 JDBC 3，而1.4 版本對應 JDK 1.6 和 JDBC 4。因此在選擇版本的時候要看看你用的是什麼 JDK 版本了，功能上倒是沒有什麼區別。（主頁：http://commons.apache.org/dbcp/）
Proxool是一個Java SQL Driver驅動程序，提供了對你選擇的其它類型的驅動程序的連接池封裝。可以非常簡單的移植到現存的代碼中。完全可配置。快速，成熟，健壯。可以透明地爲你現存的JDBC驅動程序增加連接池功能。
數據庫連接是一種關鍵的有限的昂貴的資源，這一點在多用戶的網頁應用程序中體現得尤爲突出。對數據庫連接的管理能顯著影響到整個應用程序的伸縮性和健壯性，影響到程序的性能指標。數據庫連接池正是針對這個問題提出來的。數據庫連接池負責分配、管理和釋放數據庫連接，它允許應用程序重複使用一個現有的數據庫連接，而再不是重新建立一個；釋放空閒時間超過最大空閒時間的數據庫連接來避免因爲沒有釋放數據庫連接而引起的數據庫連接遺漏。這項技術能明顯提高對數據庫操作的性能。
Java中常用的數據庫連接池有：DBCP 、C3P0、BoneCP、Proxool、DDConnectionBroker、DBPool、XAPool、Primrose、SmartPool、MiniConnectionPoolManager及Druid等。
Java開源數據連接池: http://www.open-open.com/20.htm
Hibernate常用三種連接池的配置：http://tieba.baidu.com/f?kz=70604644
幾種常用java連接池:http://hi.baidu.com/tangyudee/blog/item/f8bdb43decca892571cf6ced.html
感覺在介紹之前有必要闡述一下連接池的幾個概念，有助於後邊一些文字的理解。
最原始的數據庫使用就是打開一個連接並進行使用，使用過後一定要關閉連接釋放資源。由於頻繁的打開和關閉連接對jvm包括數據庫
都有一定的資源負荷，尤其應用壓力較大時資源佔用比較多容易產生性能問題。由此使用連接池的作用就顯現出來，他的原理其實不復雜：
先打開一定數量的數據庫連接，當使用的時候分配給調用者，調用完畢後返回給連接池，注意返回給連接池後這些連接並不會關閉，而是
準備給下一個調用者進行分配。由此可以看出連接池節省了大量的數據庫連接打開和關閉的動作，對系統性能提升的益處不言而喻。
幾個概念：
最小連接--應用啓動後隨即打開的連接數以及後續最小維持的連接數。
最大連接數--應用能夠使用的最多的連接數
連接增長數--應用每次新打開的連接個數
舉個例子說明連接池的運作：
假設設置了最小和最大的連接爲10，20，那麼應用一旦啓動則首先打開10個數據庫連接，但注意此時數據庫連接池的正在使用數字爲0--因爲你並沒有使用這些連接，而空閒的數量則是10。然後你開始登錄，假設登錄代碼使用了一個連接進行查詢，那麼此時數據庫連接池的正在使用數字爲1、空閒數爲9，這並不需要從數據庫打開連接--因爲連接池已經準備好了10個給你留着呢。登錄結束了，當前連接池的連接數量是多少？當然是0，因爲那個連接隨着事務的結束已經返還給連接池了。然後同時有11個人在同一秒進行登錄，會發生什麼：連接池從數據庫新申請（打開）了一個連接，連同另外的10個一併送出，這個瞬間連接池的使用數是11個，不過沒關係正常情況下過一會兒又會變成0。如果同時有21個人登錄呢？那第21個人就只能等前面的某個人登錄完畢後釋放連接給他。這時連接池開啓了20個數據庫連接--雖然很可能正在使用數量的已經降爲0，那麼20個連接會一直保持嗎？當然不，連接池會在一定時間內關閉一定量的連接還給數據庫，在這個例子裏數字是20-10=10，因爲只需要保持最小連接數就好了，而這個時間週期也是連接池裏配置的。
好了，基本概念說完了，言歸正傳進行比較了。
首先說明的一點，爲了應用便於移植以及可配置的角度，建議還是使用jndi統一進行連接池的配置。怎麼配置其實網上都有很多例子，
這裏簡單舉個例子（使用spring框架）：
首先在應用的上下文定義中配置jndi名稱，如一個resource.xml文件，裏邊的寫法
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/myapp</value></property>
</bean>
注意dataSource這個bean在dao層(hibernate或jdbc)的配置文件裏需要作爲dataSource名稱的屬性配置到所有bean中
其中“jdbc/myds”這個就是jndi名稱了，下一步就是在應用服務器連接池裏進行數據庫連接以及對應的jndi配置了
一 開源數據連接池
1 dbcp
dbcp可能是使用最多的開源連接池，原因大概是因爲配置方便，而且很多開源和tomcat應用例子都是使用的這個連接池吧。
這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。這個連接池的配置參見附件壓縮包中的:dbcp.xml
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性還是可以，不過速度稍慢，在大併發量的壓力下穩定性
有所下降，此外不提供連接池監控
2 c3p0
c3p0是另外一個開源的連接池，在業界也是比較有名的，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的:c3p0.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性相當不錯，在大併發量的壓力下穩定性也有一定保證，
此外不提供連接池監控。
3 proxool
proxool這個連接池可能用到的人比較少，但也有一定知名度，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的：proxool.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性有一定問題，有一個需要長時間跑批的任務場景任務，同樣的代碼
在另外2個開源連接池中成功結束，但在proxool中出現異常退出。
但是proxool有一個優勢--連接池監控，這是個很誘人的東西，大概的配置方式就是在web.xml中添加如下定義：
<servlet>
<servlet-name>admin</servlet-name>
<servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>admin</servlet-name>
<url-pattern>/admin</url-pattern>
</servlet-mapping>
並在應用啓動後訪問：http://localhost:8080/myapp/admin這個url即可監控
不過proxool本身的包在監測使用中會有編碼問題，附件中有一個
解決此問題的包，參見附件壓縮包中的：proxool-0.9.0RC3.jar。另外需要jdk1.5以上的環境。
總結時刻：
綜上所述，這幾種開源連接池各有優劣，推薦使用c3p0，經檢驗這種連接池性能穩定，承壓能力強。而proxool儘管有明顯的性能問題，
但由於它具備監控功能，因此建議在開發測試時使用，有助於確定是否有連接沒有被關掉，可以排除一些代碼的性能問題。
二 商業中間件連接池
上面列舉了幾種開源的連接池，其實可以肯定的說，如果條件允許使用weblogic和websphere等中間件，那麼不要猶豫，一定要
使用這些商業級別的中間件所自帶的數據庫連接池，他們的性能以及調配和開源的不在一個量級，舉個例子，曾經有一個項目，數據量比較大，同樣的代碼應用，在3種開源的連接池裏都多少出現過系統異常，而weblogic和websphere的連接池則正常運行，當然後來發現代碼有一定瑕疵，但也側面說明了商業連接池的強大。
1 weblogic的連接池
weblogic 8 是一個讓人使用起來很輕鬆方便的應用服務器軟件，但是到了9簡直就是折磨，不知道是bea是怎麼想的，oracle收購了bea以後出了10，比9強不少，但是最喜歡的還是8。。。
題外話不說了，就以8.1版本介紹一下他的數據庫連接池（其實10的配置也差不多）
首先是連接池的基本設置，這個不講了，網上有很多教程。然後進入Data Sources菜單配置數據源裏邊的JNDI Name，要和之前在應用配置中的一致：jdbc/myapp。
然後是連接池一些具體項目的配置，包括設置最小（Initial Capacity），最大（ Maximum Capacity）連接，以及
每次連接增加時需要一次性增加多少連接（Capacity Increment）。Allow Shrinking（是否把不用的連接退還數據庫以保持最小連接數--這個就可以參見之前的連接池闡述的例子進行理解了）。
另外還有幾個有意思的選項Test Reserved Connections：對取得的連接進行測試，Test Released Connections：對釋放的連接進行測試。有人會問了，這個有什麼用啊？
不知道大家在項目中有沒有遇到java報連接失效的異常，反正我碰到過，只有在系統壓力大的時候纔出現。而有了這個選項就不用擔心這個問題了--因爲連接池已經幫你測試了，一旦檢查到連接是無效的他會廢棄掉還給數據庫，只給你有效的。不過這個連接失效的異常其實多半是應用的不嚴謹造成的，我們更因該關心應代碼的問題--但起碼weblogic想到幫你彌補一下，是不是很貼心：）
另外一個重要功能當然是連接池監控：monitor選項卡里可以看到使用情況，有人又要問了，沒有什麼指標啊，別忘了custom view這個功能鏈接哦：）
有以下指標：當前連接數、曾經達到的峯值、可以使用的連接數、等待的連接數、從數據庫打開的連接數、曾經關閉的連接數。。。其中前3項是我最關注的
使用評價：在具體項目應用中，此連接池的持續運行的穩定性很強，在大併發量的壓力下性能也相當優秀，另外在一些異常情況下連接池裏的連接也能夠及時釋放。
連接池監控一目瞭然，及時到位。
2 websphere的連接池
還是先來段題外話：記得有人說過，websphere只有版本6以後纔算是websphere，個人很贊同。websphere 5以及以前的版本。。。還是忘了吧。
其實websphere的連接池秉承ibm一貫的風格：功能強大，使用複雜：）
進入控制檯使用“JDBC提供程序”功能菜單進行連接池的基本配置，一路下來，不同的數據庫配置方式不盡相同，最奇怪的是還要單獨手工加上user和password參數，如果沒有
資料指導的話還真是摸不着頭腦。這些基本設置還是網上找吧很多的。連接池設置完還需要設置數據源，jndi名字一樣與之前的對應：jdbc/myapp
高級設置包括初始化連接數，最大連接，連接有效性檢查，不使用超時。。其實這些都和weblogic中的連接池配置大致一樣。
連接池監控：使用運行監控菜單，裏邊會有一個監控項目選擇，選jdbc監控即可，可惡的是一開始彈出什麼服務器操作系統需要安裝什麼圖形化控件，選擇是那麼就得去找到控件在操作系統（linux）下安裝，然後很多的依賴組件都沒有。。。搞了半天才發現選擇否，監控數據以及圖形一樣能出來嘛，真是要怒了。
雖然經過一番波折但是監控的內容還是很強大的，就連接池來說一樣包括當前連接數、曾經達到的峯值、可以使用的連接數、從數據庫打開的連接數、曾經關閉的連接數。。。其中前3項是我最關注的，比較奇怪的現象是應用剛啓動的時候已開啓的連接數量竟然沒有達到初始定義的連接數量，不清楚websphere是怎麼個計算機制。
另外在壓力大的時候可使用的連接數會是負數，當時很奇怪，想想也瞭然了，那個負數肯定是排隊等待的數量了
使用評價：在具體項目應用中，此連接池的持續運行的穩定性相當強，在大併發量的壓力下性能也足夠優秀，另外在一些異常情況下連接池裏的連接能夠及時釋放，
連接池監控配置有些複雜，但是配置好後各項指標一目瞭然並且有圖形顯示
總結時刻：
這兩種商業級別的連接池都給我留下深刻印象，功能強大，使用穩定，性能優秀，監控到位。可以說難分伯仲，相對而言weblogic的連接池使用配置和監控配置更簡單明瞭，而websphere的更復雜但選項功能也更多一些。其實這正是對兩種應用服務器的使用印象的直接反映，當然總體比較2種應用服務器應該又是另一個話題了，也許在下一期的內容裏。。。
比較了多種連接池的優劣，下面這個話題可能和比較本身沒有直接關係，但個人認爲應該是更有價值的一些經驗分享吧，那就是---這麼多指標配置，那些最大和最小連接數以及其他一些必要的配置指標，在一個正式的生產項目中到底應該配置什麼值呢？
其實這個值首先還是要根據具體的項目情況、數據規模以及併發數來制定的(儘管像是套話，但是我們研發人員嚴謹的作風還是必要的:)。具體而言在中型偏小型的項目--給個數值把，用戶數300到3000，數據量100萬到1億---中,建議weblogic設置爲最大和最小都是200，websphere最小200最大300，前提是2者設置的最小內存要在1G以上，當然如果條件允許內存越大越好，不過32位機內存1.5G的限制是一定的（64位嘛我願意設個4G內存過來，速度提升的感覺很爽啊）。這個數字出來以後相信會有不少問題要拋過來，我一一談一下自己的體驗和想法吧
1 爲什麼是200或300而不是更高？
回答： 再分配多了效果也不大了，一個是應用服務器維持這個連接數需要內存支持，剛纔說了32位的機器只能支持到1.5G，並且維護大量的連接進行分配使用對cpu也是一個不小的負荷，因此不宜太大。
2 爲什麼不小一點？
回答： 如果太小，那麼在上述規模項目的併發量以及數據量上來以後會造成排隊現象，系統會變慢，數據庫連接會經常打開和關閉，性能上有壓力，用戶體驗也不好。
3 爲什麼weblogic最小最大都一樣，而websphere不一樣
回答： 其實和分配內存的最小最大值的情況一樣，一般都推薦2個值應該一致，都放在內存裏就好了嘛。但是ibm官方推薦2個值要有區別---官方說法還是要聽的
4 其他開源連接池的分配方案還沒說呢？
回答： 開源的個人認爲到100就可以了，再高他也不會太穩定，當然1G的最小內存是一定要給tomcat分
附件：
Oracle RAC連接URL常見配置參數： jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<ServerName>)(PORT=<Port>))(LOAD_BALANCE=YES)(FAILOVER=on)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<ServiceName>)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180)(DELAY=5))))
MySQL connector/j連接串高級配置屬性： https://docs.oracle.com/cd/E17952_01/connector-j-en/connector-j-reference-configuration-properties.html