Tomcat：重启是解决Threadlocal导致内存泄漏的唯一方法吗？

我们在生产环境中使用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"]

---

终端用户在此时间段内未记录任何客户活动，因为当时是清晨。我们只是重新启动了服务器，一切正常。但重启是最好的解决方案吗？还是这个问题会再次发生

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

相反，您应该添加VM参数

-XX:+heapdumponotofmemoryerror

，以便在发生OutOfMemoryError时创建堆转储。当这种情况再次发生时，可以使用堆转储分析器打开堆转储，如。在那里，您可以进行进一步调查，以找到泄漏原因。例如，您可以查看支配者树，以找到通过引用保存最多内存的对象。如果您发现了可疑的东西，可以在这里发布Eclipse MAT的截图

---

如果您不想等到OutOfMemory错误再次出现，那么您也可以在应用程序运行一段时间后手动创建heapdump并对其进行分析。

重新部署应用程序时是否重新启动tomcat？或者您只是重新部署应用程序而不重新启动tomcat？关于tomcat的内存泄漏，我建议您从ApacheWiki阅读此页面：这些是日志中的第一个错误吗？在尝试停止/取消部署应用程序时，这些看起来像是错误，就像是先发生了其他事情一样