在我们实际开发中，如果你经常造轮子，可能免不了去使用反射。反射，可以在运行期间动态执行访问类，方法及字段，会大大提高框架的灵活性，但，反射的性能一直是被诟病的。

那么，如果我们必须需要在运行期间去访问对应的方法怎么办呢？这里简单讲讲个人在近几年总结出来的几点经验。

1、缓存访问的对象，适当时候可使用内省代替

以反射调用方法为例，尽量不要每次去查找Method对象，可以通过一个Map把Method对象缓存起来，因为查找Method对象很消耗性能，但即使这样，和方法直接调用比可能还是相差了5倍以上性能。
如果你是访问字段的get/set方法，使用内省去查找Method对象性能可能会更好，但需要注意的是，使用内省访问boolean字段的get/set方法可能有点问题。

注意：内省只是查找Method会更快，但执行Method方法还是通过反射！！！

优点：简单粗暴，如果对性能没有太高要求可以优先使用此方案。

缺点：性能不如原生的快，如果是在很大的循环中执行，性能会和原生明显产生差异。

2、接口优先于反射

对于某些场景下，我们完全通过可以通过接口解决问题。这里我们有个设计原则，就是接口优先反射，接口可以让我们在运行期间方法直接调用，无反射开销。性能肯定是最大的。

使用场景诸如：回调方法，获取传入对象某个标志属性等等。

优点：性能和原生调用无差异，一般不会有性能瓶颈，并且拥有编译期检查的好处。

缺点：仅适用于部分场景，不适用于大规模使用的场景，例如，如果我要编写一个orm框架，使用此方案去实现一个orm框架是非常不靠谱的。

3、属性访问器

在某些大牛写的orm框架中，我们或者可以看到属性访问器的身影，他基于Java8函数式编程。

简单来说，将一个实体类中的属性和get,set方法通过Lambda表达式的方式包装到一个Map当中。美中不足的是，这个Map可能需要用户自己去构建。然后框架在调用对应的get.set的时候直接通过Map中去获取对应的lambda表达式，然后去执行。

优点：性能和原生调用无差异，一般性能也不太有太大瓶颈。

缺点：用户需要编写的代码更多，并且可以称之为垃圾代码。即便你可以通过代码生成器来开发。

4、使用字节码技术

这个可以说是杀手锏了，也是主流框架中常用的技术。他的工作原理是：使用诸如javassist类似框架，动态生成一个类，通过classLoader机制，动态载入jvm内存中，然后再利用java的多态机制，通过接口或是抽象类的方式去调用这个被jvm载入内存中的类，也是无开销，完全清除了反射代码的存在。

在我们常用的框架中，有fastjson、orika等等这类的框架使用的都是字节码技术去实现的。

假如我们要编写一个orm框架，通过javassist动态编写一个类，他可以将一个ResultSet对象每一行转换成一个具体对象，这其实是一个非常具有挑战的事，我们可能需要经过大量的测试才能让这个框架稳定。这里推荐一个框架，那就是
ReflectASM，他就是基于这个原理实现，可以方便的获取实体类的get/set方法，具体使用可以在github中看到：https://github.com/EsotericSoftware/reflectasm

当然，如果你能自己动态编写出这个类出来，性能肯定会比ReflectASM要好，因为ReflectASM每次还会通过索引去取对应的方法。但对应大多情况而言，ReflectASM足以满足我们的需要了。

优点：性能接近于原生，适用于复杂场景，并且很灵活。
缺点：对编码人员能力素质方面要求比较高。

建议在性能要求高的时候再考虑使用此方案。

5、魔法类：sun.misc.Unsafe

他是java中一大魔法类，类似于C语言中的指针，这里不做具体介绍其用法 ，大家如果有兴趣可以上网找找，会有很多资料，这里就不一一搬运。本文主要讲解反射必须的解决思路。

他可以直接去在内存中进行操作，不受访问修饰符的控制，甚至于可以绕过构造方法去创建对象，CAS底层主要依赖此功能实现。但是他是一把双刃剑，用的好的人，可以创造出卓越的性能。

一定要注意：他正和他的名字一样，Unsafe，是不安全的，他的所有操作是不受Jvm管理的，容易oom，需要自己手动回收资源，gc不会自动去回收。

优点：可以绕过jvm为所欲为，没有什么不可以，性能甚至高于原生代码。
缺点：对编码人员有极高的能力方面要求，并且加大维护成本。

结语

以上我要说的，都是必须要用反射情况下的解决方案，切忌，能不用反射的一定不要用反射。如果本人说的不全，欢迎楼下补充，大家一起学习进步。