㈠ 開源的資料庫連接池和普通的資料庫連接池有什麼區別
在項目中嘗試使用了幾種開源的資料庫連接池實現。一種是dbcp，一種是c3p0，還有一種是proxool，這幾種資料庫連接池都可以很容易的在Spring配置起來。性能總體上上感覺dbcp為最優，因為穩定性和並發性都是我的項目需要的。
項目中經過反復測試，如果web server和資料庫server不是同一個機器的話，在斷網時間比較短的時間內三種資料庫連接池都能較好的重連，但是在斷網時間超過8個鍾頭 proxool就不能恢復工作了。但是dbcp卻能很快的重新連接。實際生產環境中穩定性和總體性能是最重要的，都需要做相應的測試才能放心的讓系統上生產線。
這里給出項目中資料庫連接池配置：
dbcp的jndi：13 4 java:comp/env/jdbc/mysql5 6 proxool(proxool-0.9.0RC1)的配置： com.mysql.jdbc.Driver jdbc:mysql://ip:3306/dbname?useUnicode=true&characterEncoding=utf8&autoReconnect=true user password 500 15000 select CURRENT_DATE true mysqlProxoolDataSource 1000 false 建議使用DBCP，配置在tomcat中，然後在spring中使用jndi的形式獲取。 c3p0(c3p0-0.9.0)： 1 3 4 com.mysql.jdbc.Driver 5 6 7 jdbc:mysql://192.168.0.225:3306/sendinmdb?useUnicode=true&characterEncoding=utf8&autoReconnect=true 8 9 10 ********11 12 13 ********14 15 16 10017 18 19 5020 21 22 10023 24 25 100026 27 28 3029 30 直接 & paste到spring配置文件里就可以使用了。 配置一些額外的tomcat 的DBCP連接池參數，也可以更好的使用到類似proxool提供的功能，只是dbcp更加穩定而已。tomcat/conf/context.xml中插入一個Resource元素： 解釋一下以下這些參數的含義：
validationQuery = "select current_date()"
testOnBorrow = "true"
testOnReturn = "false"
testWhileIdle = "true"
當 從池中獲取一個Connection後使用 select current_date() 來測試該資料庫連接的可用性，如果SQL語句返回結果則認為是一個有效的連接，否則將繼續測試知道可以拿到有效的連接。當返回Connection給池的時候不進行驗證，但是Connection空閑的時候就要進行認證。
timeBetweenEvictionRunsMillis = "15000"
DBCP 清空線程睡眠的間隙，如值為負數則不運行該線程
numTestsPerEvictionRun = "10"
清空線程每次驗證的連接對象個數
minEvictableIdleTimeMillis = "600000" Connection對象可以在池中空閑的最小時間，單位為毫秒詳細配置請訪問
㈡ java的3種資料庫連接池用哪個好
1 dbcp
dbcp可能是使用最多的開源連接池，原因大概是因為配置方便，而且很多開源和tomcat應用例子都是使用的這個連接池吧。
這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。這個連接池的配置參見附件壓縮包中的:dbcp.xml
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性還是可以，不過速度稍慢，在大並發量的壓力下穩定性有所下降，此外不提供連接池監控
2 c3p0
c3p0是另外一個開源的連接池，在業界也是比較有名的，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的:c3p0.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性相當不錯，在大並發量的壓力下穩定性也有一定保證，此外不提供連接池監控。
3 proxool
proxool這個連接池可能用到的人比較少，但也有一定知名度，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的：proxool.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性有一定問題
㈢ java的3種資料庫連接池用哪個好
1
dbcp
dbcp可能是使用最多的開源連接池，原因大概是因為配置方便，而且很多開源和tomcat應用例子都是使用的這個連接池吧。
這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。這個連接池的配置參見附件壓縮包中的:dbcp.xml
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性還是可以，不過速度稍慢，在大並發量的壓力下穩定性
有所下降，此外不提供連接池監控
2
c3p0
c3p0是另外一個開源的連接池，在業界也是比較有名的，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的:c3p0.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性相當不錯，在大並發量的壓力下穩定性也有一定保證，
此外不提供連接池監控。
3
proxool
proxool這個連接池可能用到的人比較少，但也有一定知名度，這個連接池可以設置最大和最小連接，連接等待時間等，基本功能都有。
這個連接池的配置參見附件壓縮包中的：proxool.xml。
使用評價：在具體項目應用中，發現此連接池的持續運行的穩定性有一定問題，有一個需要長時間跑批的任務場景任務，同樣的代碼
㈣ 什麼是資料庫連接池，有什麼作用
資料庫連接是一種有限的昂貴的資源，
資料庫連接影響到程序的性能指標。
資料庫連接池正是針對這個問題提出來的。資料庫連接池負責分配、
管理和釋放資料庫連接，
它允許應用程序重復使用一個現有的資料庫連接，
而再不是重新建立一個；
釋放空閑時間超過最大空閑時間的資料庫連接來避免因為沒有釋放數
據庫連接而引起的資料庫連接遺漏。
這項技術能明顯提高對資料庫操作的性能。
㈤ 資料庫連接池druid和bonep有什麼區別
現在常用的開源資料庫連接池主要有c3p0、dbcp、proxool三種，其中：
Spring 推薦使用dbcp；
Hibernate 推薦使用c3p0和proxool；
1、 DBCP：apache
DBCP(DataBase connection pool)資料庫連接池。是apache上的一個 java連接池項目，也是 tomcat使用的連接池組件。單獨使用dbcp需要3個包：common-dbcp.jar,common-pool.jar,common-collections.jar由於建立資料庫連接是一個非常耗時耗資源的行為，所以通過連接池預先同資料庫建立一些連接，放在內存中，應用程序需要建立資料庫連接時直接到連接池中申請一個就行，用完後再放回去。dbcp沒有自動的去回收空閑連接的功能。
2、 C3P0：
C3P0是一個開源的jdbc連接池，它實現了數據源和jndi綁定，支持jdbc3規范和jdbc2的標准擴展。c3p0是非同步操作的，緩慢的jdbc操作通過幫助進程完成。擴展這些操作可以有效的提升性能。目前使用它的開源項目有Hibernate，Spring等。c3p0有自動回收空閑連接功能。
3、 Proxool：Sourceforge
Proxool是一種Java資料庫連接池技術。是sourceforge下的一個開源項目,這個項目提供一個健壯、易用的連接池，最為關鍵的是這個連接池提供監控的功能，方便易用，便於發現連接泄漏的情況。
對比：
1> 相同時間內同等量的線程數和循環次數下:通過對三個連接池的三個標志性性能測試參數（Average,median,90%Line）進行比較發現：性能dbcp<=c3p0<proxool；
2> 不同情況下的同一資料庫連接池測試：通過觀察 Average,median,90%Line三個參數發
現三個連接池的穩定性（三種連接池的三個測試參數的變化情況）依次：穩定性dbcp>=c3p0>proxool。
結論：
通過對三種資料庫連接池的性能測試發現，proxool和 c3p0能夠更好的支持高並發，但是在穩定性方面略遜於 dpcp；
㈥ websphere 資料庫連接池比其他連接池好么
websphere的連接池
還是先來段題外話：記得有人說過，websphere只有版本6以後才算是websphere，個人很贊同。websphere 5以及以前的版本。。。還是忘了吧。
其實websphere的連接池秉承ibm一貫的風格：功能強大，使用復雜：
進入控制台使用「JDBC提供程序」功能菜單進行連接池的基本配置，一路下來，不同的資料庫配置方式不盡相同，最奇怪的是還要單獨手工加上user和password參數，如果沒有
資料指導的話還真是摸不著頭腦。這些基本設置還是網上找吧很多的。連接池設置完還需要設置數據源，jndi名字一樣與之前的對應：jdbc/myapp
高級設置包括初始化連接數，最大連接，連接有效性檢查，不使用超時。
連接池監控：使用運行監控菜單，里邊會有一個監控項目選擇，選jdbc監控即可，可惡的是一開始彈出什麼伺服器操作系統需要安裝什麼圖形化控制項，選擇是那麼就得去找到控制項在操作系統（linux）下安裝，然後很多的依賴組件都沒有。。。搞了半天才發現選擇否，監控數據以及圖形一樣能出來嘛，真是要怒了。
雖然經過一番波折但是監控的內容還是很強大的，就連接池來說一樣包括當前連接數、曾經達到的峰值、可以使用的連接數、從資料庫打開的連接數、曾經關閉的連接數。。。其中前3項是我最關注的，比較奇怪的現象是應用剛啟動的時候已開啟的連接數量竟然沒有達到初始定義的連接數量，不清楚websphere是怎麼個計算機制。
另外在壓力大的時候可使用的連接數會是負數，當時很奇怪，想想也瞭然了，那個負數肯定是排隊等待的數量了
使用評價：在具體項目應用中，此連接池的持續運行的穩定性相當強，在大並發量的壓力下性能也足夠優秀，另外在一些異常情況下連接池裡的連接能夠及時釋放，連接池監控配置有些復雜，但是配置好後各項指標一目瞭然並且有圖形顯示 。
總結：
這種商業級別的連接池功能強大，使用穩定，性能優秀，監控到位。
下面這個話題可能和比較本身沒有直接關系，但個人認為應該是更有價值的一些經驗分享吧，那就是---這么多指標配置，那些最大和最小連接數以及其他一些必要的配置指標，在一個正式的生產項目中到底應該配置什麼值呢？
其實這個值首先還是要根據具體的項目情況、數據規模以及並發數來制定的(盡管像是套話，但是我們研發人員嚴謹的作風還是必要的:)。具體而言在中型偏小型的項目--給個數值把，用戶數300到3000，數據量100萬到1億---中,建議websphere最小200最大300，前提是設置的最小內存要在1G以上，當然如果條件允許內存越大越好，不過32位機內存1.5G的限制是一定的（64位嘛我願意設個4G內存過來，速度提升的感覺很爽啊）。這個數字出來以後相信會有不少問題要拋過來，
1 為什麼是200或300而不是更高？
回答： 再分配多了效果也不大了，一個是應用伺服器維持這個連接數需要內存支持，剛才說了32位的機器只能支持到1.5G，並且維護大量的連接進行分配使用對cpu也是一個不小的負荷，因此不宜太大。
2 為什麼不小一點？
回答： 如果太小，那麼在上述規模項目的並發量以及數據量上來以後會造成排隊現象，系統會變慢，資料庫連接會經常打開和關閉，性能上有壓力，用戶體驗也不好。
3 為什麼websphere最小最大不一樣
回答： 其實和分配內存的最小最大值的情況一樣，一般都推薦2個值應該一致，都放在內存里就好了嘛。但是ibm官方推薦2個值要有區別---官方說法還是要聽的
4 其他開源連接池的分配方案還沒說呢？
回答： 開源的個人認為到100就可以了，再高他也不會太穩定，當然1G的最小內存是一定要給tomcat分的
㈦ 資料庫連接池與JDBC的區別
資料庫連接池與JDBC的區別如下：
1、理念方面的區別：
資料庫連接池負責分配、管理和釋放資料庫連接，它允許應用程序重復使用一個現有的資料庫連接，而不是再重新建立一個；釋放空閑時間超過最大空閑時間的資料庫連接來避免因為沒有釋放資料庫連接而引起的資料庫連接遺漏。這項技術能明顯提高對資料庫操作的性能。
JDBC（Java DataBase Connectivity,java資料庫連接）是一種用於執行SQL語句的Java API，可以為多種關系資料庫提供統一訪問，它由一組用Java語言編寫的類和介面組成。JDBC提供了一種基準，據此可以構建更高級的工具和介面，使資料庫開發人員能夠編寫資料庫應用程序，同時，JDBC也是個商標名。
2、原理不同：
與資料庫建立連接的標准方法是調用DriverManager.getConnection方法。該方法接受含有某個URL的字元串。DriverManager類（即所謂的JDBC管理層）將嘗試找到可與那個URL所代表的資料庫進行連接的驅動程序。DriverManager類存有已注冊的Driver類的清單。當調用方法getConnection時，它將檢查清單中的每個驅動程序，直到找到可與URL中指定的資料庫進行連接的驅動程序為止。Driver的方法connect使用這個URL來建立實際的連接。
連接池基本的思想是在系統初始化的時候，將資料庫連接作為對象存儲在內存中，當用戶需要訪問資料庫時，並非建立一個新的連接，而是從連接池中取出一個已建立的空閑連接對象。使用完畢後，用戶也並非將連接關閉，而是將連接放回連接池中，以供下一個請求訪問使用。而連接的建立、斷開都由連接池自身來管理。同時，還可以通過設置連接池的參數來控制連接池中的初始連接數、連接的上下限數以及每個連接的最大使用次數、最大空閑時間等等。也可以通過其自身的管理機制來監視資料庫連接的數量、使用情況等。
㈧ 使用連接池技術與使用傳統jdbc訪問資料庫相比，哪個速度上會更快一些
肯定是連接池更快啊，連接池存放一定數量的連接池，用戶需要連接資料庫時，直接從連接池取一條連接，不需要重新重建一條連接，這個道理很簡單了，取和創建比，取明顯效率要更高
㈨ 為什麼HikariCP被號稱為性能最好的Java資料庫連接池，如何配置使用
HiKariCP是資料庫連接池的一個後起之秀，號稱性能最好，可以完美地PK掉其他連接池。
為何要使用HiKariCP？這要先從BoneCP說起：
什麼？不是有C3P0/DBCP這些成熟的資料庫連接池嗎？一直用的好好的，為什麼又搞出一個BoneCP來？因為，傳說中BoneCP在快速這個特點上做到了極致，官方數據是C3P0等的25倍左右。不相信？其實我也不怎麼信。可是，有圖有真相啊（圖片來自BoneCP官網：）：
而且，網上對於BoneCP是好評如潮啊，推薦的文章一搜一大堆。
然而，上Maven Repository網站（）查找有沒有最新版本的時候，你會發現最新的是2013年10月份的（這么久沒新版本出來了？）。於是，再去BoneCP的Githut（）上看看最近有沒有提交代碼。卻發現，BoneCP的作者對於這個項目貌似已經心灰意冷，說是要讓步給HikariCP了（有圖有真相）：
……什麼？又來一個CP？……什麼是Hikari？
Hikari來自日文，是「光」（陽光的光，不是光禿禿的光）的意思。作者估計是為了藉助這個詞來暗示這個CP速度飛快。不知作者是不是日本人，不過日本也有很多優秀的碼農，聽說比特幣據說日本人搞出來的。。。
這個產品的口號是「快速、簡單、可靠」。實際情況跟這個口號真的匹配嗎？又是有圖有真相（Benchmarks又來了）：
這個圖，也間接地、再一次地證明了boneCP比c3p0強大很多，當然，跟「光」比起來，又弱了不少啊。
那麼，這么好的P是怎麼做到的呢？官網詳細地說明了HikariCP所做的一些優化，總結如下：
位元組碼精簡：優化代碼，直到編譯後的位元組碼最少，這樣，CPU緩存可以載入更多的程序代碼；
優化代理和攔截器：減少代碼，例如HikariCP的Statement proxy只有100行代碼，只有BoneCP的十分之一；
自定義數組類型（FastStatementList）代替ArrayList：避免每次get()調用都要進行range check，避免調用remove()時的從頭到尾的掃描；
自定義集合類型（ConcurrentBag）：提高並發讀寫的效率；
其他針對BoneCP缺陷的優化，比如對於耗時超過一個CPU時間片的方法調用的研究（但沒說具體怎麼優化）。
很多優化的對比都是針對BoneCP的……哈哈。
（參考文章：）
幾個連接池的代碼量對比（代碼量越少，一般意味著執行效率越高、發生bug的可能性越低）：
可是，「黃婆賣瓜，自催自擂」這個俗語日本人也是懂得，於是，用戶的好評如潮也是有圖有真相：
還有第三方關於速度的測試：
也許你會說，速度高，如果不穩定也是硬傷啊。於是，關於穩定性的圖也來了：
另外，關於可靠性方面，也是有實驗和數據支持的。對於資料庫連接中斷的情況，通過測試getConnection()，各種CP的不相同處理方法如下：
（所有CP都配置了跟connectionTimeout類似的參數為5秒鍾）
HikariCP：等待5秒鍾後，如果連接還是沒有恢復，則拋出一個SQLExceptions 異常；後續的getConnection()也是一樣處理；
C3P0：完全沒有反應，沒有提示，也不會在「CheckoutTimeout」配置的時長超時後有任何通知給調用者；然後等待2分鍾後終於醒來了，返回一個error；
Tomcat：返回一個connection，然後……調用者如果利用這個無效的connection執行SQL語句……結果可想而知；大約55秒之後終於醒來了，這時候的getConnection()終於可以返回一個error，但沒有等待參數配置的5秒鍾，而是立即返回error；
BoneCP：跟Tomcat的處理方法一樣；也是大約55秒之後才醒來，有了正常的反應，並且終於會等待5秒鍾之後返回error了；
可見，HikariCP的處理方式是最合理的。根據這個測試結果，對於各個CP處理資料庫中斷的情況，評分如下：
參考文章：
說得這么好，用起來會不會很麻煩啊，會不會有很多參數要配置才能有這樣的效果啊？答案是：不會。
如果之前用的是BoneCP配置的數據源，那麼，就簡單了，只需要把dataSource換一下，稍微調整一下參數就行了：
BoneCP的數據源配置：
<!--BoneCpDatasource-->
<beanid="dataSourceBoneCp"class="com.jolbox.bonecp.BoneCPDataSource"destroy-method="close">
<propertyname="driverClass"value="${db.driverClass}"/>
<propertyname="jdbcUrl"value="${db.url}"/>
<propertyname="username"value="${db.username}"/>
<propertyname="password"value="${db.password}"/>
<propertyname=""value="2"/>
<propertyname="idleMaxAgeInMinutes"value="2"/>
<propertyname="maxConnectionsPerPartition"value="2"/>
<propertyname="minConnectionsPerPartition"value="0"/>
<propertyname="partitionCount"value="2"/>
<propertyname="acquireIncrement"value="1"/>
<propertyname="statementsCacheSize"value="100"/>
<propertyname="lazyInit"value="true"/>
<propertyname="maxConnectionAgeInSeconds"value="20"/>
<propertyname="defaultReadOnly"value="true"/>
</bean>
HiKariCP的數據源配置：
<!--HikariDatasource-->
<beanid="dataSourceHikari"class="com.zaxxer.hikari.HikariDataSource"destroy-method="shutdown">
<!--<propertyname="driverClassName"value="${db.driverClass}"/>--><!--無需指定，除非系統無法自動識別-->
<propertyname="jdbcUrl"value="jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8"/>
<propertyname="username"value="${db.username}"/>
<propertyname="password"value="${db.password}"/>
<!--連接只讀資料庫時配置為true，保證安全-->
<propertyname="readOnly"value="false"/>
<!--等待連接池分配連接的最大時長（毫秒），超過這個時長還沒可用的連接則發生SQLException，預設:30秒-->
<propertyname="connectionTimeout"value="30000"/>
<!--一個連接idle狀態的最大時長（毫秒），超時則被釋放（retired），預設:10分鍾-->
<propertyname="idleTimeout"value="600000"/>
<!--一個連接的生命時長（毫秒），超時而且沒被使用則被釋放（retired），預設:30分鍾，建議設置比資料庫超時時長少30秒，參考MySQLwait_timeout參數（showvariableslike'%timeout%';）-->
<propertyname="maxLifetime"value="1800000"/>
<!--連接池中允許的最大連接數。預設值：10；推薦的公式：((core_count*2)+effective_spindle_count)-->
<propertyname="maximumPoolSize"value="15"/>
</bean>
其中，很多配置都使用預設值就行了，除了maxLifetime和maximumPoolSize要注意自己計算一下。
其他的配置（sqlSessionFactory、MyBatis MapperScannerConfigurer、transactionManager等）統統不用變。
其他關於Datasource配置參數的建議：
Configure your to be one minute less than thewait_timeoutof MySQL.