网站建设分前端和后台吗,wordpress 回复提醒,移动排名提升软件,禅城容桂网站制作三思笔记介绍 有时#xff0c;作为开发人员#xff0c;您可能会遇到无法使用new运算符实例化对象的情况#xff0c;因为其类名称存储在配置XML中的某个位置#xff0c;或者您需要调用一个名称指定为注释属性的方法。 在这种情况下#xff0c;您总会有一个答案#xff1a;… 三思笔记 介绍 有时作为开发人员您可能会遇到无法使用new运算符实例化对象的情况因为其类名称存储在配置XML中的某个位置或者您需要调用一个名称指定为注释属性的方法。 在这种情况下您总会有一个答案“使用反射”。 在新版本的CUBA框架中 我们决定改进体系结构的许多方面最重要的变化之一是在控制器UI中弃用了“经典”事件侦听器。 在该框架的先前版本中屏幕的init()方法中注册了许多样板代码的侦听器使您的代码几乎不可读因此新概念应该可以解决此问题。 您始终可以通过为带注释的方法存储java.lang.reflect.Method实例来实现方法侦听器并像在许多框架中实现的那样调用它们但是我们决定看看其他选项。 反射调用需要付出一定的成本如果您开发了生产级框架则即使是很小的改进也可能在短时间内得到回报。 在本文中我们将介绍反射API的用法优缺点并查看其他替代反射API调用的选项-AOT和代码生成以及LambdaMetafactory。 反射–良好的旧可靠API 根据维基百科“反射是计算机程序在运行时检查自省和修改其自身的结构和行为的能力”。 对于大多数Java开发人员而言反射并不是新事物它在许多情况下都被使用。 我敢说Java在没有反思的情况下不会变成现在的样子。 只需考虑批注处理数据序列化通过批注或配置文件进行方法绑定…对于最流行的IoC框架由于广泛使用类代理方法引用等反射API是基石。此外您还可以添加面向方面的编程到此列表–一些AOP框架依靠反射来进行方法执行拦截。 反射有什么问题吗 我们可以考虑其中的三个 速度 –反射呼叫比直接呼叫慢。 我们可以看到随着每个JVM版本的发布反射API的性能都有了很大的提高JIT编译器的优化算法越来越好但是反射方法的调用速度仍然比直接调用慢3倍。 类型安全性 –如果您在代码中使用方法引用则它只是方法引用。 如果编写的代码通过其引用调用方法并传递错误的参数则该调用将在运行时失败而不是在编译时或加载时失败。 可追溯性 –如果反射方法调用失败则可能很难找到导致这一问题的代码行因为堆栈跟踪通常很庞大。 您需要深入研究所有这些invoke()和proxy()调用。 但是如果您研究Spring中的事件侦听器实现或Hibernate中的JPA回调则会在其中看到熟悉的java.lang.reflect.Method引用。 而且我怀疑它是否会在不久的将来更改–成熟的框架又大又复杂用在许多关键任务系统中因此开发人员应该谨慎地进行重大更改。 让我们看看其他选项。 AOT编译和代码生成–使应用程序再次快速 反射替换的第一个候选人–代码生成。 如今我们可以看到诸如Micronaut和Quarkus之类的新框架的兴起它们针对两个目标快速启动时间和低内存占用。 在微服务和无服务器应用程序时代这两个指标至关重要。 最近的框架正试图通过使用提前编译和代码生成来完全摆脱反思。 通过使用注释处理类型访问者和其他技术他们将直接方法调用对象实例化等添加到代码中从而使应用程序更快。 那些不使用Class.newInstance()在启动期间创建和注入bean不在侦听器中使用反射方法调用等等。这看起来很有希望但是这里有什么取舍吗 答案是–是的。 第一个–您运行的代码不完全是您自己的。 代码生成会更改您的原始代码因此如果出现问题您将无法确定是您的错误还是代码处理算法中的故障。 并且不要忘记现在您应该调试生成的代码而不是代码。 第二个权衡–您必须使用供应商提供的单独工具/插件才能使用该框架。 您不能“只是”运行代码而应以特殊方式对其进行预处理。 并且如果您在生产中使用框架则应将供应商的错误修正应用于框架代码库和代码处理工具。 代码生成早已为人所知但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创建期间执行一次所有预调用检查。 长话短说–方法句柄是对基础方法构造函数字段或类似的低级操作的类型化直接可执行的引用具有参数或返回值的可选转换。 令人惊讶的是除非您按照本电子邮件列表中的方法将MethodHandle引用设为静态否则与反射API相比纯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相比开发不会花费更多时间。 翻译自: https://www.javacodegeeks.com/2019/09/think-twice-before-using-reflection.html三思笔记
