Groovy加载类导致OOM分析

java

现象

项目中需要使用动态规则引擎，因此对热门的Groovy进行了调研。但早先就对Groovy会有OOM的问题有所耳闻，因此调研的时候特地关注了高频率使用Groovy加载类的场景，结果果然与预期一直稳定复现OOM故障。

分析

复现场景

1
2
3
4
5
6
7
8
9
10
11
12
13
GroovyClassLoader loader = new GroovyClassLoader();
for (int i = 0; ; i++) {
    String source = "" +
            "public class CustomApplication {\n" +
            "    public void print() {\n" +
            "        System.out.println(\"" + i + "\");\n" +
            "    }\n" +
            "}";
    Class<?> clazz = loader.parseClass(source);
    Object target = clazz.newInstance();
    Method method = clazz.getMethod("print");
    method.invoke(target);
}

执行以上代码，并通过JVM自带的jconsole工具监控类加载数量和元数据区的内存，如下图所示。监控显示，JVM的类数量从三千一路飙升到一万三，元数据内存使用也是一路飙涨，直到OOM后应用报错。

image

image

分析OOM

通过以上两张图，显而易见，应用OOM的原因是Groovy加载的类即使只使用一次，但却并没有被释放，最终导致元数据内存空间不足而OOM。因此接下来的思路是需要分析类如何才能被回收释放，以及如何才能让Groovy加载的类回收释放掉。

首先分析一个类的回收的前置条件，一个类如果需要被垃圾回收，则需要同时满足下面3个条件：

  1. 该类所有的实例都已经被回收
  2. 加载该类的ClassLoader已经被回收
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

对照复现场景中的测试代码，显然条件1和条件3是满足的，所有的类对象和类实例都没有被外部持有。至于条件2则需要了解Groovy的类加载机制才能解答。

Groovy类加载机制

Groovy加载类的核心逻辑在groovy.lang.GroovyClassLoader#doParseClass，其实现细节是通过GroovyClassLoader对象执行parseClass方法尝试加载类时，实际是每次类加载都会新建一个新的GroovyClassLoader.InnerLoader类加载器来真正执行类加载，加载完成后则不再引用该GroovyClassLoader.InnerLoader类加载器对象。

