Tomcat 6内存泄漏日志条目 [英] Tomcat 6 memory leaks log entries

问题描述

以下是我在CentOS机器上的Catalina.out文件中输入的唯一条目。我正在使用Spring 3和我的应用程序运行Tomcat 6。有很多这样的，所以我选择了一些不断重复的东西。这不会一直发生，但每周至少发生一次。

Below is outtake of unique entries in my Catalina.out file on CentOS machine. I'm running Tomcat 6 with spring 3 and my application. There is whole bunch of them so I just picked some that keep repeating. This doesn't happen all the time but it happens at least once a week.

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc

SEVERE: The web application [] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named [com.iteezy.shared.domain.DirEntry.data] but has failed to stop it. This is very likely to create a memory leak.


Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named

[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but has failed to stop it. This is very likely to create a memory leak.


Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads  

SEVERE: The web application [] appears to have started a thread named [File Reaper] but has failed to stop it. This is very likely to create a memory leak.

Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

SEVERE: The web application [] appears to have started a thread named [pool-1-thread-22] but has failed to stop it. This is very likely to create a memory leak.  

37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
b application [] appears to have started a thread named 

[org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2] but has failed to stop it. This is very likely to create a memory leak.

37:48 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap

b application [] created a ThreadLocal with key of type [net.sf.json.AbstractJSON$1] (value [net.sf.json.AbstractJSON$1@40bbb3d6]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.

推荐答案

当你定义一个线程假设的外部标志时在设置时轮询并退出 - 它必须是 volatile 。否则，线程可能永远不会看到其他线程所做的更改。

When you define an external flag which a thread is suppose to poll and exit when it's set - it must be volatile. Otherwise the thread might never see the change made by other thread.

但是在标准API中已经存在类似的功能 - 它被称为 interrupt（）方法和 Thread.currentThread（）。isInterrupted（）。无需复制已有的逻辑。请参阅：停止特定的Java线程。

However there is already a feature like that in standard API - it is called an interrupt() method and Thread.currentThread().isInterrupted(). No need to duplicate already existing logic. See: Stopping a specific java thread.

据说在每个线程上调用 interrupt（）也是一个坏主意，因为不能保证所有线程都响应它。检查您的异常我注意到以下线程未正确清理：

That being said calling interrupt() on each and every thread is a bad idea as well because there is no guarantee that all threads respond to it. Examining your exceptions I noticed the following threads not being cleaned up properly:

• com.mchange.v2 .async.ThreadPoolAsynchronousRunner $ PoolThread-＃0 - 关闭C3P0数据源。由于您使用的是Spring，只需添加 destroy-method =close。我们已经完成了这个帖子。

• com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0 - close the C3P0 data source. Since you are using Spring simply add destroy-method="close". We're done with this thread.

文件收割机 - 据我所知看到这个帖子由 FileCleaningTracker 创建。关闭应用程序时（或者不再需要类，我从未使用过它）或者让Spring执行此操作时，您需要显式调用 FileCleaningTracker.exitWhenFinished（）（往上看）。有可能是某些第三方库使用它而没有正确关闭 - 这意味着它有一个错误。

File Reaper - as far as I can see this thread is created by FileCleaningTracker. You need to call FileCleaningTracker.exitWhenFinished() explicitly when shutting down your application (or when the class is no longer needed, I never used it) or let Spring to do this (see above). Chances are some 3rd party library uses it and not closing properly - this means it has a bug.

pool-1-thread- 22 - 这是 执行者 实用程序 ExecutorService 。确保在关机期间在应用程序中的每个此类池上调用 shutdown（）。

org.springframework.scheduling.quartz.SchedulerFactoryBean＃0_Worker-2 - Quartz工作线程（实际运行作业的线程）。 SchedulerFactoryBean 自动关闭调度程序，我认为Tomcat在这里错了，我也经常看到这个错误。不过看起来像设置 SchedulerFactoryBean.waitForJobsToCompleteOnShutdown 到 true 解决了这个问题。

org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2 - Quartz worker thread (the one that actually runs jobs). SchedulerFactoryBean closes the scheduler for you automatically, I think Tomcat is mistaken here, I see this error often as well. Nevertheless looks like setting SchedulerFactoryBean.waitForJobsToCompleteOnShutdown to true solves this.

com.iteezy.shared.domain.DirEntry.data - 我不确定这个。它是您自己的线程，需要在关机时中断或H2数据库线程（？）需要检查其堆栈以猜测它来自何处。

com.iteezy.shared.domain.DirEntry.data - I am not sure about this one. It is either your own thread that needs to be interrupted upon shutdown or H2 database thread (?) Its stack needs to be examined to guess where does it come from.

底线是：不要只是杀死所有移动的东西（实际上，Tomcat在发出此警告后为你做了这一点）但是确定线程的来源并使用特定的框架/库 close（）允许进一步清理的方法。要温柔。

The bottom line is: don't just kill everything that moves (actually, Tomcat does that for you after issuing this warning) but determine where the threads come from and use framework/library specific close() method to allow further cleanup. Be gentle.

这篇关于Tomcat 6内存泄漏日志条目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！