首页 > 其他 > 详细

groovy脚本导致的FullGC问题

时间:2015-03-12 14:35:37      阅读:10490      评论:0      收藏:0      [点我收藏+]

标签:des   class   代码   com   log   使用   java   http   文件   

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

背景: 
应用中内嵌了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的依赖路径:

[email protected]  
[email protected]  
[email protected]  
[email protected]  
[email protected]  

这里有个问题,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原理浅析

groovy脚本导致的FullGC问题

标签:des   class   代码   com   log   使用   java   http   文件   

原文:http://www.cnblogs.com/fourspirit/p/4332154.html

(0)
(0)
   
举报
评论 一句话评论(0
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号