ClassLoader内存溢出-从tomcat的reload说起

原文链接:http://nius.me/classloader-memory-leak/

对于j2ee项目,一直使用eclipse的wtp,每次修改代码后,可以自动热部署。简单的项目wtp似乎没什么问题,但一旦项目代码稍微多一点,就很容易出现各种莫名其妙掉挂的现象,不得不整个重启tomcat服务器,这个时候就很痛苦了。

于是,我换用了maven的jetty插件,启动一个轻量级的jetty服务器,这下热部署似乎没那么多问题了!但是jetty似乎在热部署几次之后,也仍然会崩溃!这是什么情况!tomcat和jetty到底发生了什么?jetty的崩溃最常看见的异常就是OutOfMemoryException,Perm区的内存占满了

short version

不要慌!为了节省时间,先上解决方案:classloader-leak-prevention

  1. 在maven中添加如下配置:
<dependency>
  <groupId>se.jiderhamn</groupId>
  <artifactId>classloader-leak-prevention</artifactId>
  <version>1.9.3</version>
</dependency>
  1. 在web.xml__顶部__添加一个listener
<listener>
    <listener-class>
        se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor
    </listener-class>
</listener>
  1. 去西湖玩一天

long version

看看Perm区到底都是些啥

今天实在忍不了了,上Visual VM,监视一下Perm区的情况。

果然,reload几次之后,Perm的使用量蹭蹭的往上涨。看看Perm区都是啥

怎么这么多char[]呀,好像也看不出什么,还是dump一下吧。中间翻阅了一些博客,觉得应该是class loader的问题。oql查询一下。(这里因为是jetty,所以查询了jetty的WebAppClassLoader,如果使用tomcat或者其他容器,应该有对应的Loader,可以通过Saved Queries->PermGen Analysis->ClassLoader Types看一下有哪些ClassLoader)


上图是刚启动的时候,WebAppClassLoader只有一个实例。经过两次reload,嘿,问题来了。如下图:

居然出现了3个WebAppClassLoader实例,前两个Loader都没有销毁!哟呵呵,gc销不掉,一会就进Perm区了,然后多几次reload,Perm区再大也都撑满了。

发生了什么,gc不靠谱?

首先,我们回忆一下gc的运作过程。通过minor gc,清理eden区(eden generation)的没有被引用的对象,活下来的进入suvivor区,接下来的minor gc会让对象在两个suvivor里面倒腾倒腾,挺过几次的进入old区,这里面进行的就是full gc了,耗时长,如果old区还挺了好几次,就会进入Perm区。Perm里面发生的也是full gc.

一个普通对象,只要没有引用了,就一定会在某一次gc被回收。那么ClassLoader进入了Perm,说明在reload的时候,虽然程序取消了对Classloader的直接引用,但是仍然有其他对象间接的引用了ClassLoader。其实如果单纯的仅仅是ClassLoader一个对象,也就罢了,但是ClassLoader并不是一个普通的对象。

任何一个Java类,都是通过某个ClassLoader加载的。通过这个ClassLoader加载的类的实例,会保存这个类对象的引用,也就是MyClass.class这种。而类对象,会保留这个ClassLoader的引用。反过来,在ClassLoader中,也会保持对这个类对象的引用。(注意区分类对象MyClass.class,不是这个类的实例。好吧如果还是混淆了,我也不知道该怎么说清楚了)。关键在于,ClassLoader和类对象之间是双向引用。

双向引用有什么问题嘛?一般情况下没有问题。因为如果ClassLoader的外界引用,和具体类对象的外界引用都消失了,那么这两个对象都不可达了,都会被gc。但是在一些情况下,类对象可能不仅仅被这个类的实例保存,还可能被其他对象保存!如果这个对象是其他OtherClassLoader加载的呢?那意味着,如果这个对象不回收,那么其引用的类对象不会被回收,于是ClassLoader不会被回收,于是,所有ClassLoader加载的类对象都不会被回收!WebAppClassLoader会加载多少个类?如果你恰好使用的是Spring、Hibernate这种大家伙,嚯嚯。如果对此很感兴趣,这里有一篇写的很详细的:Anatomy of a PermGen Memory Leak

怎么解决

你并不知道什么时候会出现某个外部对象会引用到类对象。所以解决问题的思路是,换一个ClassLoader。一开始的解决方案classloader-leak-prevention就是依赖这个思路的。核心代码如下:

      // Switch to system classloader in before we load/call some JRE stuff that will cause 
      // the current classloader to be available for garbage collection
      Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoader());

      try {
        java.awt.Toolkit.getDefaultToolkit(); // Will start a Thread
      }
      catch (Throwable t) {
        error(t);
        warn("Consider adding -Djava.awt.headless=true to your JVM parameters");
      }

      java.security.Security.getProviders();
      
      java.sql.DriverManager.getDrivers(); // Load initial drivers using system classloader

      javax.imageio.ImageIO.getCacheDirectory(); // Will call sun.awt.AppContext.getAppContext()

让这一段代码运行在servlet初始化之前,在所有的listener之前。

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>