认识达内从这里开始

昆明IT培训的老师提醒大家不需要太多关注反射效率。

反射的效率是一个老生常谈的问题，有"经验"的开发人员经常会使用这句话恐吓新人：反射的效率是非常低的，不到万不得已就不要使用。事实上，这句话前半句是对的，后半句是错的。

反射的效率相对于正常的代码执行确实低很多，但它是一个非常有效的运行期工具类，只要代码结构清晰、可读性好那就先开发起来，等到进行性能测试时证明此处性能确实有问题再修改也不迟(一般情况下，反射并不是性能的终极杀手，而代码结构混乱、可读性差则可能会埋下性能隐患)。昆明IT培训的老师带大家看这样一个例子，在运行期获得泛型类的泛型，代码如下：

class Utils {

//获得一个泛型类的实际泛型类型

public static <T> Class<T> getGenricClassType(Class clz) {

Type type = clz.getGenericSuperclass();

if (type instanceof ParameterizedType) {

ParameterizedType pt = (ParameterizedType) type;

Type[] types = pt.getActualTypeArguments();

if (types.length > 0 && types[0] instanceof Class) {

//若有多个泛型参数，依据位置索引返回

return (Class<T>) types[0];

}

}

return (Class<T>) Object.class;

}

}

前面昆明IT培训的老师讲过，Java泛型只存在于编译器，那为什么这个工具类可以取得运行期的泛型类型呢?那是因为该工具只支持继承的泛型类，如果是在Java编译时已经确定了泛型类的类型参数，那当然可以通过泛型类获得了。例如有这样一个泛型类：

abstract class BaseDao<T>{

//获得T运行期的类型

private Class<T> clz = Utils.getGenricClassType(getClass());

//根据主键获得一条记录

public void get(long id){

session.get(clz,id);

}

}

//操作user表

class UserDao extends BaseDao<String>{

}

对于UserDao类，编译器编译时已经明确了其参数类型是String，因此可以通过反射的方式来获取其类型，这也是getGenricClassType方法使用的场景。

BaseDao和UserDao是ORM中的常客，BaseDao实现对数据库的基本操作，比如增删改查，而UserDao则是一个比较具体的数据库操作，其作用是对User表进行操作，如果BaseDao能够提供足够多的基本方法，比如单表的增删改查，哪些与UserDao类似的BaseDao子类就可以省却大量的开发工作。但问题是持久层的session对象(这里模拟的是HibernateSession)需要明确一个具体的类型才能操作，比如get查询，需要获得两个参数：实体类类型(用于确定映射的数据表)和主键，主键好办，问题是实体类类型怎么获得呢？

子类进行传递?麻烦，而且也容易产生错误。

读取配置问题？可行，但效率不高。

最好的办法就是父类泛型化，子类明确泛型参数，然后通过反射读取相应的类型即可，于是就有了我们代码中clz变量：通过反射获得泛型类型。如此实现后，UserDao可不用定义任何方法，继承过来的父类操作方法已经满足基本需求了，这样的代码结构清晰，可读性又好。

想想看，如果考虑反射效率问题，没有clz变量，不使用反射，每个BaseDao的子类都要实现一个查询操作，代码将会大量重复，违反了" Don't Repeat Yourself "这条最基本的编码规则，这会致使项目重构、优化难度加大，代码的复杂度也会提高很多。

对于反射效率的问题，不要做任何的提前优化和预期，这基本上是杞人忧天，很少有项目是因为反射问题引起系统效率故障的（除非是拷贝的垃圾代码），而且根据二八原则，80%的性能消耗在20%的代码上，这20%的代码才是我们关注的重点，不要单单把反射作为重点关注对象。

昆明IT培训的老师提醒大家注意：反射效率低是个真命题，但因为这一点而不使用它就是个假命题。