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

迈不过友情╰ 2022-05-23 00:51 109阅读 0赞

### 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文件中，把  
> ` <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`，解决方案在后面的博客解决。