Java_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。

在maven中添加如下配置：

<listener>
<listener-class>
se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor
</listener-class>
</listener>

去西湖玩一天

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之前。

下面是自己翻阅的一些资料：

英文的资料：http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ （在此链接可找到最新的maven地址以及源码地址以及非maven得jar）

Git源码地址：https://github.com/mjiderhamn/classloader-leak-prevention