Java 静态块中的初始化最终和非最终静态字段

我发现以下代码显示了MethodHandles和Reflection在性能上的差异：

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class MHOpto {

    private int value = 42;

    private static final Field static_reflective;
    private static final MethodHandle static_unreflect;
    private static final MethodHandle static_mh;

    private static Field reflective;
    private static MethodHandle unreflect;
    private static MethodHandle mh;

    // We would normally use @Setup, but we need to initialize "static final" fields here...
    static {
        try {
            reflective = MHOpto.class.getDeclaredField("value");
            unreflect = MethodHandles.lookup().unreflectGetter(reflective);
            mh = MethodHandles.lookup().findGetter(MHOpto.class, "value", int.class);
            static_reflective = reflective;
            static_unreflect = unreflect; //LINE X!!!
            static_mh = mh;
        } catch (IllegalAccessException | NoSuchFieldException e) {
            throw new IllegalStateException(e);
        }
    }

    @Benchmark
    public int plain() {
        return value;
    }

    @Benchmark
    public int dynamic_reflect() throws InvocationTargetException, IllegalAccessException {
        return (int) reflective.get(this);
    }

    @Benchmark
    public int dynamic_unreflect_invoke() throws Throwable {
        return (int) unreflect.invoke(this);
    }

    @Benchmark
    public int dynamic_unreflect_invokeExact() throws Throwable {
        return (int) unreflect.invokeExact(this);
    }

    @Benchmark
    public int dynamic_mh_invoke() throws Throwable {
        return (int) mh.invoke(this);
    }

    @Benchmark
    public int dynamic_mh_invokeExact() throws Throwable {
        return (int) mh.invokeExact(this);
    }

    @Benchmark
    public int static_reflect() throws InvocationTargetException, IllegalAccessException {
        return (int) static_reflective.get(this);
    }

    @Benchmark
    public int static_unreflect_invoke() throws Throwable {
        return (int) static_unreflect.invoke(this);
    }

    @Benchmark
    public int static_unreflect_invokeExact() throws Throwable {
        return (int) static_unreflect.invokeExact(this);
    }

    @Benchmark
    public int static_mh_invoke() throws Throwable {
        return (int) static_mh.invoke(this);
    }

    @Benchmark
    public int static_mh_invokeExact() throws Throwable {
        return (int) static_mh.invokeExact(this);
    }

}

结果如下：

Benchmark                             Mode  Cnt  Score   Error  Units
MHOpto.dynamic_mh_invoke              avgt   25  4.393 ± 0.003  ns/op
MHOpto.dynamic_mh_invokeExact         avgt   25  4.394 ± 0.007  ns/op
MHOpto.dynamic_reflect                avgt   25  5.230 ± 0.020  ns/op
MHOpto.dynamic_unreflect_invoke       avgt   25  4.404 ± 0.023  ns/op
MHOpto.dynamic_unreflect_invokeExact  avgt   25  4.397 ± 0.014  ns/op
MHOpto.plain                          avgt   25  1.858 ± 0.002  ns/op
MHOpto.static_mh_invoke               avgt   25  1.862 ± 0.015  ns/op
MHOpto.static_mh_invokeExact          avgt   25  1.859 ± 0.002  ns/op
MHOpto.static_reflect                 avgt   25  4.274 ± 0.011  ns/op
MHOpto.static_unreflect_invoke        avgt   25  1.859 ± 0.002  ns/op
MHOpto.static_unreflect_invokeExact   avgt   25  1.858 ± 0.002  ns/op

我不明白的是这行代码：

static_unreflect = unreflect;

---

static\u unreflect

（final）是否不等于

unreflect

（not final）？那么为什么它们在性能上表现出不同的结果呢？有人能解释一下吗？

只有方法句柄的

静态最终变量被JIT视为常量，例如：

并且只有通过MethodHandles进行的常量调用才是内联的，请参见它在何处进行了几次检查，以查看接收方是否为常量，如：

Node* receiver = kit.argument(0);
if (receiver->Opcode() == Op_ConP) {
  ...
} else {
  print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),
                         "receiver not constant");
}

这种差异使得对
静态final
方法句柄的调用可以内联，因此与普通情况下的调用速度大致相同

如果您打印出内联信息，您也可以看到这一点。e、 g.您可以添加如下内容：

@Fork(jvmArgsAppend="-Xlog:inlining*=trace:inlining-%p-static_mh_invokeExact.txt")

以基准方法为基础

