在Tomcat中重新部署应用程序时出现内存泄漏 [英] Memory leak when redeploying application in Tomcat

问题描述

当我在 tomcat 中重新部署我的应用程序时，出现以下问题:

When I redeploy my application in tomcat, I get the following issue:

 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.这似乎也导致了以下异常.

Also, am using ehcache in my application. This also seems to result in the following exception.

     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 似乎创建了一个弱哈希映射，我收到消息说这很可能会造成内存泄漏.

The ehcache seems to create a weak hash map and I get the message that this is very likely to create a memory leak.

我在网上搜了一下，找到了这个，http://jira.pentaho.com/browse/PRD-3616 但我没有访问服务器.

I searched over the net and found this, http://jira.pentaho.com/browse/PRD-3616 but I dont have access to the server as such.

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

Please let me know if these warnings have any functional impact or can they be ignored? I used the "Find Memory leaks" option in tomcat manager and it says "No memory leaks found"

推荐答案

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

When you redeploy your application, Tomcat creates a new class loader. The old class loader must be garbage collected, otherwise you get a permgen memory leak.

Tomcat 无法检查垃圾收集是否有效，但它知道几个常见的故障点.如果 webapp 类加载器使用一个实例设置了一个 ThreadLocal ，该实例的类是由 webapp 类加载器本身加载的，那么 servlet 线程将持有对该实例的引用.这意味着类加载器不会被垃圾回收.

Tomcat cannot check if the garbage collection will work or not, but it knows about several common points of failures. If the webapp class loader sets a ThreadLocal with an instance whose class was loaded by the webapp class loader itself, the servlet thread holds a reference to that instance. This means that the class loader will not be garbage collected.

Tomcat 会执行许多此类检测，请参阅此处了解更多信息.清理线程局部变量很困难，您必须在被访问的每个线程中的 ThreadLocal 上调用 remove().实际上，这仅在开发期间多次重新部署 Web 应用程序时才重要.在生产中，您可能不会重新部署，因此可以忽略.

Tomcat does a number of such detections, see here for more information. Cleaning thread locals is difficult, you would have to call remove() on the ThreadLocal in each of the threads that is was accessed from. In practice this is only important during development when you redeploy your web app multiple times. In production, you probably do not redeploy, so this can be ignored.

要真正找出哪些实例定义了线程局部变量，您必须使用分析器.例如JProfiler中的heap walker(免责声明:我公司开发JProfiler)将帮助您找到那些线程本地人.选择报告的值类(com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty 或 com.sun.xml.bind.v2.ClassFactory)并显示累积的传入引用.其中之一是 java.lang.ThreadLocal$ThreadLocalMap$Entry.选择该传入引用类型的引用对象并切换到分配视图.您将看到实例已分配到何处.有了这些信息，您就可以决定是否可以做些什么.

To really find out which instances define the thread locals, you have to use a profiler. For example the heap walker in JProfiler (disclaimer: my company develops JProfiler) will help you to find those thread locals. Select the reported value class (com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty or com.sun.xml.bind.v2.ClassFactory) and show the cumulated incoming references. One of those will be a java.lang.ThreadLocal$ThreadLocalMap$Entry. Select the referenced objects for that incoming reference type and switch to the allocations view. You will see where the instance has been allocated. With that information you can decide whether you can do something about it or not.

这篇关于在Tomcat中重新部署应用程序时出现内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！