使用反射前先三思

介绍

有时，作为开发人员，您可能会遇到无法使用new运算符实例化对象的情况，因为其类名存储在配置XML中的某个位置，或者您需要调用一个名称指定为注释属性的方法。在这种情况下，您总会有一个答案：“使用反射！”。

在新版本的CUBA框架中，我们决定改进体系结构的许多方面，最重要的变化之一是在控制器UI中弃用了“经典”事件侦听器。在该框架的先前版本中，屏幕的init()方法中注册了许多样板代码的侦听器，使您的代码几乎不可读，因此新概念应该可以解决此问题。

您始终可以通过为带注释的方法存储java.lang.reflect.Method实例来实现方法侦听器，并像在许多框架中实现的那样调用它们，但是我们决定看看其他选项。反射调用需要付出一定的成本，如果您开发了生产级框架，则即使是很小的改进也可能在短时间内得到回报。

在本文中，我们将介绍反射API的用法和优缺点，并查看其他替代反射API调用的选项-AOT和代码生成以及LambdaMetafactory。

反射–良好的旧可靠API

根据维基百科，“反射是计算机程序在运行时检查，自省和修改其自身的结构和行为的能力”。

对于大多数Java开发人员而言，反射并不是新事物，它在许多情况下都被使用。我敢说Java在没有反思的情况下不会变成现在的样子。只需考虑批注处理，数据序列化，通过批注或配置文件进行方法绑定…对于最流行的IoC框架，反射API是基石，因为广泛使用了类代理，方法引用用法等。此外，您还可以添加面向方面的方法编程到此列表–一些AOP框架依靠反射来进行方法执行拦截。

反射有什么问题吗？我们可以考虑其中的三个：

速度 –反射呼叫比直接呼叫慢。我们可以看到每个JVM版本在反射API性能上都有很大的改进，JIT编译器的优化算法越来越好，但是反射方法调用的速度仍然比直接方法慢三倍。

类型安全性 –如果在代码中使用方法引用，则它只是方法引用。如果编写的代码通过其引用调用方法并传递错误的参数，则该调用将在运行时失败，而不是在编译时或加载时失败。

可追溯性 –如果一个反射方法调用失败，那么找到导致这一问题的代码行可能会很棘手，因为堆栈跟踪通常很庞大。您需要深入研究所有这些invoke()和proxy()调用。

但是，如果您研究Spring中的事件侦听器实现或Hibernate中的JPA回调，则会在其中看到熟悉的java.lang.reflect.Method引用。而且我怀疑它是否会在不久的将来更改–成熟的框架又大又复杂，已在许多关键任务系统中使用，因此开发人员应谨慎地进行重大更改。

让我们看看其他选项。

AOT编译和代码生成–使应用程序再次快速

反射替换的第一个候选人–代码生成。如今，我们可以看到诸如Micronaut和Quarkus之类的新框架的兴起，它们针对两个目标：快速启动时间和低内存占用。在微服务和无服务器应用程序时代，这两个指标至关重要。最近的框架正试图通过使用提前编译和代码生成来完全摆脱反思。通过使用注释处理，类型访问者和其他技术，他们将直接方法调用，对象实例化等添加到代码中，从而使应用程序更快。那些不会在启动期间使用Class.newInstance()创建和注入bean的Class.newInstance() ，不会在侦听器中使用反射方法的调用，等等。看起来很有希望，但是这里有什么取舍吗？答案是–是的。

第一个–您运行的代码不完全是您自己的。代码生成会更改原始代码，因此，如果出现问题，您将无法确定是您的错误还是代码处理算法中的故障。并且不要忘记，现在您应该调试生成的代码，而不是代码。

第二个权衡–您必须使用供应商提供的单独工具/插件才能使用该框架。您不能“只是”运行代码，而应以特殊方式对其进行预处理。并且，如果您在生产中使用框架，则应将供应商的错误修正应用于框架代码库和代码处理工具。

代码生成早已为人所知，但Micronaut或Quarkus尚未出现。例如，在CUBA中，我们在编译期间使用自定义的Grails插件和Javassist库使用类增强功能。我们添加了额外的代码来生成实体更新事件，并在类代码中将bean验证消息作为String字段包含在类代码中，以用于漂亮的UI表示。

但是为事件侦听器实现代码生成看起来有些极端，因为这将需要对内部体系结构进行彻底的更改。有反射这样的东西，但是更快吗？

LambdaMetafactory –更快的方法调用

在Java 7中，引入了新的JVM指令invokedynamic 。最初针对基于JVM的动态语言实现，它已成为API调用的良好替代。该API可以使我们在性能上优于传统反射。还有一些特殊的类可以在Java代码中构造invokedynamic调用：

MethodHandle –该类是Java 7中引入的，但它仍然不为人所知。
LambdaMetafactory –是Java 8中引入的。它是动态调用思想的进一步发展。该API基于MethodHandle。

方法句柄API可以很好地替代标准反射，因为JVM在MethodHandle创建期间仅执行一次所有预调用检查。长话短说–方法句柄是对基础方法，构造函数，字段或类似的低级操作的类型化，直接可执行的引用，具有参数或返回值的可选转换。

出乎意料的是，与按反射API相比，纯MethodHandle引用调用不会提供更好的性能，除非您按照本电子邮件列表中所述将MethodHandle引用设为静态。

