珠海市网站开发公司电话,中国货源网一件代发,专业做股权众筹的网站,优秀网页设计教程介绍 有时#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编译器的优化算法越来越好但是反射方法调用的速度仍然比直接方法慢三倍。 类型安全性 –如果在代码中使用方法引用则它只是方法引用。 如果编写的代码通过其引用调用方法并传递错误的参数则该调用将在运行时失败而不是在编译时或加载时失败。 可追溯性 –如果一个反射方法调用失败那么找到导致这一问题的代码行可能会很棘手因为堆栈跟踪通常很庞大。 您需要深入研究所有这些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相比开发不会花费更多时间。 翻译自: https://www.javacodegeeks.com/2019/09/think-twice-before-using-reflection.html
