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;

    ...
}

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