内存泄漏 - metrics-meter-tick-thread和新I / O客户端工作程序

Question

我正在运行spring-mvc应用程序。当我关闭Tomcat服务器时，它会显示

SEVERE: The web application [/myapp] appears to have started a thread named [metrics-meter-tick-thread-1] but has failed to stop it. This is very likely to create a memory leak.
SEVERE: The web application [/myapp] appears to have started a thread named [metrics-meter-tick-thread-2] but has failed to stop it. This is very likely to create a memory leak.

和这一个：

SEVERE: The web application [/myapp] appears to have started a thread named [New I/O client worker #1-3] but has failed to stop it. This is very likely to create a memory leak.

SEVERE: The web application [/anant] created a ThreadLocal with key of type [org.jboss.netty.util.CharsetUtil$2] (value [org.jboss.netty.util.CharsetUtil$2@5db3978d]) and a value of type [java.util.IdentityHashMap] (value [{UTF-8=sun.nio.cs.UTF_8$Decoder@39a2da0a}]) 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.

这个人不知道哪个罐子可能是netty

当我探讨罐子依赖时，我发现有两个metrics-core罐子：

metrics-core:2.2.0 (used by `datastax`)
metrics-core:3.0.1 (used by `Titan`)

我附上所有快照以使其更清晰。那么解决方案是什么？

我正在使用

jdk1.7 cassandra-driver-core-1.0.4 titan-0.4.4 cassandra-1.2.2 tomcat-7.0.34

Answer 1

检查启动metrics-meter-tick-thread *线程的内容，无论是您的webapp还是某些库。在关闭应用程序之前停止线程。 请参阅Tomcat wiki link解释它是如何产生内存泄漏的。它还解释了未清理的ThreadLocal变量如何导致内存泄漏。

  

由webapps生成的主题

     

默认情况下，如果webapp创建了一个线程   它的上下文类加载器被设置为父线程之一（   创建新线程的线程）。在webapp中，这个父线程   是tomcat工作线程之一，其上下文类加载器设置为   webapp类加载器执行webapp代码时。

     

此外，生成的线程可能正在执行（或阻塞）某些线程   涉及webapp加载的类的代码，从而阻止了   收集webapp类加载器。

     

因此，如果生成的线程未正确终止时   应用程序停止，webapp类加载器将因泄漏而泄漏   产生线程所持有的强大参考。

Answer 2

我知道我这有点晚了。我有同样的问题，最终找到了解决方案。问题是指标2.2 JAR（产生这些线程）使用ManagementFactory.getPlatformMBeanServer()方法，如Oracle所建议的那样。此类位于java.lang包中，因此它将由 VM 集中加载，而不是每个模块加载。因此，由于Metrics包只会在 VM 出口上自行关闭这些线程（通过添加shutdown-hook），加载此包的类加载器将允许通过包指定的MXBeans会在模块卸载时停留。更糟糕的是，加载 war 文件的类加载器也将保留在 VM 上，其中（传递上）还包括任何在模块中加载的类和任何静态状态。

您可以手动拨打Metrics.shutdown()，这有时可以解决问题。我确实遇到了一些奇怪的解决方案问题（有时候线程在此之后仍然存在，但我有一个非常奇特的设置，并且不想再浪费时间在这个问题上。）