由于Tomcat中的孤立线程,我遇到了内存泄漏。特别是,Guice和JDBC驱动程序似乎没有关闭线程。
Aug 8, 2012 4:09:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [com.google.inject.internal.util.$Finalizer] but has failed to stop it. This is very likely to create a memory leak.
Aug 8, 2012 4:09:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [Abandoned connection cleanup thread] but has failed to stop it. This is very likely to create a memory leak.
我知道这与其他问题,但是就我而言,“不必担心”的答案是不够的,因为它给我带来了麻烦。我的CI服务器会定期更新此应用程序,重新加载6-10次后,由于Tomcat内存不足,CI服务器将挂起。
我需要能够清理这些孤立的线程,以便可以更可靠地运行CI服务器。任何帮助,将不胜感激!
我自己解决了这个问题。与其他答案相反,我不建议发出该t.stop()
命令。此方法已被弃用,这是有充分理由的。请参考Oracle这样做的原因。
但是,有一种解决方案可以消除此错误,而无需诉诸t.stop()
…
您可以使用提供的大多数代码@Oso,只需替换以下部分
Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
Thread[] threadArray = threadSet.toArray(new Thread[threadSet.size()]);
for(Thread t:threadArray) {
if(t.getName().contains("Abandoned connection cleanup thread")) {
synchronized(t) {
t.stop(); //don't complain, it works
}
}
}
使用MySQL驱动程序提供的以下方法替换它:
try {
AbandonedConnectionCleanupThread.shutdown();
} catch (InterruptedException e) {
logger.warn("SEVERE problem cleaning up: " + e.getMessage());
e.printStackTrace();
}
这应该正确地关闭线程,并且错误应该消失。
问题内容: 好的,所以我的程序有很多(〜300)线程,每个线程都与中央数据库通信。我创建了一个与数据库的全局连接,然后每个线程进行其业务创建语句并执行它们。 一路上的某个地方,我发生了大量内存泄漏。在分析堆转储之后,我看到com.mysql.jdbc.JDBC4Connection对象为70 MB,因为它在“ openStatements”(哈希映射)中有800,000个项目。在某个地方,它不能正
我的tomcat日志中有这些消息: “org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc web应用程序注册了JBDC驱动程序[com.mysql.jdbc.driver],但在web应用程序停止时未能注销它。为了防止内存泄漏,已强制注销jdbc驱动程序。” 和 “org.apache.catalina.loader.W
我正在编写一个spring boot 2应用程序,我正在使用SQL批量复制功能在SQL Server2012数据库中插入几条记录。每插入700行,我就有600 MB的泄漏 我已经试用了Microsoft驱动程序版本6.4.0.jre8和7.2.2.jre8,但任何东西都改变了。我尝试为tomcat更改Hikari连接池,但结果是一样的。 为了调用Microsoft API,我使用了包装器框架(ht
问题内容: 我认为我的android应用正在泄漏内存。我不是绝对确定这是问题所在。 应用程序打开时经常崩溃,并且logcat尝试加载位图图像时会显示“内存不足”异常。 崩溃后,我重新打开了该应用程序,它运行正常。Logcat会显示许多“ gc”,并且JIT表会不时地向上调整大小,而不会向下调整,直到应用程序因内存不足错误而崩溃。 这听起来像是内存泄漏吗?如果是这样,我该如何定位和关闭泄漏点。 这是
问题内容: 我一直在追寻内存泄漏(由“ valgrind –leak-check = yes”报告),它似乎来自ALSA。这段代码已经存在于自由世界中一段时间了,所以我猜这是我做错的事情。 输出看起来像这样: 并继续一些页面 这是由于我在一个项目中使用ALSA并开始看到这种巨大的泄漏……或者至少是所说泄漏的报告。 所以问题是:是我,ALSA或valgrind在这里遇到问题吗? 问题答案: ht
问题内容: 我有一个长时间运行的脚本,如果让脚本运行足够长的时间,它将消耗系统上的所有内存。 在不详细介绍脚本的情况下,我有两个问题: 是否有可遵循的“最佳实践”,以防止泄漏发生? 有什么技术可以调试Python中的内存泄漏? 问题答案: 看看这篇文章:跟踪python内存泄漏 另外,请注意,垃圾收集模块实际上可以设置调试标志。看一下功能。此外,请查看Gnibbler的这段代码,以确定调用后已创建