错误示例:
严重: The web application [/flex_vod] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@793ae954]) and a value of type [flex.messaging.client.FlexClient] (value [flex.messaging.client.FlexClient@2f35d7ad]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
2011-3-16 10:40:26 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
原因分析:
查了很多资料都没有给出明确说法,最后通过在他的FAQ找到说明了。
应该是tomcat的bug,建议稳定版上tomcat7吧,我查看了tomcat6的changelog ,tomcat6.0.29以后修改了N多BUG,
关于内存泄漏检测在tomcat FAQ上的大致描述如下:
Tomcat6.0.24 - 6.0.26在关闭和重载时检测到内存泄漏通过修改ThreadLocalMap代码清除关联的线程实例把内存释放了,但是后来又觉得不安全实现不理想,这点通过看tomcat6的changelog也能发现基本6.0.27之后的每一个本版都在内存泄漏的处理上进行或多或少的改进(当然也改进因此导致的一些bug,如jdbc、dbcp相关联的bug),但是在tomcat7.0.6之后通过对线程池机制进行更新把该bug彻底解决了。
关于内存泄漏解决详细描述参考其FAQ:
部分描述:
The leak is caused because we have a custom class for the ThreadLocal instance, and also a custom class for the value bound to the Thread. Actually the important thing is that both classes were loaded by the webapp classloader.
Hopefully tomcat 6.0.24 can detect the leak when the application is stopped: each Thread in the JVM is examined, and the internal structures of the Thread and ThreadLocal classes are introspected to see if either the ThreadLocal instance or the value bound to it were loaded by the WebAppClassLoader of the application being stopped.
In this particular case, the leak is detected and a message is logged. Tomcat 6.0.24 to 6.0.26 modify internal structures of the JDK (ThreadLocalMap) to remove the reference to the ThreadLocal instance, but this is unsafe (see #48895) so that it became optional and disabled by default from 6.0.27. Starting with Tomcat 7.0.6, the threads of the pool are renewed so that the leak is safely fixed.
Tomcat 6 的change log地址:
http://tomcat.apache.org/tomcat-6.0-doc/changelog.html