在 java-8
源代码中,我们可以在 Class
类中找到非常棘手的 JIT 优化方法:
/*
* Private constructor. Only the Java Virtual Machine creates Class objects.
* This constructor is not used and prevents the default constructor being
* generated.
*/
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization value of non-null
// prevents future JIT optimizations from assuming this final field is null.
classLoader = loader;
}
因此,此构造函数永远不会被调用,但 JIT 将被此技巧“欺骗”。
我的问题是:是否可以以稍微不同的方式实现,比方说
private Class() {
classLoader = (ClassLoader)(new Object());
}
这绝对是毫无意义的逻辑,但是如果永远不会调用构造函数又有什么关系呢?
这种技巧是否也会阻止 JIT 进行这种优化?
最佳答案
在 Java 6 和 Java 7(以及更新 40 之前的 Java 8)中,构造函数与 private Class() {}
一样简单,但在这些版本中,没有 classLoader
字段。
这意味着 Class
和 ClassLoader
之间的关联必须以特殊的 JVM 特定方式维护,因此,getClassLoader()
具有调用 native
方法,不一定涉及 JNI,而是作为 JVM 内部操作处理,但在 JVM 的 native 代码内部仍需要特别注意。此外,垃圾收集器必须知道这种特殊关系。
相比之下,在反射中隐藏一个字段并不那么复杂,而现在拥有一个普通字段简化了 JVM 的 native 代码,最显着的是 getClassLoader()
操作和垃圾收集器实现.如果是普通字段,优化器内联字段访问也可能更简单。
现在,当 Class
对象是通过特殊的 JVM 代码创建的,而不是使用声明的构造函数时,它可能与优化 JIT 的假设相矛盾,该假设通过分析构造函数的实际代码来预测可能的值final
字段。
请注意,没有人说当前的 JIT 如此智能。该评论谈到了假设的“ future 的 JIT 优化”。让构造函数使用参数值初始化字段符合 JVM 的实际操作。
相比之下,像您建议的 classLoader = (ClassLoader)(new Object());
这样的构造函数可能会导致假设的优化器得出结论,该字段不能用实际的 ClassLoader
实例,因为该代码永远无法正常完成。
关于java - JIT优化预防技术,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42097460/