tomcat的服务器过十几个小时就连不到数据库，重启一下tomcat就好了，每次都要重启tomcat，是哪出问题？？

Posted 2023-05-09

打开页面提示以下错误，注意：重启一下tomcat就又好了，每次都是这样，是哪里出问题呢？据说是连接池出问题……但实在找不出哪有问题，重启过后又正常了……

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
com.product.dao.DB.query(DB.java:52)
com.product.action.DoProduct.getMqeProduct(DoProduct.java:260)
com.product.servlet.Marquee.doPost(Marquee.java:45)
com.product.servlet.Marquee.doGet(Marquee.java:28)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
java.security.AccessController.doPrivileged(Native Method)
com.product.util.filter.CharsetEncodingFilter.doFilter(CharsetEncodingFilter.java:32)
sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:218)

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.18 logs.

你的连接池是自己实现的吗
应该是连接池里的连接都没有了：
1 要么被销毁了
2 要么是你没释放连接，导致没有空闲连接，
所有得不到连接包空指针

要是用的tomcat自己的连接池，是不是配置有问题，重新仔细检查下，
再或许看看是不是tomcat的bug，重新换个tomcat试试 参考技术A 我遇到过这样的是tomcat6+SqlServer2005的系统，因为SqlServer·是盗版的，会出现每隔一段时间就连不上数据库的情况，不知道你得是程序问题还是数据库问题

Tomcat Pooling DataSource数据库连接池优化(20180705)

公司刚上线的项目，在某天晚上收到监控系统发送的DB监控异常的邮件，查看相关日志，发现异常信息如下：

根据异常信息排查引起异常的原因：

    Mysql服务器默认的“wait_timeout”是8小时（也就是默认的值默认是28800秒），也就是说一个connection空闲超过8个小时，Mysql将自动断开该connection，通俗的讲就是一个连接在8小时内没有活动，就会自动断开该连接。而连接池却认为该连接还是有效的(因为并未校验连接的有效性)，当应用申请使用该连接时，就会导致上面的报错。

为了确保是连接池问题，随后查看Azure Mysql 服务日志，并未发现有异常情况，排除了DB出现异常的情况，然后重新定位Tomcat 服务的日志时间段，发现在时间段内有监控DB请求也有正常返回的情况，进一步确定Mysql服务在该段时间内是正常服务的情况。

接下来根据异常原因查找解决方案,查看项目中配置的连接池参数如下：

发现testOnBorrow,testOnReturn两个参数是关闭的，但是担心该两个参数太影响性能（每次在获取连接或者返还连接时会去校验连接有效性），遂查看是否有其他参数能够保证在Mysql 8小时连接断开之前将连接从线程池中剔除，查看到以下参数：

maxAge

长整型值。连接保持时间（以毫秒计）。当连接要返回池中时，连接池会检查是否达到 now - time-when-connected > maxAge 的条件，如果条件达成，则关闭该连接，不再将其返回池中。默认值为 0，意味着连接将保持开放状态，在将连接返回池中时，不会执行任何年龄检查。

发现该参数可以设置连接的有效保持时间，可以解决Mysql因为连接时长问题断开连接但是连接池并未释放连接的问题。

另外，分析发现也有其他方式解决问题：

方案一：改小连接池始终都应保留的连接的最小数目(MinIdle)，并缩小空闲连接验证的间隔(timeBetweenEvictionRunsMillis)。

方案二：增大每次空闲连接回收器线程(如果有)运行时检查的连接数量(numTestsPerEvictionRun)，默认值是3(注意，网上的资料提示该参数在Tomcat Pooling DataSource不生效，但是未实际测试过).