Tomcat应用中ThreadLocal引发的内存泄漏详解
Tomcat环境下，ThreadLocal变量可能导致内存泄漏，尤其当静态变量与类卸载机制共同作用时。本文深入探讨此现象的成因及Tomcat的应对机制。
ThreadLocal内存泄漏通常发生在Tomcat应用部署和卸载阶段。 例如，文中提到的LeakingServlet使用静态MyThreadLocal变量，这种设计容易引发问题。
关键在于Tomcat为每个Web应用创建独立的WebAppClassLoader。该加载器负责管理应用内所有类，包括LeakingServlet。应用停止或重新部署时，Tomcat尝试卸载WebAppClassLoader及其加载的类。
然而，如果LeakingServlet持有静态MyThreadLocal变量，该变量的生命周期与LeakingServlet类紧密相连。只要WebAppClassLoader存在，静态变量就不会被垃圾回收。
理想情况下，应用停止时，相关对象应被释放。但如果MyThreadLocal存储的对象与应用上下文相关，由于静态变量的持续引用，这些对象无法被垃圾回收，造成内存泄漏。
虽然Tomcat努力卸载所有组件，但静态ThreadLocal这类引用可能导致部分资源无法完全释放。即使Tomcat尝试卸载WebAppClassLoader，LeakingServlet通过静态变量的间接引用可能维持与WebAppClassLoader的连接，导致内存泄漏。
Java虚拟机中，类的卸载并不直接决定类加载器的卸载，而是类加载器的活动性影响其加载的类是否可卸载。当类加载器加载的类及其实例不再被强引用时，理论上可以被垃圾回收。但如果类加载器自身被保留，其加载的类即使没有其他强引用，也可能无法卸载。
Tomcat在应用停止或重新部署时尝试卸载WebAppClassLoader。一旦卸载，其加载的类（如LeakingServlet）如果没有其他类加载器引用，理论上可以被垃圾回收。
LeakingServlet在应用卸载时应被卸载。但如果它通过静态字段引用ThreadLocal，而ThreadLocal又持有应用上下文或其他不该长期存在的对象引用，则可能导致类加载器及其加载的类无法卸载，最终引发内存泄漏。
因此，LeakingServlet可能因不当引用而影响整个类加载器层次结构的卸载，从而产生内存泄漏。