1
2
3
4
5
6
7
// 创建GroovyClassLoader.InnerLoader类加载器
ClassCollector collector = createCollector(unit, su);
unit.setClassgenCallback(collector);
int goalPhase = Phases.CLASS_GENERATION;
if (config != null && config.getTargetDirectory() != null) goalPhase = Phases.OUTPUT;
// 最终调用groovy.lang.GroovyClassLoader.ClassCollector#createClass方法
unit.compile(goalPhase);
1
2
3
4
5
6
7
8
protected ClassCollector createCollector(CompilationUnit unit, SourceUnit su) {
    InnerLoader loader = AccessController.doPrivileged(new PrivilegedAction<InnerLoader>() {
        public InnerLoader run() {
            return new InnerLoader(GroovyClassLoader.this);
        }
    });
    return new ClassCollector(loader, unit, su);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public static class ClassCollector extends CompilationUnit.ClassgenCallback {
    private Class generatedClass;
    private final GroovyClassLoader cl;
    private final SourceUnit su;
    private final CompilationUnit unit;
    private final Collection<Class> loadedClasses;

    protected ClassCollector(InnerLoader cl, CompilationUnit unit, SourceUnit su) {
        this.cl = cl;
        this.unit = unit;
        this.loadedClasses = new ArrayList<Class>();
        this.su = su;
    }

    public GroovyClassLoader getDefiningClassLoader() {
        return cl;
    }

    protected Class createClass(byte[] code, ClassNode classNode) {
        BytecodeProcessor bytecodePostprocessor = unit.getConfiguration().getBytecodePostprocessor();
        byte[] fcode = code;
        if (bytecodePostprocessor!=null) {
            fcode = bytecodePostprocessor.processBytecode(classNode.getName(), fcode);
        }
        // 实际使用的是GroovyClassLoader.InnerLoader类加载器
        GroovyClassLoader cl = getDefiningClassLoader();
        Class theClass = cl.defineClass(classNode.getName(), fcode, 0, fcode.length, unit.getAST().getCodeSource());
        this.loadedClasses.add(theClass);

        if (generatedClass == null) {
            ModuleNode mn = classNode.getModule();
            SourceUnit msu = null;
            if (mn != null) msu = mn.getContext();
            ClassNode main = null;
            if (mn != null) main = (ClassNode) mn.getClasses().get(0);
            if (msu == su && main == classNode) generatedClass = theClass;
        }

        return theClass;
    }

    ...
}

通过arthas工具监控类加载器如下图，通过GroovyClassLoader对象加载类时，实际上是使用的GroovyClassLoader.InnerLoader对象加载目标类，且每个GroovyClassLoader.InnerLoader类加载器对象只加载一个类。

image

漏网之鱼

我们再回忆一下一个类的回收的3个前置条件：

  1. 该类所有的实例都已经被回收
  2. 加载该类的ClassLoader已经被回收
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

测试代码中条件1和条件3满足，根据Groovy的类加载机制，明显类加载器加载完成目标类后就不再引用，因此条件2也满足，但实际上类并没有按预期被垃圾回收。显然在测试代码之外，有代码引用到了类对象或者类实例亦或者类加载器，导致最终类木有被垃圾回收。

这里就需要借助其他工具来分析对象引用，为了方便分析，使用OOM的内存快照，来分析导致内存溢出的对象，可直接定位到被偷偷引用的漏网之鱼。

image

image

如上图，最终定位出java.beans.ThreadGroupContext下引用了类对象，因此上述的类回收的3个条件未满足而导致类不会被垃圾回收。

那么问题来了，类对象为什么会被java.beans.ThreadGroupContext引用？经过层层debug后发现，当对Groovy加载的类执行反射时，会将该类的结构缓存到java.beans.ThreadGroupContext中，且不会主动清除缓存。核心代码如下：

groovy.lang.MetaClassImpl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// 对Groovy加载的类执行反射时,会执行该方法
private void addProperties() {
    BeanInfo info;
    final Class stopClass;
    //     introspect
    try {
        if (isBeanDerivative(theClass)) {
            info = (BeanInfo) AccessController.doPrivileged(new PrivilegedExceptionAction() {
                public Object run() throws IntrospectionException {
                    // 创建类结构缓存
                    return Introspector.getBeanInfo(theClass, Introspector.IGNORE_ALL_BEANINFO);
                }
            });
        } else {
            info = (BeanInfo) AccessController.doPrivileged(new PrivilegedExceptionAction() {
                public Object run() throws IntrospectionException {
                    // 创建类结构缓存
                    return Introspector.getBeanInfo(theClass);
                }
            });
        }
    } catch (PrivilegedActionException pae) {
        throw new GroovyRuntimeException("exception during bean introspection", pae.getException());
    }
    ...
}

java.beans.Introspector

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static BeanInfo getBeanInfo(Class<?> beanClass)
    throws IntrospectionException
{
    if (!ReflectUtil.isPackageAccessible(beanClass)) {
        return (new Introspector(beanClass, null, USE_ALL_BEANINFO)).getBeanInfo();
    }
    // 注意:ThreadGroupContext和线程group绑定
    ThreadGroupContext context = ThreadGroupContext.getContext();
    BeanInfo beanInfo;
    synchronized (declaredMethodCache) {
        beanInfo = context.getBeanInfo(beanClass);
    }
    if (beanInfo == null) {
        beanInfo = new Introspector(beanClass, null, USE_ALL_BEANINFO).getBeanInfo();
        synchronized (declaredMethodCache) {
            context.putBeanInfo(beanClass, beanInfo);
        }
    }
    return beanInfo;
}

解决

综上，虽然Groovy通过GroovyClassLoader.InnerLoader来加载类，实现类加载器在类加载完成后就会被垃圾回收，但由于Groovy加载的类在反射时会被java.beans.ThreadGroupContext缓存，且该缓存不会被主动清除，因此最终类没有按预期被垃圾回收。

所以只要定期清除java.beans.ThreadGroupContext中的缓存，就能释放所有类引用，让Groovy加载的类被垃圾回收。测试代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
GroovyClassLoader loader = new GroovyClassLoader();
for (int i = 0; ; i++) {
    String source = "" +
            "public class CustomApplication {\n" +
            "    public void print() {\n" +
            "        System.out.println(\"" + i + "\");\n" +
            "    }\n" +
            "}";
    Class<?> clazz = loader.parseClass(source);
    Object target = clazz.newInstance();
    Method method = clazz.getMethod("print");
    method.invoke(target);
    // 模拟定期清除ThreadGroupContext中的缓存
    if (i % 100 == 0) {
        // 需要与反射线程同ThreadGroup
        Introspector.flushCaches();
    }
}

如下图，图1为类加载数量图，其中红线为累计加载类数量，蓝色为当前加载类数量，而图二为元数据内存使用情况。可见在定期清除ThreadGroupContext中的缓存后，实现了对Groovy加载类的垃圾回收，不再出现OOM的问题。

image

image

>