Tomcat6类加载器泄露

异常信息

    created a ThreadLocal with key of type [com.opensymphony.xwork2.inject.ContainerImpl$10] (value [com.opensymphony.xwork2.inject.ContainerImpl$10@12c74b9]) and a value of type [java.lang.Object[]] (value [[Ljava.lang.Object;@1a34544]) but failed to remove it.

解决办法

原因大概是说tomcat 6.025之后引入了一种内存泄露的检查机制，会把不能垃圾收集的对像做日志。

第一种解决办法：使用低于6版本的tomcat。

第二种解决办法：在tomcat的server.xml文件（在tomcat的安装路径下的conf文件夹里）中把这个监听关掉：

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>

就是用<!--。。。-->把下面三句话括起来就可以啦。

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

 -------以下是我看的别人的：

现象：

上次同事在热部署应用到liferay服务器上时，遇到了以下错误：

Sep 21, 2012 3:19:06 AM org.apache.catalina.startup.HostConfig deployDirectory 
 
INFO: Deploying web application directory /home/portal/liferay-container-1.0.0-SNAPSHOT/standalone/liferay-portal/community-edition-liferay-portal-tomcat-6.1.0/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/webapps/paas_integration_portlet 
 
Sep 21, 2012 3:19:06 AM org.apache.catalina.core.StandardContext startInternal 
 
SEVERE: Error listenerStart 
 
Sep 21, 2012 3:19:06 AM org.apache.catalina.core.StandardContext startInternal 
 
SEVERE: Context [/paas_integration_portlet] startup failed due to previous errors 
 
Sep 21, 2012 3:19:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 
 
SEVERE: The web application [/paas_integration_portlet] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@3e043340]) and a value of type [java.lang.Class] (value [class oracle.sql.AnyDataFactory]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
 
Sep 21, 2012 3:19:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 
 
SEVERE: The web application [/paas_integration_portlet] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5c0ce8f]) and a value of type [java.lang.Class] (value [class oracle.sql.TypeDescriptorFactory]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
 
Sep 21, 2012 3:19:06 AM org.apache.coyote.AbstractProtocol start 
 
INFO: Starting ProtocolHandler ["http-bio-8080"] 
 
Sep 21, 2012 3:19:06 AM org.apache.coyote.AbstractProtocol start 
 
INFO: Starting ProtocolHandler ["ajp-bio-8009"] 
 
Sep 21, 2012 3:19:06 AM org.apache.catalina.startup.Catalina start 
 
INFO: Server startup in 37724 ms 

 

基于我的以前经验，这是"类加载器泄露“的问题，具体细节参见我的以下邮件回复：

 

Reason:

 

This is very common in Tomcat .

 

We all know (1) ThreadLocal is used for holding variables per thread.

                         (2) Tomcat supports multi-threads.

                        (3) The default GC mechanism for tomcat is “object reference”

 

 

 

So the process is ,when we redeploy a portlet ,then the WebClassloader will load all the necessary classes and jars which required by this portlet ,and the threadlocal is used for identifying the thread .But when we destroy the portlet(redeploy or remove) ,though the portlet is removed ,but the threadlocal  value didn’t remove ,(which means the object reference number still >0) ,so the classes loaded by WebappClassLoader can’t not be gc , that’s a very famous topic  “Classloader leak”

 

My highlighted part is my understanding to this problem and it can explains what Judith has highlighted .

 

 

 

Solution:

 

“Classloader leak” issue happened since the first version of tomcat ,and it always a challenging work , as I know ,since tomcat 7 (because our Liferay 6.1 based on tomcat 7) has added some detection mechanism to detect the classloader leak issue ,that’s why it report “SEVERE”   ,if you familiar with tomcat 5 or 6 ,it just shutdown without any useful information.

 

Up to now just as I know ,we have no solution about it ,maybe we need to new version of tomcat to fix it .  If often meet with it ,I suggest we re-start the liferay.