为什么JavaCompiler在实例化Java类时速度较慢

Question

我使用JavaCompiler动态创建一个Java类，对其进行编译并加载到我的应用程序中。

我的问题如下：JavaCompiler的执行时间比实例化同一类的标准方法慢得多

这里有一个例子：

static void function() {
long startTime = System.currentTimeMillis();
String source = "package myPackage; import java.util.BitSet; public class MyClass{ static {";
while (!OWLMapping.axiomStack.isEmpty()) {
source += OWLMapping.axiomStack.pop() + ";";
}
source += "} }";
File root = new File("/java");
File sourceFile = new File(root, "myPackage/MyClass.java");
sourceFile.getParentFile().mkdirs();
Files.write(sourceFile.toPath(), source.getBytes(StandardCharsets.UTF_8));
// Compile source file.
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
compiler.run(null, null, null, sourceFile.getPath());
// Load and instantiate compiled class.
URLClassLoader classLoader = URLClassLoader.newInstance(new URL[] { root.toURI().toURL() });
Class<?> cls = Class.forName("myPackage.MyClass", true, classLoader);
long stopTime = System.currentTimeMillis();
long elapsedTime = stopTime - startTime;
System.out.println("EXECUTION TIME: " + elapsedTime);
}

在测量了这段代码之后，我创建了一个新的java类，该类与var源的内容相同，以测试性能：它比JavaCompiler的方式快得多。(我不能使用标准类，因为在我的应用程序中我需要动态地创建它)。那么，有可能提高这段代码的性能吗？或者这种低性能是正常的？

EDIT：我还测试了生成的代码是一个简单的OWLAPI公理序列：

package myPackage;
public class myClass{
static {
myPackage.OWLMapping.manager.addAxiom(myPackage.OWLMapping.ontology,   myPackage.OWLMapping.factory.getOWLSubClassOfAxiom(/*whatever*/);
myPackage.OWLMapping.manager.addAxiom(myPackage.OWLMapping.ontology,myPackage.OWLMapping.factory.getOWLSubClassOfAxiom(/*whatever*/);
myPackage.OWLMapping.manager.addAxiom(myPackage.OWLMapping.ontology,myPackage.OWLMapping.factory.getOWLSubClassOfAxiom(/*whatever*/);

}
}

这正是变量源所包含的内容。公理的数量取决于用户的输入。

Answer 1

您有两个领域可能会很慢(但您的基准测试将这两个领域结合在一起)。

第一个是构建包含源代码的JavaString。当在不同的语句中附加字符串时，JVM无法将它们优化为StringBuilders，这意味着它首先在附加的一侧创建字符串，然后在另一侧创建String，然后在附加的两个语句中创建第三个String。这给堆和垃圾收集带来了很大的压力，生成了大量几乎立即被垃圾收集的对象。

要解决第一个问题，请创建一个StringBuilder并将其称为.append(...)。

第二个问题是您正在实例化一个JavaCompiler。用于编译Java程序的编译器可能有一个类在顶级驱动它，但它会产生大量的支持类来填充它的私有字段和嵌入的include。最后，当运行它时，将创建更多的对象来保存代码、Lexer、Parser、CompilationUnit的AST，以及最终的字节码发射器。这意味着的一行代码

JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
compiler.run(null, null, null, sourceFile.getPath());

可能需要一些时间(同样，它们没有独立的基准)。

最后，类加载器行与类加载系统交互，并且可能不适合性能。虽然这是一个较小的机会，它是一个大的性能打击，我也会独立的基准线。