reflection - 在运行时使用 JDK 编译器时的内存泄漏

Question

我正在尝试向我的程序中添加一个 javaeditor 以在运行时扩展该程序。一切正常，除非广泛使用该程序(我模拟了 1000-10000 次编译器执行)。内存使用率越来越高，看起来有内存泄漏。

在我的程序中，类被加载，构造函数被执行，类被卸载(没有剩余的实例并且类加载器变得无效，因为我将指针设置为空)。我用 JConsole 分析了这个过程，当垃圾收集器被执行时，这些类被卸载了。

我做了一个 heapdum 在内存分析器中打开它，问题似乎在 java.net.FactoryURLClassLoader 内部(在 com.sun.tools.javac.util.List 对象中)。由于 (com.sun.tools.javac) 是 JDK 的一部分而不是 JRE 中的一部分，并且 SystemToolClassLoader 是一个 FactoryURLClassLoader 对象，因此我会在某处找到泄漏。当我第一次执行编译器时，SystemToolClassLoader 中加载的类数从 1 增加到 521，但之后保持不变。

所以我不知道泄漏在哪里，有没有办法重置 SystemToolClassLoader？我怎样才能更准确地定位泄漏点。

编辑:好的，我发现它也出现在一个非常非常简单的示例中。所以它似乎是编译的一部分，我不需要加载类或实例化它:

import java.io.File;
import java.io.IOException;
import java.util.Arrays;

import javax.tools.JavaCompiler;
import javax.tools.JavaFileObject;
import javax.tools.StandardJavaFileManager;
import javax.tools.ToolProvider;


public class Example {   

public static void main(String[] args)
{
    for (int i =0; i<10000;i++){
        try {
            System.out.println(i);
            compile();
        } catch (InstantiationException | IllegalAccessException
                | ClassNotFoundException | IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

}

public static void compile() throws IOException, InstantiationException, IllegalAccessException, ClassNotFoundException
{
    File source = new File( "src\\Example.java" ); // This File
    JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
    StandardJavaFileManager fileManager = compiler.getStandardFileManager( null, null, null );
    Iterable<? extends JavaFileObject> units;
    units = fileManager.getJavaFileObjectsFromFiles( Arrays.asList( source ) );
    compiler.getTask( null, fileManager, null, null, null, units ).call();
    fileManager.close();
}

}

Answer 1

起初，我认为这肯定是内存泄漏；然而，它与 SoftReference 的工作方式直接相关。

Oracle 的 JVM 仅在堆完全用完时才尝试收集软引用。似乎无法以编程方式强制收集软引用。

为了找出问题所在，我在“无限”堆上使用了三个转储:

1. 启动应用程序并获取编译器和 ScriptFileManager，然后执行 GC-finalize-GC。做一个垃圾场。
2. 加载 500 个“脚本”。
3. 执行 GC-finalize-GC。写统计数据。做一个垃圾场。
4. 加载 500 个“脚本”。
5. 执行 GC-finalize-GC。写统计数据。做一个垃圾场。

明显的(双倍)实例数量增加:Names (500 -> 1k), SharedNameTable (500->1k), SharedNameTable$NameImpl(数十万)和 [LSharedNameTable$NameImpl (500->1k)。

在使用 EMA 分析后，很明显 SharedNameTable 有一个对 com.sun.tools.javac.util.List 的静态引用，这显然是 SoftReference s 曾经创建的每一个 SharedNameTable(所以一个对应于您在运行时编译的每个源文件)。所有 $NameImpl 都是您的源文件被分割成的标记。显然，所有 token 都从未从堆中释放并无休止地累积……或者确实如此？

我决定测试一下是否真的如此。了解软引用与弱引用的区别后，我决定使用小堆 (-Xms32m -Xmx32m)。通过这种方式，JVM 将被迫释放 SharedNameTable 或因 OutOfMemoryError 而失败。结果不言自明:

-Xmx512m -Xms512m

Total memory: 477233152
Free memory: 331507232
Used memory: 138.97506713867188 MB
Loaded scripts: 500

Total memory: 489816064
Free memory: 203307408
Used memory: 273.23594665527344 MB
Loaded scripts: 1000

The classloader/component "java.net.FactoryURLClassLoader @ 0x8a8a748" occupies 279.709.192 (98,37%) bytes.

-Xmx32m -Xms32m

Total memory: 29687808
Free memory: 25017112
Used memory: 4.454322814941406 MB
Loaded scripts: 500

Total memory: 29884416
Free memory: 24702728
Used memory: 4.941642761230469 MB
Loaded scripts: 1000

One instance of "com.sun.tools.javac.file.ZipFileIndex" loaded by "java.net.FactoryURLClassLoader @ 0x8aa4cc8" occupies 2.230.736 (47,16%) bytes. The instance is referenced by *.*.script.ScriptFileManager @ 0x8ac8230.

(这只是一个指向 JDK 库的链接。)

脚本:

public class Avenger
{
    public Avenger()
    {
        JavaClassScriptCache.doNotCollect(this);
    }

    public static void main(String[] args)
    {
        // this method is called after compiling
        new Avenger();
    }
}

不收集:

private static final int TO_LOAD = 1000;
private static final List<Object> _active = new ArrayList<Object>(TO_LOAD);

public static void doNotCollect(Object o)
{
    _active.add(o);
}

System.out.println("Loaded scripts: " + _active.size());