Java反射机制的适用场景及其利与弊

  • 格式:pdf
  • 大小:256.37 KB
  • 文档页数:2

Java反射机制的适⽤场景及其利与弊

摘⾃:https://blog.csdn.net/zolalad/article/details/29370565 ⼀、反射的适⽤场景是什么?1).Java的反射机制在做基础框架的时候⾮常有⽤,有⼀句话这么说来着:反射机制是很多Java框架的基⽯。⽽⼀般应⽤层⾯很少⽤,不过这种东西,现在很多开源框架基本都已经给你封装好了,⾃⼰基本⽤不着写。典型的除了Hibernate之外,还有Spring也⽤到很多反射机制。经典的就是在xml⽂件或者properties⾥⾯写好了配置,然后在Java类⾥⾯解析xml或properties⾥⾯的内容,得到⼀个字符串,然后⽤反射机制,根据这个字符串获得某个类的Class实例,这样就可以动态配置⼀些东西,不⽤每⼀次都要在代码⾥⾯去new或者做其他的事情,以后要改的话直接改配置⽂件,代码维护起来就很⽅便了,同时有时候要适应某些需求,Java类⾥⾯不⼀定能直接调⽤另外的⽅法,这时候也可以通过反射机制来实现。总的来说,⾃⼰写的很少,具体什么时候要⽤那要看需求,反射机制⽆⾮就是根据⼀个String来得到你要的实体对象,然后调⽤它原来的东西。但是如果是要⾃⼰写框架的话,那就会⽤得⽐较多了。2)当你做⼀个软件可以安装插件的功能,你连插件的类型名称都不知道,你怎么实例化这个对象呢?因为程序是⽀持插件的(第三⽅的),在开发的时候并不知道 。所以⽆法在代码中 New出来 ,但反射可以,通过反射,动态加载程序集,然后读出类,检查标记之后再实例化对象,就可以获得正确的类实例。3)在编码阶段不知道那个类名,要在运⾏期从配置⽂件读取类名, 这时候就没有办法硬编码new ClassName(),⽽必须⽤到反射才能创建这个对象.反射的⽬的就是为了扩展未知的应⽤。⽐如你写了⼀个程序,这个程序定义了⼀些接⼝,只要实现了这些接⼝的dll都可以作为插件来插⼊到这个程序中。那么怎么实现呢?就可以通过反射来实现。就是把dll加载进内存,然后通过反射的⽅式来调⽤dll中的⽅法。很多⼯⼚模式就是使⽤的反射。

⼆、程序员在⾃⼰的业务开发中应该尽量的远离反射

反射:在流⾏的库如Spring和Hibernate中,反射⾃然有其⽤武之地。不过内省业务代码在很多时候都不是⼀件好事,原因有很多,⼀般情况下我总是建议⼤家不要使⽤反射。

⾸先是代码可读性与⼯具⽀持。打开熟悉的IDE,寻找你的Java代码的内部依赖,很容易吧。现在,使⽤反射来替换掉你的代码然后再试⼀下,结果如何呢?如果通过反射来修改已经封装好的对象状态,那么结果将会变得更加不可控。请看看如下⽰例代码:

如果这样做就⽆法得到编译期的安全保证。就像上⾯这个⽰例⼀样,你会发现如果getDeclaredField()⽅法调⽤的参数输错了,那么只有在运⾏期才能发现。要知道的是,寻找运⾏期Bug的难度要远远超过编译期的Bug。

最后还要谈谈代价问题。JIT对反射的优化程度是不同的,有些优化时间会更长⼀些,⽽有些甚⾄是⽆法应⽤优化。因此,有时反射的性能损失可以达到⼏个数量级的差别。不过在典型的业务应⽤中,你可能不会注意到这个代价。

总结⼀下,我觉得在业务代码中唯⼀合理(直接)使⽤反射的场景是通过AOP。除此之外,你最好远离反射这⼀特性。

三、性能分析

反射机制是⼀种程序⾃我分析的能⼒。⽤于获取⼀个类的类变量,构造函数,⽅法,修饰符。优点:运⾏期类型的判断,动态类加载,动态代理使⽤反射。

缺点:性能是⼀个问题,反射相当于⼀系列解释操作,通知jvm要做的事情,性能⽐直接的java代码要慢很多。