zoukankan      html  css  js  c++  java
  • 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原理浅析

  • 相关阅读:
    LeetCode题解(2)-- Add Two Numbers
    LeetCode题解(1)--Two Sum
    STL review:vector & string & map & struct
    机器学习导论(一) 基本概念
    Single Number
    Single Number II
    Copy List with Random Pointer
    Word Break
    Populating Next Right Pointers in Each Node II
    Binary Tree Inorder Traversal
  • 原文地址:https://www.cnblogs.com/fourspirit/p/4332154.html
Copyright © 2011-2022 走看看