为什么调用 class.NewInstance() 时使用 InvokeVirtual 而不是 InvokeSpecial？

Question

我正在研究以下 java 程序的反汇编

public class ASMPlayground {
    private String bar;

    public String getBar(){
        return bar;
    }

    public void setBar(String bar) throws IllegalAccessException, InstantiationException {
        String name = String.class.newInstance();
        System.out.println(name);
    }

    public static void main(String[] args) {

    }
}

以下字节码 sn-p 引起了我的注意，似乎不是最佳的

LDC Ljava/lang/String;.class
INVOKEVIRTUAL java/lang/Class.newInstance ()Ljava/lang/Object;
CHECKCAST java/lang/String

问题：

当要执行的方法依赖于对象引用时，使用 InvokeVirtual。鉴于“类”是最终的并且 newInstance() 仅存在 在“类”中，为什么不使用 InvokeSpecial 而不是 InvokeVirtual ？不是更高效吗？

Answer 1

InvokeSpecial 用于指定调用是

超类、私有和实例初始化方法调用

规格：https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokespecial

Class.newInstance 既不是超类方法调用，也不是私有方法调用，也不是对初始化方法的调用。它也不是动态方法，InvokeDynamic 与此无关。这两个指令都不能在这里使用，因为它会遇到 jvms。在创建 jvm 时，可以允许用“性能更高”的指令代替一些指令，但正如我在 jvm 中看到的那样，它还没有完成。

性能不是更好吗？

JIT 足够聪明，可以理解在这种情况下不需要遍历虚拟方法表，因此它不应该减慢执行速度。实际性能应通过实际测试进行比较，但我认为没有理由预期会有显着差异。

Answer 2

目标方法或类是final这一事实永远不会改变使用其他类/调用方法的类的编译形式。

这是 JLS 第 13 章规定的。“二进制兼容性”，§13.4.17, final methods：

将声明为 final 的方法更改为不再声明为 final 不会破坏与预先存在的二进制文件的兼容性。

同样§13.4.2. final Classes

将声明为 final 的类更改为不再声明为 final 不会破坏与预先存在的二进制文件的兼容性。

显然，依赖于目标方法的final 性质的调用指令会违反此规范。

预计不会对性能产生相关影响。当符号引用必须解析为实际方法时（就 JVM 的运行时表示而言），总会有第一次开销。此时，如果有好处的话，JVM 也可以将这个方法或其声明类实际上是final 的事实记录到调用指令中。现代 JVM 走得更远，例如利用非final 方法实际上没有被覆盖以达到相同效果的事实，尽管如果子类被加载和实例化，则需要取消优化这些调用，该子类具有覆盖方法。所以唯一的区别是final 修饰符保证永远不需要这种去优化。