Java特性关于反射的一些技术

反射：在流行的库如Spring和Hibernate中，反射自然有其用武之地。不过内省业务代码在很多时候都不是一件好事，原因有很多，一般情况下我总是建议大家不要使用反射。

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

code

如果这样做就无法得到编译期的安全保证。就像上面这个示例一样，你会发现如果getDeclaredField()方法调用的参数输错了，那么只有在运行期才能发现。要知道的是，寻找运行期Bug的难度要远远超过编译期的Bug。

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

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