Java 在Tomcat中重新部署应用程序时内存泄漏

当我在tomcat中重新部署应用程序时，我遇到以下问题：

 The web application [] created a ThreadLocal with key of type
 [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@10d16b])
 and a value of type [com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty]
(value [com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty@1a183d2]) but 
 failed to remove it when the web application was stopped. 
 This is very likely to create a memory leak.

另外，我在应用程序中使用ehcache。这似乎也会导致以下例外情况

     SEVERE: The web application [] created a ThreadLocal with key of type [null] 
     (value [com.sun.xml.bind.v2.ClassFactory$1@24cdc7]) and a value of type [java
     .util.WeakHashMap... 

ehcache似乎创建了一个弱哈希映射，我得到的消息是，这很可能会导致内存泄漏

我在网上搜索发现了这个， 但我无法访问服务器本身

---

请让我知道这些警告是否有任何功能影响，或者是否可以忽略它们？我在tomcat管理器中使用了“查找内存泄漏”选项，它显示“未发现内存泄漏”

当您重新部署应用程序时，tomcat会创建一个新的类加载器。旧的类装入器必须进行垃圾收集，否则会导致永久内存泄漏

Tomcat无法检查垃圾收集是否有效，但它知道几个常见的故障点。如果webapp类加载器对其类由webapp类加载器本身加载的实例设置了

ThreadLocal

，则servlet线程持有对该实例的引用。这意味着类装入器不会被垃圾收集

Tomcat进行了大量此类检测，请参阅。清理线程局部变量很困难，您必须在访问的每个线程中调用

ThreadLocal

上的

remove（）

。实际上，只有在开发过程中多次重新部署web应用时，这一点才很重要。在生产中，您可能不会重新部署，因此可以忽略这一点

要真正了解哪些实例定义了线程局部变量，必须使用探查器。例如，中的heap walker（免责声明：我的公司开发了JProfiler）将帮助您找到这些线程局部变量。选择报告的值类（com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty或com.sun.xml.bind.v2.ClassFactory）并显示累积的传入引用。其中之一是

java.lang.ThreadLocal$ThreadLocalMap$条目

。选择该传入引用类型的引用对象，然后切换到“分配”视图。您将看到实例已分配到何处。有了这些信息，你就可以决定你是否可以做些什么

---

我猜您可能看到了这一点，但以防万一ehcache doc建议您这样做。

创建线程而不正确清理它们最终会耗尽内存-已经完成，完成了

那些仍在寻求快速解决方案/解决方法的人，可以选择以下内容：

• 如果运行独立的tomcat，请杀死javaw.exe或承载它的进程
• 如果从eclipse运行，请终止eclipse.exe和java.exe或封闭进程
• 仍然未解决，请检查任务管理器，导致此问题的进程很可能会显示最高内存 使用-做你的分析，并杀死它

---

您应该能够很好地重新部署这些内容，并在没有内存问题的情况下继续操作

Mattias Jiderhamn有一个很好的 这非常清楚地解释了classloader泄漏的理论和实践。更好的是，他还发布了一个jar文件，我们可以将其包含在我们的war文件中。我在我的网络应用程序上试用了它，jar文件工作得很好！jar文件名为classloader-leak-prevention.jar。使用它就像将它添加到web.xml一样简单

<listener>
  <listener-class>se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor</listener-class>
</listener>

se.jiderhamn.classloader.leak.prevention.classloader防泄漏器

然后将其添加到pom.xml中

<dependency>
  <groupId>se.jiderhamn</groupId>
  <artifactId>classloader-leak-prevention</artifactId>
  <version>1.15.2</version>
</dependency>

吉德哈姆东南酒店
或
我建议在一个特定的环境中初始化

ServletRequestListener
有两种方法：一种用于初始化，另一种用于销毁

这样，您就可以清理
线程本地
。例如：

public class ContextInitiator implements ServletRequestListener {
    @Override
    public void requestInitialized(ServletRequestEvent sre) {
        context = new ThreadLocal<ContextThreadLocal>() {
            @Override
            protected ContextThreadLocal initialValue() {
                ContextThreadLocal context = new ContextThreadLocal();
                return context;
            }
        };
        context.get().setRequest(sre.getServletRequest());
    }
    @Override
    public void requestDestroyed(ServletRequestEvent sre) {
        context.remove();
    }
}

正如我所看到的，JProfiler似乎不是一个免费的开源解决方案。你能推荐一些其他的吗alternative@RaghavEclipse内存分析器也非常适合分析堆转储。这些警告意味着您在不重新启动Tomcat本身的情况下重新部署应用程序的能力是有限的。这种类型的内存泄漏长期困扰着Webapps。除非重新部署应用程序，否则它们不会产生任何影响。我不知道，但我怀疑Tomcat输出中的这些消息（它在一两年后又开始出现）会对框架构建者施加压力，要求他们在重启后开始正确清理。
<listener>
    <listener-class>ContextInitiator</listener-class>
</listener>