在静态情况下，您将看到调用被内联：

 @ 17   org.sample.MyBenchmark::static_mh_invokeExact (8 bytes)   force inline by CompileCommand
   @ 4   java.lang.invoke.LambdaForm$MH/0x00000008000f0040::invokeExact_MT (23 bytes)   force inline by annotation
     @ 10   java.lang.invoke.Invokers::checkExactType (17 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandle::type (5 bytes)
     @ 14   java.lang.invoke.Invokers::checkCustomized (23 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandleImpl::isCompileConstant (2 bytes)
     @ 19   java.lang.invoke.LambdaForm$MH/0x00000008000f0440::getInt (34 bytes)   force inline by annotation
       @ 7   java.lang.invoke.DirectMethodHandle::fieldOffset (9 bytes)   force inline by annotation
       @ 12   java.lang.invoke.DirectMethodHandle::checkBase (5 bytes)   force inline by annotation
         @ 1   java.util.Objects::requireNonNull (14 bytes)
           @ 8   java.lang.NullPointerException::<init> (5 bytes)   don't inline Throwable constructors
       @ 30   jdk.internal.misc.Unsafe::getInt (0 bytes)   intrinsic

也就是说，在这种情况下，仍然有一个通过的间接调用，因为“接收方不是常数”。
实际上，
无反射
和
静态_无反射
：后者被定义为
最终
@Turing85谢谢。我明白了。但这两个变量只设置一次——当第一次加载类并执行静态块时。为什么重要？在这种情况下，
最终的
可能很重要。因为参考永远不会改变，所以可以对其进行优化。我不确定hotspot编译器是否能够推断
unreflect
引用实际上是最终引用。如果不能，这可能有助于提高性能测量结果已经回答了…@Holger Shipilev有一段关于这一点的精彩视频（不过是俄语）。在演讲中，他多次提到，当
MethodHandle
s为常量时，常量折叠效果最好，所以这是MethodHandles的特例。当使用例如接口时，JIT还可以进行类型分析（即检查我们实际看到的具体类型）并基于此进行推测性内联，但MethodHandles没有等效的（至少还没有）。@Eugene可以做的一个技巧是为每个MethodHandle生成一个类（例如使用ASM）其中MethodHandle卡在常量池或
静态final
字段中，并且类具有MethodHandle的getter。基本上是调用
o.get（）.invokeExact（…）
时，JIT会对类进行分析，对getter进行推测性内联，此时MethodHandle又是一个常量，并且可以内联。@这是否意味着在MethodHandle的情况下，Java语言不能按照规范工作？我的意思是，
static\u unreflect
（final）必须给出与
unreflect
（非final）相同的结果，但它不是。根据规范，
final
显示变量是常量-我们不能在初始化后在代码中更改它，也不能影响性能。@Pavel_K“也不能影响性能。”你有链接到它吗？MethodHandle调用的结果是
42
，而不管它的计算速度有多快，因此结果仍然是一样的。
 @ 17   org.sample.MyBenchmark::static_mh_invokeExact (8 bytes)   force inline by CompileCommand
   @ 4   java.lang.invoke.LambdaForm$MH/0x00000008000f0040::invokeExact_MT (23 bytes)   force inline by annotation
     @ 10   java.lang.invoke.Invokers::checkExactType (17 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandle::type (5 bytes)
     @ 14   java.lang.invoke.Invokers::checkCustomized (23 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandleImpl::isCompileConstant (2 bytes)
     @ 19   java.lang.invoke.LambdaForm$MH/0x00000008000f0440::getInt (34 bytes)   force inline by annotation
       @ 7   java.lang.invoke.DirectMethodHandle::fieldOffset (9 bytes)   force inline by annotation
       @ 12   java.lang.invoke.DirectMethodHandle::checkBase (5 bytes)   force inline by annotation
         @ 1   java.util.Objects::requireNonNull (14 bytes)
           @ 8   java.lang.NullPointerException::<init> (5 bytes)   don't inline Throwable constructors
       @ 30   jdk.internal.misc.Unsafe::getInt (0 bytes)   intrinsic

 @ 17   org.sample.MyBenchmark::dynamic_mh_invokeExact (8 bytes)   force inline by CompileCommand
   @ 4   java.lang.invoke.LambdaForm$MH/0x00000008000f0040::invokeExact_MT (23 bytes)   force inline by annotation
     @ 10   java.lang.invoke.Invokers::checkExactType (17 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandle::type (5 bytes)
       @ 12   java.lang.invoke.Invokers::newWrongMethodTypeException (36 bytes)   callee is too large
     @ 14   java.lang.invoke.Invokers::checkCustomized (23 bytes)   force inline by annotation
       @ 1   java.lang.invoke.MethodHandleImpl::isCompileConstant (2 bytes)
       @ 19   java.lang.invoke.Invokers::maybeCustomize (28 bytes)   don't inline by annotation
     @ 19   java.lang.invoke.MethodHandle::invokeBasic(L)I (0 bytes)   receiver not constant