groovy脚本导致的FullGC问题

这个是由一个线上问题导致的：

背景： 
应用中内嵌了groovy引擎，会动态执行传入的表达式并返回执行结果 
线上问题：

• 发现机器的fullGC从某个时候开始暴涨，并且一直持续；
• 登到机器上，用jstat -gcutil 命令观察，发现perm区一直是100%，fullGC无法回收；
• 将这台机器的内存dump出来进行分析；
• 在类视图中，发现大量的groovy.lang.GroovyClassLoader$InnerLoader;
• 在类加载器视图里面也看到大量的groovy的InnerLoader；

• 基本上可以定位问题在groovy脚本的加载处；

  初步的问题分析：

groovy每执行一次脚本，都会生成一个脚本的class对象，并new一个InnerLoader去加载这个对象，而InnerLoader和脚本对象都无法在fullGC的时候被回收，因此运行一段时间后将PERM占满，一直触发fullGC。

因此，跟了一下groovy的编译脚本的源码：

脚本编译的入口是GroovyShell的parse方法：

public Script parse(GroovyCodeSource codeSource)    throws CompilationFailedException
 {
 return InvokerHelper.createScript(parseClass(codeSource), this.context);
}

所有的脚本都是由GroovyClassLoader加载的，每次加载脚本都会生成一个新的InnerLoader去加载脚本，但InnerLoader只是继承GroovyClassLoader，加载脚本的时候，也是交给GroovyClassLoader去加载：

创建新的innerLoader：

InnerLoader loader = (InnerLoader)AccessController.doPrivileged(new PrivilegedAction() {
public GroovyClassLoader.InnerLoader run() {
return new GroovyClassLoader.InnerLoader(GroovyClassLoader.this);
     }
   });

