Tomcat:重启是线程导致的内存泄漏的唯一解决方案吗？

Question

我们在生产环境中使用apache-tomcat-8.0.20。

由于以下错误，我们的应用程序(Japha)突然崩溃，服务器自动关闭：

25-Nov-2015 05:20:37.311 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Japha] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@2472eccc]) and a value of type [com.sun.xml.stream.XMLReaderImpl] (value [com.sun.xml.stream.XMLReaderImpl@24d1f33]) 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.
25-Nov-2015 05:20:37.311 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Japha] created a ThreadLocal with key of type [com.sun.xml.bind.v2.runtime.Coordinator$1] (value [com.sun.xml.bind.v2.runtime.Coordinator$1@73b0e605d]) and a value of type [com.sun.xml.bind.v2.runtime.Coordinator[]] (value [[Lcom.sun.xml.bind.v2.runtime.Coordinator;@2d42463a5b]) 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.

最后它停止了所有的连接器

25-Nov-2015 05:20:37.327 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [Japha] created a ThreadLocal with key of type [com.sun.xml.ws.api.client.ServiceInterceptorFactory$1] (value [com.sun.xml.ws.api.client.ServiceInterceptorFactory$1@434ba48d]) and a value of type [java.util.HashSet] (value [[]]) 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.
25-Nov-2015 05:20:37.356 INFO [Thread-7] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-8080"]
25-Nov-2015 05:20:37.453 INFO [Thread-7] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-nio-8009"]
25-Nov-2015 05:20:37.462 INFO [Thread-7] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-8080"]
25-Nov-2015 05:20:37.464 INFO [Thread-7] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-nio-8009"]

最终用户在这段时间内没有记录任何客户活动，因为当时是清晨。我们简单地重新启动了服务器，一切都运行得很好。但是，重新启动是最好的解决方案吗？或者这个问题还会再次发生吗？

Answer 1

因为您在每次重新部署时都重启Tomcat，所以您的内存泄漏不是由Tomcat WebappClassLoader的类加载器泄漏引起的，这是与Tomcat相关的内存泄漏的最常见原因。因此，你可以忽略我在评论中发布的链接。

相反，您应该添加VM参数-XX:+HeapDumpOnOutOfMemoryError，以便在发生OutOfMemoryError时创建堆转储。当这种情况再次发生时，您可以使用像Eclipse MAT这样的堆转储分析器打开堆转储。在那里你可以做进一步的调查，以找出泄漏的原因。例如，你可以查看主导者树，以便通过引用找到拥有最大内存量的对象。如果你发现了可疑的东西，你可以在这里发布一张Eclipse MAT的截图。

如果您不想等到OutOfMemoryError再次发生，那么您也可以在应用程序运行一段时间后手动创建堆转储并对其进行分析。