近段时间，公司的检测中心报表系统(SMC)的开发人员时不时找到我，说用户老是出现无法登录的情况。前些日子因为手头上 有Jboss集群的测试工作，发现用户不能登录时，都是在Tomcat中将这个项目Reload一下就好了，不过只是治标而已，因为大概几个小时之后又会 再次出现无法登录的情况。

今天上午，开发人员小毛又找到我，要我协助将这个问题根治一下，拖太久用户难保不投诉。

简单分析了一下，每次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如下所示：



<         Resource          name         =         "jdbc/smc"           


                   type         =         "javax.sql.DataSource"           


                   username         =         "user"           


                   password         =         "password"           


                   driverClassName         =         "oracle.jdbc.driver.OracleDriver"           


                    maxIdle         =         "50"           


                    maxWait         =         "2000"           


                    removeAbandoned         =         "true"           


                    removeAbandonedTimeout         =         "180"           


                    validationQuery         =         "select * from dual "           


                        url         =         "jdbc:oracle:thin:@192.168.7.98:1521:dw"           


                  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



附上作者的原文说明：

在配置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如果设置太长那么客户端会等待很久才激发回收事件。


阿里云国内75折 回扣 微信号：monov8
阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6
标签: Tomcat