Tomcat如何检测内存泄漏
一般情况下,如果我们重启web应用是通过重启tomcat的话,则不存在内存泄漏问题。但如果不重启tomcat而对web应用进行重加载则可能会导致内存泄漏,因为重加载后有可能会导致原来的某些内存无法让GC回收,例如web应用使用了JDBC,驱动会进行注册,当web应用停止时没有反注册就会导致内存泄漏。
看看是什么原因导致tomcat内存泄漏的。这个要从热部署开始说起,因为tomcat提供了不必重启容器而只需重启web应用以达到热部署的功能,其实现是通过定义一个WebappClassLoader类加载器,当热部署时就将原来的类加载器废弃并重新实例化一个WebappClassLoader类加载器。但这种方式可能存在内存泄漏问题,因为ClassLoader是一个结构复杂的对象,导致它不能被GC回收的可能性比较多,除了对ClassLoader对象有引用可能导致其无法回收,还可能对其加载的元数据(方法、类、字段等)有引用都会导致无法被GC回收。
如上图,tomcat的资源由不同类加载器加载,这里只看BootstrapClassLoader和WebappClassLoader两个类加载器,BootstrapClassLoader负责加载rt.jar包的Java.sql.DriverManager,WebappClassLoader负责加载web应用中的MySQL驱动包,其中有一个很重要的步骤是mysql的驱动类需要注册到DriverManager中,即DriverManager.registerDriver(new Driver()),它由mysql驱动包自动完成。这样一来当web应用进行热部署操作时,没有将mysql的Driver从DriverManager中反注册掉的话,则会导致整个WebappClassLoader回收不了,造成内存泄漏。
接着看tomcat如何对此内存泄漏进行监控的,要判断WebappClassLoader会不会导致内存泄漏只需判断WebappClassLoader有没有被GC回收即可。在Java中有一种引用叫弱引用,它能很好判断WebappClassLoader有没有被GC回收,被弱引用关联的对象只能生存到下一次垃圾回收发生之前,即如果某WebappClassLoader对象只被某弱引用关联,则它会在下次垃圾回收时被回收,但如果WebappClassLoader对象除了被弱引用关联外还被其他对象强引用,那么WebappClassLoader对象是不会被回收的,根据这些条件就可以判断是否有WebappClassLoader内存泄漏了。
Tomcat的实现是通过WeakHashMap来实现弱引用的,只需将WebappClassLoader对象put到WeakHashMap中,例如weakMap.put(“a”,webappClassLoader),当webappClassLoader及其包含的元素没有被其它任何类加载器中的元素引用到时,JVM发生垃圾回收时则会把webappClassLoader对象回收。
简单的实现代码大致如下:
public class MemoryLeakTest{ private Map<ClassLoader, String> childClassLoaders = new WeakHashMap<ClassLoader, String>(); public String[] findReloadedContextMemoryLeaks() { System.gc(); List<String> result = new ArrayList<String>(); for (Map.Entry<ClassLoader, String> entry : childClassLoaders.entrySet()) { ClassLoader cl = entry.getKey(); if (!((WebappClassLoader) cl).isStarted()) { result.add(entry.getValue()); } } return result.toArray(new String[result.size()]); } }
使用一个WeakHashMap用于跟踪WebappClassLoader,在查找内存泄漏之前会先强制调用System.gc();进行一次垃圾回收,保证没问题的WebappClassLoader都被回收掉,这时如果还有WebappClassLoader的状态是非started(正常启动的都为started,关闭了的则为非started)的,则是未被垃圾回收的WebappClassLoader,属于内存泄漏的。
感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!
问题内容: 由于Tomcat中的孤立线程,我遇到了内存泄漏。特别是,Guice和JDBC驱动程序似乎没有关闭线程。 我知道这与其他问题,但是就我而言,“不必担心”的答案是不够的,因为它给我带来了麻烦。我的CI服务器会定期更新此应用程序,重新加载6-10次后,由于Tomcat内存不足,CI服务器将挂起。 我需要能够清理这些孤立的线程,以便可以更可靠地运行CI服务器。任何帮助,将不胜感激! 问题答案:
问题内容: 是否有一些工具可以检测Node.js中的内存泄漏?并告诉我您在测试nodejs应用程序方面的经验。 问题答案: 以下工具对于发现内存泄漏很有用: 节点检查器 还有一个教程可以帮助您在此处查找内存泄漏: https://github.com/felixge/node-memory-leak- tutorial
我在哪里可以找到libc_malloc_debug_leak。还有libc_malloc_debug_qemu。那么对于不同的Android版本(冰淇淋三明治、果冻豆、KitKat)和不同的设备(Galaxy Nexus、Nexus 7、Nexus 10)呢?
问题内容: 我收到以下警告: 我在server.js中编写了这样的代码: 如何解决呢? 问题答案: 这是在解释节点eventEmitter文档 这是哪个版本的Node?您还有什么其他代码?那不是正常行为。 简而言之,其:
我的tomcat日志中有这些消息: “org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc web应用程序注册了JBDC驱动程序[com.mysql.jdbc.driver],但在web应用程序停止时未能注销它。为了防止内存泄漏,已强制注销jdbc驱动程序。” 和 “org.apache.catalina.loader.W
问题内容: 以下是我在CentOS机器上的Catalina.out文件中唯一条目的录入。我正在使用Spring 3和我的应用程序运行Tomcat 6。他们一整堆,所以我只是挑选了一些不断重复的东西。这并非一直发生,但至少每周发生一次。 问题是我该怎么做才能防止风箱发生? 问题答案: 当您定义一个外部标志时,应该在设置 该标志的同时轮询该线程并退出该线程。否则,该线程可能永远不会看到其他线程所做的更