众所周知，反射是一种灵活但缓慢的方法，用于在运行时维护和修改代码的行为。

但是如果我们必须使用这样的功能，Java 中是否有比反射 API 更快的编程技术来进行动态修改？这些替代反射的优缺点是什么？

最佳答案

Reflection 的一种替代方法是动态生成类文件。这个生成的类应该执行所需的操作，例如调用在运行时发现的方法，并实现在编译时已知的 interface，以便可以使用该接口(interface)以非反射方式调用生成的方法。有一个问题:如果适用，Reflection 在内部会做同样的事情。这在特殊情况下不起作用，例如调用 private 方法时，您无法生成调用它的合法类文件。因此，在反射实现中有不同类型的调用处理程序，使用生成的代码或 native 代码。你无法击败它。

但更重要的是，Reflection 会对每次调用进行安全检查。因此，您生成的类将仅在加载和实例化时进行检查，这可能是一个巨大的胜利。或者，您可以在 Method 实例上调用 setAccessible(true) 以关闭安全检查。然后只剩下自动装箱和可变参数数组创建的轻微性能损失。

由于 Java 7 有一个替代方案，即 MethodHandle。最大的优势是，与其他两个不同，它甚至可以在安全受限的环境中工作。 MethodHandle 的访问检查在获取它时执行，但在调用它时不执行。它具有所谓的“多态签名”，这意味着您可以使用任意参数类型调用它，而无需自动装箱或创建数组。当然，错误的参数类型会产生一个合适的RuntimeException。

(更新) 借助 Java 8，可以选择在运行时使用 lambda 表达式的后端和方法引用语言功能。这个后端完全按照开头描述的那样做，动态生成一个类，该类实现一个 interface 你的代码可以在编译时直接调用它。确切的机制是特定于实现的，因此未定义，但您可以假设实现将尽力使调用尽可能快。 Oracle 的 JRE 的当前实现完美地做到了这一点。这不仅使您免于生成此类访问器类的负担，而且还能够完成您永远无法做到的事情——甚至通过生成的代码调用 private 方法。我已更新示例以包含此解决方案。这个例子使用了一个标准的interface，它已经存在并且恰好有想要的方法签名。如果不存在这样的匹配 interface，您必须使用具有正确签名的方法创建自己的访问器功能接口(interface)。但是，当然，现在示例代码需要 Java 8 才能运行。

这是一个简单的基准测试示例:

import java.lang.invoke.LambdaMetafactory;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.reflect.Method;
import java.util.function.IntBinaryOperator;

public class TestMethodPerf
{
  private static final int ITERATIONS = 50_000_000;
  private static final int WARM_UP = 10;

  public static void main(String... args) throws Throwable
  {
 // hold result to prevent too much optimizations
    final int[] dummy=new int[4];

    Method reflected=TestMethodPerf.class
      .getDeclaredMethod("myMethod", int.class, int.class);
    final MethodHandles.Lookup lookup = MethodHandles.lookup();
    MethodHandle mh=lookup.unreflect(reflected);
    IntBinaryOperator lambda=(IntBinaryOperator)LambdaMetafactory.metafactory(
      lookup, "applyAsInt", MethodType.methodType(IntBinaryOperator.class),
      mh.type(), mh, mh.type()).getTarget().invokeExact();

    for(int i=0; i<WARM_UP; i++)
    {
      dummy[0]+=testDirect(dummy[0]);
      dummy[1]+=testLambda(dummy[1], lambda);
      dummy[2]+=testMH(dummy[1], mh);
      dummy[3]+=testReflection(dummy[2], reflected);
    }
    long t0=System.nanoTime();
    dummy[0]+=testDirect(dummy[0]);
    long t1=System.nanoTime();
    dummy[1]+=testLambda(dummy[1], lambda);
    long t2=System.nanoTime();
    dummy[2]+=testMH(dummy[1], mh);
    long t3=System.nanoTime();
    dummy[3]+=testReflection(dummy[2], reflected);
    long t4=System.nanoTime();
    System.out.printf("direct: %.2fs, lambda: %.2fs, mh: %.2fs, reflection: %.2fs%n",
      (t1-t0)*1e-9, (t2-t1)*1e-9, (t3-t2)*1e-9, (t4-t3)*1e-9);

    // do something with the results
    if(dummy[0]!=dummy[1] || dummy[0]!=dummy[2] || dummy[0]!=dummy[3])
      throw new AssertionError();
  }

  private static int testMH(int v, MethodHandle mh) throws Throwable
  {
    for(int i=0; i<ITERATIONS; i++)
      v+=(int)mh.invokeExact(1000, v);
    return v;
  }

  private static int testReflection(int v, Method mh) throws Throwable
  {
    for(int i=0; i<ITERATIONS; i++)
      v+=(int)mh.invoke(null, 1000, v);
    return v;
  }

  private static int testDirect(int v)
  {
    for(int i=0; i<ITERATIONS; i++)
      v+=myMethod(1000, v);
    return v;
  }

  private static int testLambda(int v, IntBinaryOperator accessor)
  {
    for(int i=0; i<ITERATIONS; i++)
      v+=accessor.applyAsInt(1000, v);
    return v;
  }

  private static int myMethod(int a, int b)
  {
    return a<b? a: b;
  }
}

在我的 Java 7 设置中打印的旧程序:direct: 0,03s, mh: 0,32s, reflection: 1,05s 这表明 MethodHandle 是不错的选择。现在，在同一台机器上运行在 Java 8 下的更新程序打印出 direct: 0,02s, lambda: 0,02s, mh: 0,35s, reflection: 0,40s 这清楚地表明了反射性能已经改进到可能不需要处理 MethodHandle 的程度，除非您使用它来执行 lambda 技巧，这显然优于所有反射替代方案，这不足为奇，因为它只是一个直接的调用(嗯，几乎:一级间接)。请注意，我制作了目标方法 private 来演示有效调用 private 方法的能力。

与往常一样，我必须指出这个基准的简单性以及它的人工性。但我认为，趋势是清晰可见的，更重要的是，结果可以令人信服地解释。

关于java - Java 反射的更快替代方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19557829/