This is very likely to create a memory leak. Stack trace of thread错误分析

1、问题描述

启动tomcat部署项目时,报This is very likely to create a memory leak. Stack trace of thread错误。

29-May-2018 12:30:09.322 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file
29-May-2018 12:30:09.323 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [] startup failed due to previous errors
29-May-2018 12:30:09.427 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [com.alibaba.druid.proxy.DruidDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
29-May-2018 12:30:09.427 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
29-May-2018 12:30:09.428 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [org.h2.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
29-May-2018 12:30:09.428 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [Abandoned connection cleanup thread] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.lang.Object.wait(Native Method)
 java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
 com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:64)
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 java.lang.Thread.run(Thread.java:745)

2、问题原因

tomcat启动奔溃,同时释放了jdbc连接。

3、解决方案

这种异常造成的原因千奇百怪,并没有统一的处理方案,以下是我遇到的不同情况采取的几种解决方案。

3.1、存在多个tomcat子线程

启动前tomcat意外退出,使用ps -ef | grep "tomcat名称"查看是不是有多个tomcat在启动,若有,Kill掉。

3.2、调整JVM参数

JAVA_OPTS='-server -Xms5120m -Xmx10240m -XX:PermSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=5120m '

3.3、去掉tomcat监听

tomcat 6.025以后引入了内存泄露侦测,对于垃圾回收不能处理的对像,它就会做日志。去掉监听的方法也很简单:
在tomcat的server.xml文件中,把
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
这个监听给关了。

3.4、其他

如果以上方案无法解决问题,只能逐步排查,排查方案如下:
1.使用“之前部署正常的分支”(我们记为hoaven分支)部署项目;
2.若tomcat能正常启动,说明tomcat或服务器没有问题,检查自己的代码;
3.逐步检查自己的代码:从hoaven分支checkout一个分支(fixbug),然后将自己写的代码一点一点移至fixbug分支。
4.每移动一次代码,部署一次,若正常启动,继续移动代码;若报出以上错误,停止移动,检查本次移动的代码。

其实3.4方法很有效,特别是检查肉眼无法明了的莫名其妙的的bug。
记录下我某一次检查以上bug采用的3.4方案,得出的结果:
代码中,有一处注入报错很奇怪:

@Slf4j
@Component
public class RestAuthFilter extends FormAuthenticationFilter {

    @Resource
    MobileDeviceService mobileDeviceService;

    @Resource
    UserService userService;

    ...
}


@Slf4j
@Service
public class MobileDeviceServiceImpl implements MobileDeviceService {
    @Resource
    IHddBaseService hddBaseService;

    ...
}

MobileDeviceServiceUserService上的@Resource改为@Autowired部署则没有问题,思考一下:@Resource属于jdk的注解,@Autowired属于spring的注解,应该是注入RestAuthFilter时,在spring容器中没有找到MobileDeviceService和UserService的实例,@Resource会强制将MobileDeviceServiceUserService注入进来,而@Autowired采取的措施是不注入(或注入null)。这样一来,就会有新的问题,MobileDeviceServiceUserService实例为null,解决方案在后面的博客解决。

原文地址:https://www.cnblogs.com/jpfss/p/11828257.html