innerLoader继承GroovyClassLoader：

 public static class InnerLoader extends GroovyClassLoader {
    private final GroovyClassLoader delegate;
   private final long timeStamp;

    public InnerLoader(GroovyClassLoader delegate) {
     super();
       this.delegate = delegate;
      this.timeStamp = System.currentTimeMillis();
   }

innerLoader的类加载是交给GroovyClassLoader进行的：

public Class loadClass(String name, boolean lookupScriptFiles, boolean preferClassOverScript, boolean resolve) throws ClassNotFoundException, CompilationFailedException {
    Class c = findLoadedClass(name);
   if (c != null) return c;
      return this.delegate.loadClass(name, lookupScriptFiles, preferClassOverScript, resolve);
     }

GroovyClassLoader的类加载：

private Class doParseClass(GroovyCodeSource codeSource) {
     validate(codeSource);
    CompilationUnit unit = createCompilationUnit(this.config, codeSource.getCodeSource());
    SourceUnit su = null;
     File file = codeSource.getFile();
    if (file != null) {
      su = unit.addSource(file);
    } else {
       URL url = codeSource.getURL();
      if (url != null) {
         su = unit.addSource(url);
       } else {
        su = unit.addSource(codeSource.getName(), codeSource.getScriptText());
}
   }
    ClassCollector collector = createCollector(unit, su);
     unit.setClassgenCallback(collector);
    int goalPhase = 7;
   if ((this.config != null) && (this.config.getTargetDirectory() != null)) goalPhase = 8;
    unit.compile(goalPhase);
    Class answer = collector.generatedClass;
     String mainClass = su.getAST().getMainClassName();
     for (Object o : collector.getLoadedClasses()) {
      Class clazz = (Class)o;
       String clazzName = clazz.getName();
       definePackage(clazzName);
      setClassCacheEntry(clazz);
      if (clazzName.equals(mainClass)) answer = clazz;
    }
    return answer;
}

使用InnerLoader加载脚本的原因参见groovy的classloader加载原理，总结的原因如下，但是在这次的线上问题中，虽然用新创建的InnerLoader加载脚本，但是fullGC的时候，脚本对象和InnerLoader都无法被回收：

• 由于一个ClassLoader对于同一个名字的类只能加载一次，如果都由GroovyClassLoader加载，那么当一个脚本里定义了C这个类之后，另外一个脚本再定义一个C类的话，GroovyClassLoader就无法加载了。
• 由于当一个类的ClassLoader被GC之后，这个类才能被GC，如果由GroovyClassLoader加载所有的类，那么只有当GroovyClassLoader被GC了，所有这些类才能被GC，而如果用InnerLoader的话，由于编译完源代码之后，已经没有对它的外部引用，除了它加载的类，所以只要它加载的类没有被引用之后，它以及它加载的类就都可以被GC了。

InnerLoader的依赖路径：

groovy.lang.GroovyClassLoader$InnerLoader@18622f3  
groovy.lang.GroovyClassLoader@147c1db  
org.codehaus.groovy.tools.RootLoader@186db54  
sun.misc.Launcher$AppClassLoader@192d342  
sun.misc.Launcher$ExtClassLoader@6b97fd  

这里有个问题，JVM满足GC的条件：

JVM中的Class只有满足以下三个条件，才能被GC回收，也就是该Class被卸载（unload）：

• 该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例。
• 加载该类的ClassLoader已经被GC。
• 该类的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法.

逐条检查GC的条件：

• Groovy会把脚本编译为一个名为Scriptxx的类，这个脚本类运行时用反射生成一个实例并调用它的MAIN函数执行，这个动作只会被执行一次，在应用里面不会有其他地方引用该类或它生成的实例。

groovy执行脚本的代码：

final GroovyObject object = (GroovyObject) scriptClass
                        .newInstance();
                if (object instanceof Script) {
                    script = (Script) object;
                } else {
                    // it could just be a class, so lets wrap it in a Script
                    // wrapper
                    // though the bindings will be ignored
                    script = new Script() {
                        public Object run() {
                            Object args = getBinding().getVariables().get("args");
                            Object argsToPass = EMPTY_MAIN_ARGS;
                            if(args != null && args instanceof String[]) {
                                argsToPass = args;
                            }
                            object.invokeMethod("main", argsToPass);
                            return null;
                        }
                    };
                    setProperties(object, context.getVariables());
                }

• 上面已经讲过，Groovy专门在编译每个脚本时new一个InnerLoader就是为了解决GC的问题，所以InnerLoader应该是独立的，并且在应用中不会被引用；

只剩下第三种可能：

• 该类的Class对象有被引用

进一步观察内存的dump快照，在对象视图中找到Scriptxx的class对象，然后查看它在PERM代的被引用路径以及GC的根路径。

发现Scriptxxx的class对象被一个HashMap引用，如下：

classCache groovy.lang.GroovyClassLoader

发现groovyClassLoader中有一个class对象的缓存，进一步跟下去，发现每次编译脚本时都会在Map中缓存这个对象，即：

setClassCacheEntry(clazz);

再次确认问题原因：

每次groovy编译脚本后，都会缓存该脚本的Class对象，下次编译该脚本时，会优先从缓存中读取，这样节省掉编译的时间。这个缓存的Map由GroovyClassLoader持有，key是脚本的类名，而脚本的类名在不同的编译场景下（从文件读取脚本/从流读取脚本/从字符串读取脚本）其命名规则不同，当传入text时，class对象的命名规则为：

"script" + System.currentTimeMillis() + Math.abs(text.hashCode()) + ".groovy"

因此，每次编译的对象名都不同，都会在缓存中添加一个class对象，导致class对象不可释放，随着次数的增加，编译的class对象将PERM区撑满。

为了进一步证明是Groovy的脚本加载导致的，在本地进行模拟，分别测试不停加载groovy脚本和不停加载普通对象时，内存和GC的状态：

加载Groovy脚本的代码：

public void testMemory() throws Throwable {
        while (true) {
            for (int i = 0; i < 10000; i++) {
                testExecuteExpr();
            }
            Thread.sleep(1000);
            System.gc();
        }
    }

加载普通对象的代码：

public void testCommonMemory() throws InterruptedException {
    while (true) {
        for (int i = 0; i < 10000; i++) {
            com.alipay.baoxian.trade.util.groovy.test.Test test = new com.alipay.baoxian.trade.util.groovy.test.Test() {

                public void test() {
                }
            };
            test.test();
        }
        Thread.sleep(1000);
    }
}

运行一段时间以后，加载groovy脚本的JAVA进程由于OOM被crash掉了，而加载普通对象的JAVA进程可以一直运行。

加上JVM参数，把类加载卸载的信息以及GC的信息打出来： 
-XX:+TraceClassLoading 
-XX:+TraceClassUnloading 
-XX:+CMSClassUnloadingEnabled 
-Xloggc:*/gc.log 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps

观察GC的log，发现groovy运行时fullGC是几乎无法回收PERM区，而另一个可以正常回收。

groovy的gc日志：

[Full GC 2015-03-11T20:48:23.090+0800: 50.168: [CMS: 44997K->44997K(458752K), 0.2805613 secs] 44997K->44997K(517760K), [CMS Perm : 83966K->83966K(83968K)], 0.2806654 secs] [Times: user=0.28 sys=0.00, real=0.28 secs]

修改代码，在每次执行脚本前清空缓存：

shell.getClassLoader().clearCache();

GroovyClassLoader有提供清空缓存的方法，直接调用就可以了，再次执行，这次FullGC可以正常的回收内存了：

[Full GC 2015-03-11T19:42:22.908+0800: 143.055: [CMS: 218134K->33551K(458752K), 0.4226301 secs] 218134K->33551K(517760K), [CMS Perm : 83967K->25740K(83968K)], 0.4227156 secs] [Times: user=0.42 sys=0.00, real=0.43 secs]

解决该问题的方法：

之前对groovy做过简单的性能测试，解释执行时Groovy的耗时是编译执行耗时的三倍。大多数的情况下，Groovy都是编译后执行的，实际在本次的应用场景中，虽然是脚本是以参数传入，但其实大多数脚本的内容是相同的，所以我觉得应该修改Groovy对脚本类进行命名的方式，保证相同的脚本每次得到的命名都是相同的，这样在Groovy中就不会出现每次都新增一个class对象的方式，然后定时进行缓存清理，去掉长期不再执行的脚本，在脚本总数在一定数量限制的前提下，应该可以解决掉Groovy的PERM被占满的问题。

参考链接 
JAVA安全模型 
实例示范 
groovy的classloader加载原理 
深入探讨JAVA类加载器 
JAVA类加载原理浅析 
JAVA类加载器浅析 
ClassLoader原理浅析