解決Tomcat數據鏈接池沒法釋放

簡單分析了一下，每次Reload一下就能解決沒法登陸的狀況，天然而然就想到是否是session有問題呢？因而到Tomcat的manager界面看了下，發現並無出現session粘滯暴漲的狀況。

原本能夠打開jconsole看看的，正好想起了以前用過的Tomcat檢測工具：probe，因而直接從其餘機器上scp了一個probe.war，丟到了webapps下面自動部署。

部署完以後，打開了probe網頁管理後臺發現smc項目的實時 數據庫 鏈接數很高，並且只增不減！這個系統的數據池大小設置爲200，此時已是100+了，並且一直只升不降。好吧，當數據鏈接數達到200時，問題確定會再次出現的。

因而我將這個問題告訴了小毛，要他本身去修改 鏈接池 釋放機制（這裏用的是項目單獨設定的參數）。他說試過了，沒有用，問下我有沒有辦法。

我這人記性一直欠佳，也不多去記憶一些參數設置，問我麼？還我也只能問BD、GG了。。。

最終在強大的搜索引擎的幫助下，找到了相關參數說明，經過參考修改後成功解決了問題！

Tomcat 鏈接池 沒法釋放的解決方法：

編輯項目的鏈接池配置文件：context.xml，參考下面的【 數據庫 鏈接設置】參數說明，按照實際狀況調整好各項數值，尤爲是Maxidle和maxActive。並記得加上removeAbandoned=true 相關釋放參數便可，咱們這最終設置好的context.xml以下所示：

 1 <Resource name="jdbc/smc"  
 2 
 3 type="javax.sql.DataSource"  
 4 
 5 username="user"  
 6 
 7 password="password"  
 8 
 9 driverClassName="oracle.jdbc.driver.OracleDriver"  
10 
11 maxIdle="50"  
12 
13 maxWait="2000"  
14 
15 removeAbandoned="true"  
16 
17 removeAbandonedTimeout="180"  
18 
19 validationQuery="select * from dual "  
20 
21 url="jdbc:oracle:thin:@192.168.7.98:1521:dw"  
22 
23 maxActive="200"/>

 

數據庫鏈接設置參考：

#數據庫鏈接設置   
jdbc.driverClassName=oracle.jdbc.driver.OracleDriver   
jdbcjdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:DBSERVER   
jdbc.username=user   
jdbc.password=pass   
  
#<!-- 初始化鏈接 -->  
dataSource.initialSize=10  
  
#<!-- 最大空閒鏈接 --> dataSource.maxIdle=20 #<!-- 最小空閒鏈接 --> dataSource.minIdle=5 #最大鏈接數量 dataSource.maxActive=50 #是否在自動回收超時鏈接的時候打印鏈接的超時錯誤 dataSource.logAbandoned=true #是否自動回收超時鏈接 dataSource.removeAbandoned=true #超時時間(以秒數爲單位) dataSource.removeAbandonedTimeout=180 #<!-- 超時等待時間以毫秒爲單位 --> dataSource.maxWait=1000

 1 #數據庫鏈接設置  
 2 
 3 jdbc.driverClassName=oracle.jdbc.driver.OracleDriver  
 4 
 5 jdbcjdbc.url=jdbc:oracle:thin:@127.0.0.1:1521:DBSERVER  
 6 
 7 jdbc.username=user  
 8 
 9 jdbc.password=pass  
10 
11 #<!-- 初始化鏈接 -->  
12 
13 dataSource.initialSize=10  
14 
15 #<!-- 最大空閒鏈接 -->  
16 
17 dataSource.maxIdle=20  
18 
19 #<!-- 最小空閒鏈接 -->  
20 
21 dataSource.minIdle=5  
22 
23 #最大鏈接數量  
24 
25 dataSource.maxActive=50  
26 
27 #是否在自動回收超時鏈接的時候打印鏈接的超時錯誤  
28 
29 dataSource.logAbandoned=true  
30 
31 #是否自動回收超時鏈接  
32 
33 dataSource.removeAbandoned=true  
34 
35 #超時時間(以秒數爲單位)  
36 
37 dataSource.removeAbandonedTimeout=180  
38 
39 #<!-- 超時等待時間以毫秒爲單位 -->  
40 
41 dataSource.maxWait=1000

 

附上做者的原文說明：

在配置DBCP鏈接池時，主要難以理解的主要有： removeAbandoned 、logAbandoned、removeAbandonedTimeout、maxWait這四個參數，設置了rmoveAbandoned=true 那麼在getNumActive()快要到getMaxActive()的時候，系統會進行無效的Connection的回收，回收的 Connection爲removeAbandonedTimeout(默認300秒)中設置的秒數後沒有使用的Connection，激活回收機制好像 是getNumActive()=getMaxActive()-2。

若是開啓" removeAbandoned ",那麼鏈接在被認爲泄露時可能被池回收. 這個機制在(getNumIdle() < 2) and (getNumActive() > getMaxActive() - 3)時被觸發.

舉例：當maxActive=20, 活動鏈接爲18,空閒鏈接爲1時能夠觸發" removeAbandoned ".可是活動鏈接只有在沒有被使用的時間超過"removeAbandonedTimeout"時才被刪除,默認300秒.在resultset中游歷不被計算爲被使用.

logAbandoned=true的話，將會在回收事件後，在log中打印出回收Connection的錯誤信息，包括在哪一個地方用了Connection卻忘記關閉了，在調試的時候頗有用。

建議maxWait的時間不要設得太長，maxWait若是設置太長那麼客戶端會等待好久才激發回收事件。