但是LambdaMetafactory是另一个故事–它允许我们在运行时中生成功能接口的实例，该实例包含对由MethodHandle解析的方法的MethodHandle 。使用此lambda对象，我们可以直接调用引用的方法。这是一个例子：

 private BiConsumer createVoidHandlerLambda(Object bean, Method method) throws Throwable { MethodHandles.Lookup caller = MethodHandles.lookup(); CallSite site = LambdaMetafactory.metafactory(caller, "accept" , MethodType.methodType(BiConsumer. class ), MethodType.methodType( void . class , Object. class , Object. class ), caller.findVirtual(bean.getClass(), method.getName(), MethodType.methodType( void . class , method.getParameterTypes()[ 0 ])), MethodType.methodType( void . class , bean.getClass(), method.getParameterTypes()[ 0 ])); MethodHandle factory = site.getTarget(); BiConsumer listenerMethod = (BiConsumer) factory.invoke(); return listenerMethod; }

请注意，通过这种方法，我们可以只使用java.util.function.BiConsumer而不是java.lang.reflect.Method ，因此不需要太多的重构。让我们考虑一下事件侦听器处理程序代码–它是对Spring Framework的简化改编：

 public class ApplicationListenerMethodAdapter implements GenericApplicationListener { private final Method method; public void onApplicationEvent(ApplicationEvent event) { Object bean = getTargetBean(); Object result = this .method.invoke(bean, event); handleResult(result); }  }

这就是可以使用基于Lambda的方法参考进行更改的方式：

 public class ApplicationListenerLambdaAdapter extends ApplicationListenerMethodAdapter { private final BiFunction funHandler; public void onApplicationEvent(ApplicationEvent event) { Object bean = getTargetBean(); Object result = handler.apply(bean, event); handleResult(result); }  }

该代码具有细微的变化，并且功能相同。但是与传统反射相比，它具有一些优势：

类型安全性 –您在LambdaMetafactory.metafactory调用中指定方法签名，因此您将无法将“公正”方法绑定为事件侦听器。

可追溯性 – lambda包装器仅对方法调用堆栈跟踪添加了一个额外的调用。它使调试更加容易。

速度 –这是应该衡量的事情。

标杆管理

对于新版本的CUBA框架，我们创建了一个基于JMH的微基准，以比较“传统”反射方法调用（基于lambda）的执行时间和吞吐量，并添加了直接方法调用以进行比较。在测试执行之前，已创建并缓存了方法引用和lambda。

我们使用了以下基准测试参数：

 @BenchmarkMode ({Mode.Throughput, Mode.AverageTime})  @Warmup (iterations = 5 , time = 1000 , timeUnit = TimeUnit.MILLISECONDS)  @Measurement (iterations = 10 , time = 1000 , timeUnit = TimeUnit.MILLISECONDS)

您可以从GitHub下载基准测试，然后自己运行测试。

对于JVM 11.0.2和JMH 1.21，我们得到以下结果（运行次数可能略有不同）：

测试-获得价值	吞吐量（运营/我们）	执行时间（我们/运营）
LambdaGetTest	72	0.0118
ReflectionGetTest	65岁	0.0177
DirectMethodGetTest	260	0.0048

测试–设定值	吞吐量（运营/我们）	执行时间（我们/运营）
LambdaSetTest	96	0.0092
ReflectionSetTest	58	0.0173
DirectMethodSetTest	415	0.0031

如您所见，基于lambda的方法处理程序平均快30％。关于基于lambda的方法调用性能，这里有很好的讨论。结果-LambdaMetafactory生成的类可以被内联，从而获得一些性能改进。它比反射更快，因为反射调用必须在每次调用时通过安全检查。

该基准测试是很贫乏的，没有考虑类的层次结构，最终方法等，它只测量“公正”的方法调用，但这足以满足我们的目的。

实作

在CUBA中，您可以使用@Subscribe注释使方法“监听”各种特定于CUBA的应用程序事件。在内部，我们使用此新的基于MethodHandles / LambdaMetafactory的API来加快侦听器的调用。第一次调用后将缓存所有方法句柄。

新的体系结构使代码更简洁，更易于管理，尤其是在具有大量事件处理程序的复杂UI的情况下。看看简单的例子。假设您需要根据添加到此订单的产品重新计算订单金额。您有一个calculateAmount()方法，您需要在订单中的一组产品更改后立即调用它。这是UI控制器的旧版本：

LambdaGetTest

在新版本中的外观如下：

LambdaGetTest

代码更简洁，我们能够摆脱通常用事件处理程序创建语句填充的“魔术” init()方法。而且，我们甚至不需要将数据组件注入控制器中-框架将通过组件ID找到它。

结论

尽管最近引入了新一代框架（ Micronaut ， Quarkus ），它们比“传统”框架具有一些优势，但是由于Spring的支持，仍然存在大量基于反射的代码。我们将看到市场在不久的将来将如何变化，但是如今，Spring在Java应用程序框架中是显而易见的领导者，因此，我们将使用反射API已有相当长的时间。

而且，如果您考虑在代码中使用反射API，无论是实现自己的框架还是仅是应用程序，请考虑另外两个选项–代码生成，尤其是LambdaMetafactory。后者将提高代码执行速度，而与“传统”反射API相比，开发不会花费更多时间。