拓冰网站定制 
写Java这么多年反射属于那种“平时用得少、面试必被问、看框架源码躲不掉”的知识点。很多人觉得它神秘无非是因为它打破了“编译期确定类型”的思维习惯而框架能如此灵活地解耦对象创建和组装靠的恰恰就是这一套运行期能力。这篇文章我会从反射的本质讲起再到Class对象、构造器、方法和字段的完整操作方式接着分析性能开销的成因和优化手段然后结合Spring、MyBatis、Jackson这些常用框架讲清楚它在实际工程里的角色最后手写一个基于反射的迷你ORM映射器把知识变成能落地的代码。无论你是准备面试还是想真正理解框架底层这篇都值得认真读一遍。1. 反射的本质运行期才发下来的“万能通行证”1.1 编译期和运行期之间那条“隐形的墙”Java是静态强类型语言编译器按照类型声明做检查、做优化。你看一个类、调用一个方法在编译期就必须写得明明白白否则编译器直接报错。但真实业务里有很多场景在编译期根本不知道目标类长什么样——Spring Bean的实例化依赖配置文件里的类名字符串MyBatis的Mapper接口没有实现类Jackson要把任意Java对象序列化成JSON。这类需求没办法靠new关键字解决必须有一种机制让程序在运行的时候“动态发现”类的结构并操作它这就是反射。用大白话讲编译期编程是拿着打印好的通讯录打电话每个号码都提前写在纸上反射则是运行期给你一个万能查询接口不管谁打进来都可以临时查档案、临时分配线路。反射就是Java语言里那张运行期才发下来的“万能通行证”拿到了它你可以在程序运行过程中查看任意类的构造器、方法、字段甚至可以绕过访问控制直接调用私有成员。这里要澄清一个常见误解反射不是Java为了炫技设计的黑魔法而是为了支撑框架开发和通用工具库而生的基础设施。没有反射Spring的依赖注入、MyBatis的Mapper代理、各种配置驱动框架都无从谈起。所以它看似“越权”实际上是语言设计者刻意开放的运行时自省能力。1.2 一个最小的反射演示先看一个最简单的例子。假设有一个Dog类name字段是私有say方法是私有public class Dog { private String name; public Dog(String name) { this.name name; } private void say(String word) { System.out.println(name says: word); } }正常业务代码只能new Dog(...)然后调用public方法。但用反射可以在运行期完全不知道这个类的源码细节时动态完成创建对象、调用私有方法、修改私有字段全流程public class ReflectionDemo { public static void main(String[] args) throws Exception { // 1. 运行时根据类名找到类的元数据 Class? clazz Class.forName(com.example.Dog); // 2. 拿到私有构造器并创建实例 Constructor? constructor clazz.getDeclaredConstructor(String.class); constructor.setAccessible(true); Object dog constructor.newInstance(旺财); // 3. 拿到私有方法并调用 Method say clazz.getDeclaredMethod(say, String.class); say.setAccessible(true); say.invoke(dog, 汪汪我是反射创建的); // 4. 修改私有字段 Field name clazz.getDeclaredField(name); name.setAccessible(true); name.set(dog, 来福); say.invoke(dog, 汪汪我的名字被改了); } }运行这段代码控制台会依次打出两只狗的叫声。整个过程没有出现一次Dog类型声明所有操作都是围绕一个Class?对象展开的。把这段跑通你对反射就有了最直观的感受反射解决的核心问题就是“运行期动态探索和操作类型”。这种能力听起来很爽但也要明白它的边界它并不改变Java编译期类型检查只是在运行时提供了一条绕过编译器的通道。这也是为什么很多人第一次接触反射时既兴奋又困惑——兴奋的是原来还能这么玩困惑的是不知道哪些场景该用、哪些场景不该用。2. Class对象一切反射操作的总起点2.1 三种姿势拿到Class实例所有反射操作的第一步都是先拿到目标类的Class对象。这个对象是JVM在类加载阶段创建的保存了类的完整元信息。获取方式有三种区别很大获取方式示例写法特点Class.forNameClass.forName(com.example.Dog)按全限定名加载默认会触发类初始化类型字面量Dog.class不会触发初始化编译期安全对象getClassdog.getClass()已有实例时最自然拿运行期实际类型先说Class.forName。它是反射里出场率最高的入口因为只要你有字符串类名就能拿到类。注意它的默认行为会执行静态初始化和静态代码块。如果你只是想获取类信息不希望触发静态副作用可以调用重载方法Class.forName(name, false, classLoader)第二个参数传false表示不进行初始化。再说Dog.class。这种方式在编译期就确定了类是Dog类型安全、性能最好而且不会触发静态初始化。很多新手以为只有Class.forName算反射其实Dog.class也是反射的基础操作只不过因为类型在编译期已知常被忽略。最后是obj.getClass()。它拿到的是实例实际运行时的类在继承和多态场景下特别有用。比如父类引用指向子类对象时getClass()返回的是子类的Class。三者的选择逻辑很简单编译期能确定类型用字面量只有类名字符串用forName已有实例想获取实际类型用getClass。2.2 类加载和Class对象的唯一性关于Class对象还有一个容易被忽略的重要特性同一个类在同一个类加载器下Class对象只有一个。JVM在类加载时会检查这个类是否已经被当前类加载器加载过如果加载过就复用已有的Class对象。但这带来一个经典坑不同类加载器可以各自加载出同名但完全不同的两个Class对象。看下面的测试ClassLoader loader1 new URLClassLoader(new URL[]{url}); ClassLoader loader2 new URLClassLoader(new URL[]{url}); Class? c1 loader1.loadClass(com.example.Dog); Class? c2 loader2.loadClass(com.example.Dog); System.out.println(c1 c2); // false System.out.println(c1.isAssignableFrom(c2)); // false这就是为什么在做热部署、插件化开发、应用隔离时经常出现奇怪的ClassCastException——两边类名一样但类加载器不同Java判定它们不是同一个类。理解这一点对排查框架和容器环境下的类型转换问题非常有帮助。顺带回应一个搜索引擎里常见的热词“java是静态链接的”Java在语法层面是强类型、静态检查的但它的类加载机制和反射能力又给它带来了很强的动态性。说它完全静态是不准确的更准确的说法是“编译期静态运行期高度可扩展”。3. 从构造器、方法到字段完整操作手册3.1 创建对象getConstructor与getDeclaredConstructor有了Class对象接下来最常见的需求就是创建实例。反射里创建实例用的是Constructor对象获取方式有两个getConstructor(Class... parameterTypes)只能拿到public修饰的构造器。getDeclaredConstructor(Class... parameterTypes)能拿到本类声明的所有构造器包括private、protected、包级私有。两者都要求参数类型列表与构造器签名完全匹配。这里有个细节值得注意如果你要创建的对象类没有声明任何构造器JVM会默认生成一个无参构造器通过getConstructor()也能拿到。但如果构造器是private的直接newInstance会抛IllegalAccessException必须调用constructor.setAccessible(true)才能避开访问检查。关于setAccessible(true)多说一句它的作用是允许你访问原本不可见的成员。对于用户自己写的类这个操作基本都能成功但对于JDK内部模块高版本JDK有强限制后面章节会专门讲。另外JDK 9之后Class.newInstance()方法被废弃了。以前的代码习惯是clazz.newInstance()创建实例现在官方推荐统一使用constructor.newInstance()。原因是Class.newInstance()只能调用无参构造器异常处理也很别扭而Constructor.newInstance()更完整、更可控。这也是面试中一个高频点反射如何破坏单例单例的私有构造器在反射面前形同虚设getDeclaredConstructor().setAccessible(true)之后照样能new出新对象。所以单例的正确防御方式是枚举或者构造器里加一个初始化状态校验。3.2 调用方法getMethod和getDeclaredMethod的差异调用方法是反射最核心的操作之一。获取Method同样有一对方法方法作用范围典型场景getMethod本类及继承链上的所有public方法调用第三方公开APIgetDeclaredMethod仅本类声明的所有方法含private调用私有工具方法、注解解析很多人在这一步踩坑方法名写错一个字母或者参数类型传成包装类型导致找不到方法。反射的方法查找是精确匹配方法名和参数列表的所以参数类型必须和声明完全一致比如参数是int.class就不能传Integer.class。invoke方法的使用规则也要记牢// 非静态方法第一个参数传目标实例 Method say Dog.class.getDeclaredMethod(say, String.class); say.setAccessible(true); say.invoke(dog, 你好); // 静态方法第一个参数传null Method sleep Dog.class.getDeclaredMethod(sleep); sleep.invoke(null);反射调用可变参数方法时是个容易翻车的地方。比如一个方法声明为foo(String... args)反射拿Method时参数类型要写成String[].class调用时还要注意不要把数组拆开Method m ArgTest.class.getMethod(foo, String[].class); m.invoke(obj, new Object[]{ new String[]{a, b} });之所以要包一层new Object[]是因为invoke的签名本身是Object... args如果你直接传String[]编译器会把它当成多个参数处理而不是一个数组参数。还有一个常见的“坑中坑”被调方法内部抛出的异常会被反射包装成InvocationTargetException抛出来。很多人看到InvocationTargetException就懵了其实真正的堆栈在cause里。排查问题时一定要记得先unwrap看e.getCause()否则会浪费大量时间在无关的反射包装层上。3.3 读写字段final字段不是一定不能改字段操作的获取方式同样是getField和getDeclaredField区别和上面方法一样一个是public全链路一个是本类全部。修改字段的核心方法是field.set(obj, value)读取是field.get(obj)。如果你要修改的是static字段set的第一个参数传null即可。至于final字段这里有一个面试常考的知识点对于实例final字段早期JDK在setAccessible(true)后仍然可以修改HotSpot JVM下实测可行但从JDK 17开始强封装限制使得这种修改越来越难甚至会抛异常。对于static final字段中的编译期常量修改是无效的。因为编译期常量的值已经被编译器直接写进引用它的字节码里了你运行期改Class对象里的字段值调用方依然能用原来的字面量。更经典的是Integer缓存的问题。Integer.valueOf(1)返回的是内部缓存的Integer对象如果用反射修改这个对象的value字段那么整个JVM里所有值为1的Integer都跟着变。这个操作虽然能跑通但绝对是生产环境禁止的“危险操作”面试里拿出来分析可以千万别在真实代码里乱改。动手做一遍这些操作你会明显感觉到反射并不复杂它只是一套在不同入口和不同权限范围之间组合的API。难点从来不是API本身而是什么时候用、用完之后怎么避免破坏系统的安全边界。4. 为什么反射会慢性能开销拆解与优化4.1 慢在哪三处网上看到很多“反射性能很差”的说法但很少有人讲清楚差在哪里。根据我的实测和阅读JVM实现文档反射的性能开销主要来自三个环节。第一是参数处理。invoke方法的签名是Object target, Object... args这意味着每次调用都需要把实参装箱成Object对象还要放进一个Object数组里。如果方法参数是int、long这样的基本类型装箱拆箱就在所难免。直接调用完全不需要这一步。第二是动态查找。getMethod、getDeclaredField这些操作每次都要在类的元数据里做遍历匹配。虽然HotSpot会对查找结果做一些缓存但相对于编译期就定位好的直接调用还是要多走一层间接寻址。第三是访问检查。每次invoke时JVM都需要确认调用方是否有权限访问这个Method、Field或者Constructor。在setAccessible(false)的情况下这个检查链路尤其长。这也是为什么setAccessible(true)往往能带来可观的性能提升。还有一个隐性开销JIT编译器很难对一个反射调用点做深度的内联优化。直接调用foo()JIT可以把方法内联到调用方甚至做逃逸分析但反射调用在运行期才确定目标在哪里热点优化很难生效。4.2 性能到底差多少我在JDK 8和JDK 17上都跑过简单的基准测试同一个空方法直接调用经过JIT优化后大约是几个纳秒量级而反射invoke大约是在几十到几百纳秒量级差别通常在几十倍。但如果把Method对象缓存起来并调用setAccessible(true)差距可以缩小到一个数量级以内。要注意的是这个差距在绝对时间上仍然很小。一次反射调用几百纳秒如果应用里每天调用几万次完全不是问题。真正需要警惕的是在热循环里高频使用反射比如for循环里逐行做字段拷贝、在每次网络请求的路径上反复获取Method对象这时候性能损耗会随调用量线性放大。4.3 优化手段从缓存到MethodHandle如果确实需要在高频路径上用反射我建议按下面的顺序尝试缓存反射对象。getMethod、getDeclaredField这类查找操作比invoke本身还要贵最好在类加载或应用启动阶段把Method、Constructor、Field对象一次性准备好运行时只做invoke或set。调用setAccessible(true)。这能跳过访问检查在很多场景下带来明显的速度提升。用MethodHandle替代Method。MethodHandle从JDK 7开始提供它的设计目标本来就是为了支持JVM动态语言性能上更接近invokedynamic并且没有那么多数组分配和包装层。MethodHandles.Lookup lookup MethodHandles.lookup(); MethodHandle handle lookup.findVirtual(Dog.class, say, MethodType.methodType(void.class, String.class)); handle.invoke(dog, hello);最彻底的做法是用字节码生成。CGLIB、ASM、Byte Buddy这些库可以在运行期生成目标类的子类或代理类把反射调用转换成直接调用。Spring的AOP在默认情况下用的就是CGLIB代理而不是简单的反射。顺便说一句写业务代码时尽量不要为了“省事”在每次请求里循环反射拷贝对象。我之前见过一个内部工具用反射做大量字段拷贝上线后CPU飙高定位后改成启动期构建字段处理缓存性能直接降了一个数量级。反射是为了解决“运行期不确定性”而存在的不是用来替代普通Java方法调用的。5. 框架代码里的反射它才是框架的“地基”5.1 Spring、MyBatis、Jackson里的反射身影很多人觉得反射平时用不到但只要你用框架反射就在你身边。举三个最典型的例子。Spring IoC容器是反射的重度用户。BeanDefinition里记录的是类的全限定名容器启动时通过Class.forName加载类用Constructor.newInstance创建实例。字段注入、Autowired的解析、Value的赋值底层都是反射在做。可以说没有反射就没有Spring容器。MyBatis里更明显。你定义Mapper接口它没有实现类MyBatis在运行期用JDK动态代理生成Mapper的代理对象。当你调用接口方法时代理对象能拿到Method对象从Method上的Select等注解解析出SQL执行完之后再把ResultSet里的列用反射映射回POJO的字段。这部分我们在最后一节会动手复现。序列化框架也离不开反射。Jackson和Gson虽然优先使用Getter/Setter但在很多POJO没有标准访问器时为了序列化私有字段它们同样会通过反射强行读取。所以有人开玩笑说别以为看框架官方文档就懂框架了真正的大头都在反射和代理的底层实现里。5.2 面试考点从“会背”到“能讲”面试题里反射相关的几个问题表面上是考API本质考的其实是对运行期类型系统的理解。把这些问题的逻辑理清楚比背答案有用得多。反射为什么能破坏单例因为单例的防线只有private构造器而getDeclaredConstructor配合setAccessible(true)可以绕过访问控制。这也是为什么很多资深开发会把枚举作为单例的推荐方案——枚举在JVM层面保证了实例唯一性反射也没办法。反射和泛型擦除有什么关系泛型在运行期会擦除List 和List 在运行时是同一个Class。但这里有个细微差别方法签名和字段上的泛型信息会保留在Class文件里通过Type接口可以取回来。下一章会展开讲。反射慢怎么优化三个关键词缓存Method、setAccessible、MethodHandle。能说出这三个再补一句字节码生成方案面试官基本会满意。框架里为什么大量用反射框架在编译期不知道用户会传进来什么类它必须把“类发现”延迟到运行期。反射本质上是框架和业务代码之间的解耦桥梁。想透这些考点再看Spring源码理解路径会顺畅很多。反射不是孤立的知识它是理解Java生态的一把钥匙。6. 泛型擦除、模块化与安全限制绕不开的边界6.1 泛型信息到底拿不拿得到Java泛型在运行期几乎完全擦除这是很多人的第一反应。但“几乎”这个词很关键类上的泛型参数确实不保留但字段、方法返回值、方法参数上的泛型签名信息是保留在Class文件里的。反射可以通过Type接口把它们读回来。举个例子假设有一个接口方法返回List public class UserService { public ListUser listUsers() { return new ArrayList(); } }用普通反射只能拿到returnType List.class但用getGenericReturnType就能拿到完整的泛型信息Method m UserService.class.getMethod(listUsers); Type returnType m.getGenericReturnType(); if (returnType instanceof ParameterizedType pt) { Type arg pt.getActualTypeArguments()[0]; // User Class? clazz (Class?) arg; System.out.println(clazz.getName()); // com.example.User }Type接口下有四个子接口搞清楚它们各自代表什么才能写明白通用框架ParameterizedType参数化类型比如List 。TypeVariable类型变量比如泛型方法里的T。WildcardType通配符类型比如List? extends Number。GenericArrayType泛型数组比如T[]。手写ORM或者JSON框架时解析泛型返回类型是刚需。MyBatis的ResultHandler能自动把查询结果映射成List 背后就是通过Method的泛型签名知道目标元素类型再按字段名反射装配。6.2 模块化系统给反射上的锁从JDK 9引入模块系统JPMS开始反射的“万能”就打了折扣。模块化规定一个模块的包如果不显式opens给另一个模块另外一个模块哪怕是反射也不能访问它内部即使调用了setAccessible(true)也不行否则抛InaccessibleObjectException。这个限制在实际项目里的最常见表现是Spring Boot应用从JDK 8升到JDK 17后启动时偶尔报类似“Unable to make field accessible”的错误。通常的解决办法是在启动参数里加--add-opens把对应的包打开java --add-opens java.base/java.langALL-UNNAMED -jar app.jar理解这个限制对排错很有帮助。看报错别急着怪框架先想想是不是模块系统把反射访问拦住了。6.3 setAccessible的权限正在收窄反射曾是安全问题的重灾区历史上出现过多条利用反射绕过访问控制、构造反序列化漏洞的攻击链。也正因为如此JDK官方一直在逐步收窄setAccessible的权限。JDK 8及之前有SecurityManager兜底JDK 17之后默认强封装用户代码无法通过反射访问JDK内部模块的私有成员。不过对于用户自己代码里的类setAccessible(true)基本是畅通无阻的。这一点日常开发影响不大但做工具库、Agent类应用时要额外小心考虑用MethodHandles.Lookup或者Unsafe这类更底层的替代方案前一定要想清楚安全边界。一句话总结反射的能力不是无限膨胀的JDK在权限和安全之间反复权衡现在的趋势是“用户类的反射依旧灵活系统类的反射层层加锁”。写代码时遵循最小权限原则只在真正需要运行期动态操作时使用反射而不是把它当成绕过一切约束的万能工具。7. 综合实战手写一个基于反射的迷你ORM映射器7.1 目标与设计前面讲了大量原理这一节我带你做一个能跑的最小项目把反射、注解、动态代理、结果映射串起来。我们复刻MyBatis最核心的一小段逻辑通过Mapper接口上的Select注解动态代理拦截方法调用把SQL中的#{}占位符替换成PreparedStatement的参数执行查询后用反射把ResultSet映射成POJO。先定义注解Retention(RetentionPolicy.RUNTIME) Target(ElementType.METHOD) public interface Select { String value(); }定义一个Mapper接口public interface UserMapper { Select(select * from user where id #{id}) User findById(int id); }7.2 实现动态代理与结果映射核心是InvocationHandler的invoke方法。当调用mapper.findById(1)时实际进入这个invoke方法method参数就是被调用的接口方法public class MapperProxyT implements InvocationHandler { private final ClassT mapperInterface; public MapperProxy(ClassT mapperInterface) { this.mapperInterface mapperInterface; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // Object类的方法直接放行 if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } Select select method.getAnnotation(Select.class); if (select null) { throw new UnsupportedOperationException(no Select on method.getName()); } String sql select.value(); // 保存参数顺序并替换 #{} 为 ? int[] index {0}; String preparedSql sql.replaceAll(#\\{.*?}, match - ?); // 这里要用一个参数容器记录名称到位置的映射 // 简化版本直接按方法参数列表顺序绑定 return query(preparedSql, args); } }实际生产里需要解析#{}里的参数名和SQL字段的对应关系我这里做了简化按参数顺序绑定。重点看两个点一个是通过method.getAnnotation拿到注解一个是通过反射把结果集映射成对象。映射部分的反射操作是这样的private T T mapRow(ResultSet rs, ClassT clazz) throws Exception { ConstructorT constructor clazz.getDeclaredConstructor(); constructor.setAccessible(true); T obj constructor.newInstance(); ResultSetMetaData meta rs.getMetaData(); for (int i 1; i meta.getColumnCount(); i) { String column meta.getColumnLabel(i); // 真实项目中要做驼峰命名转换user_name - userName Field field clazz.getDeclaredField(column); field.setAccessible(true); field.set(obj, rs.getObject(i)); } return obj; }最后通过Proxy.newProxyInstance生成Mapper代理并调用UserMapper mapper (UserMapper) Proxy.newProxyInstance( UserMapper.class.getClassLoader(), new Class[]{UserMapper.class}, new MapperProxy(UserMapper.class) ); User user mapper.findById(1); System.out.println(user.getName());这个迷你ORM虽然简陋但已经把MyBatis最核心的反射路径走通了一遍接口没有实现类也能被调用SQL字符串能被动态解析ResultSet能按列名映射回POJO。跑通这个例子再回头看MyBatis的MapperRegistry、ResultSetHandler你会觉得亲切很多。7.3 还可以继续扩展的方向这个骨架想变成真正可用的工具至少还能加四块内容一是参数绑定解析#{}里的参数名和args数组的映射关系二是类型转换rs.getObject返回的数据库类型和Java字段类型不一定一致需要TypeHandler机制三是泛型返回类型解析比如接口方法返回List 时通过getGenericReturnType拿到User.class再组装List四是缓存把解析好的Method到SQL的映射关系缓存下来避免每次调用都重新反射解析。建议动手改一版。加上缓存和驼峰转换之后这个迷你框架已经有了一个小型ORM的雏形拿来给团队内部的特殊查询场景用也不是不可以。我个人在实际项目里的习惯是凡是用反射的地方都会在类加载或应用启动阶段做一次自检把反射对象提前准备好运行时只做调用。这个方法帮你把最大的一部分性能损耗消化在启动阶段也让问题尽早暴露。反射是一把好用的钥匙但别把它当成万能钥匙到处乱拧放在框架层或工具层、集中在初始化阶段才是它最舒服的位置。 Java反射从入门到实战：原理、性能与框架底层解析
写Java这么多年反射属于那种“平时用得少、面试必被问、看框架源码躲不掉”的知识点。很多人觉得它神秘无非是因为它打破了“编译期确定类型”的思维习惯而框架能如此灵活地解耦对象创建和组装靠的恰恰就是这一套运行期能力。这篇文章我会从反射的本质讲起再到Class对象、构造器、方法和字段的完整操作方式接着分析性能开销的成因和优化手段然后结合Spring、MyBatis、Jackson这些常用框架讲清楚它在实际工程里的角色最后手写一个基于反射的迷你ORM映射器把知识变成能落地的代码。无论你是准备面试还是想真正理解框架底层这篇都值得认真读一遍。1. 反射的本质运行期才发下来的“万能通行证”1.1 编译期和运行期之间那条“隐形的墙”Java是静态强类型语言编译器按照类型声明做检查、做优化。你看一个类、调用一个方法在编译期就必须写得明明白白否则编译器直接报错。但真实业务里有很多场景在编译期根本不知道目标类长什么样——Spring Bean的实例化依赖配置文件里的类名字符串MyBatis的Mapper接口没有实现类Jackson要把任意Java对象序列化成JSON。这类需求没办法靠new关键字解决必须有一种机制让程序在运行的时候“动态发现”类的结构并操作它这就是反射。用大白话讲编译期编程是拿着打印好的通讯录打电话每个号码都提前写在纸上反射则是运行期给你一个万能查询接口不管谁打进来都可以临时查档案、临时分配线路。反射就是Java语言里那张运行期才发下来的“万能通行证”拿到了它你可以在程序运行过程中查看任意类的构造器、方法、字段甚至可以绕过访问控制直接调用私有成员。这里要澄清一个常见误解反射不是Java为了炫技设计的黑魔法而是为了支撑框架开发和通用工具库而生的基础设施。没有反射Spring的依赖注入、MyBatis的Mapper代理、各种配置驱动框架都无从谈起。所以它看似“越权”实际上是语言设计者刻意开放的运行时自省能力。1.2 一个最小的反射演示先看一个最简单的例子。假设有一个Dog类name字段是私有say方法是私有public class Dog { private String name; public Dog(String name) { this.name name; } private void say(String word) { System.out.println(name says: word); } }正常业务代码只能new Dog(...)然后调用public方法。但用反射可以在运行期完全不知道这个类的源码细节时动态完成创建对象、调用私有方法、修改私有字段全流程public class ReflectionDemo { public static void main(String[] args) throws Exception { // 1. 运行时根据类名找到类的元数据 Class? clazz Class.forName(com.example.Dog); // 2. 拿到私有构造器并创建实例 Constructor? constructor clazz.getDeclaredConstructor(String.class); constructor.setAccessible(true); Object dog constructor.newInstance(旺财); // 3. 拿到私有方法并调用 Method say clazz.getDeclaredMethod(say, String.class); say.setAccessible(true); say.invoke(dog, 汪汪我是反射创建的); // 4. 修改私有字段 Field name clazz.getDeclaredField(name); name.setAccessible(true); name.set(dog, 来福); say.invoke(dog, 汪汪我的名字被改了); } }运行这段代码控制台会依次打出两只狗的叫声。整个过程没有出现一次Dog类型声明所有操作都是围绕一个Class?对象展开的。把这段跑通你对反射就有了最直观的感受反射解决的核心问题就是“运行期动态探索和操作类型”。这种能力听起来很爽但也要明白它的边界它并不改变Java编译期类型检查只是在运行时提供了一条绕过编译器的通道。这也是为什么很多人第一次接触反射时既兴奋又困惑——兴奋的是原来还能这么玩困惑的是不知道哪些场景该用、哪些场景不该用。2. Class对象一切反射操作的总起点2.1 三种姿势拿到Class实例所有反射操作的第一步都是先拿到目标类的Class对象。这个对象是JVM在类加载阶段创建的保存了类的完整元信息。获取方式有三种区别很大获取方式示例写法特点Class.forNameClass.forName(com.example.Dog)按全限定名加载默认会触发类初始化类型字面量Dog.class不会触发初始化编译期安全对象getClassdog.getClass()已有实例时最自然拿运行期实际类型先说Class.forName。它是反射里出场率最高的入口因为只要你有字符串类名就能拿到类。注意它的默认行为会执行静态初始化和静态代码块。如果你只是想获取类信息不希望触发静态副作用可以调用重载方法Class.forName(name, false, classLoader)第二个参数传false表示不进行初始化。再说Dog.class。这种方式在编译期就确定了类是Dog类型安全、性能最好而且不会触发静态初始化。很多新手以为只有Class.forName算反射其实Dog.class也是反射的基础操作只不过因为类型在编译期已知常被忽略。最后是obj.getClass()。它拿到的是实例实际运行时的类在继承和多态场景下特别有用。比如父类引用指向子类对象时getClass()返回的是子类的Class。三者的选择逻辑很简单编译期能确定类型用字面量只有类名字符串用forName已有实例想获取实际类型用getClass。2.2 类加载和Class对象的唯一性关于Class对象还有一个容易被忽略的重要特性同一个类在同一个类加载器下Class对象只有一个。JVM在类加载时会检查这个类是否已经被当前类加载器加载过如果加载过就复用已有的Class对象。但这带来一个经典坑不同类加载器可以各自加载出同名但完全不同的两个Class对象。看下面的测试ClassLoader loader1 new URLClassLoader(new URL[]{url}); ClassLoader loader2 new URLClassLoader(new URL[]{url}); Class? c1 loader1.loadClass(com.example.Dog); Class? c2 loader2.loadClass(com.example.Dog); System.out.println(c1 c2); // false System.out.println(c1.isAssignableFrom(c2)); // false这就是为什么在做热部署、插件化开发、应用隔离时经常出现奇怪的ClassCastException——两边类名一样但类加载器不同Java判定它们不是同一个类。理解这一点对排查框架和容器环境下的类型转换问题非常有帮助。顺带回应一个搜索引擎里常见的热词“java是静态链接的”Java在语法层面是强类型、静态检查的但它的类加载机制和反射能力又给它带来了很强的动态性。说它完全静态是不准确的更准确的说法是“编译期静态运行期高度可扩展”。3. 从构造器、方法到字段完整操作手册3.1 创建对象getConstructor与getDeclaredConstructor有了Class对象接下来最常见的需求就是创建实例。反射里创建实例用的是Constructor对象获取方式有两个getConstructor(Class... parameterTypes)只能拿到public修饰的构造器。getDeclaredConstructor(Class... parameterTypes)能拿到本类声明的所有构造器包括private、protected、包级私有。两者都要求参数类型列表与构造器签名完全匹配。这里有个细节值得注意如果你要创建的对象类没有声明任何构造器JVM会默认生成一个无参构造器通过getConstructor()也能拿到。但如果构造器是private的直接newInstance会抛IllegalAccessException必须调用constructor.setAccessible(true)才能避开访问检查。关于setAccessible(true)多说一句它的作用是允许你访问原本不可见的成员。对于用户自己写的类这个操作基本都能成功但对于JDK内部模块高版本JDK有强限制后面章节会专门讲。另外JDK 9之后Class.newInstance()方法被废弃了。以前的代码习惯是clazz.newInstance()创建实例现在官方推荐统一使用constructor.newInstance()。原因是Class.newInstance()只能调用无参构造器异常处理也很别扭而Constructor.newInstance()更完整、更可控。这也是面试中一个高频点反射如何破坏单例单例的私有构造器在反射面前形同虚设getDeclaredConstructor().setAccessible(true)之后照样能new出新对象。所以单例的正确防御方式是枚举或者构造器里加一个初始化状态校验。3.2 调用方法getMethod和getDeclaredMethod的差异调用方法是反射最核心的操作之一。获取Method同样有一对方法方法作用范围典型场景getMethod本类及继承链上的所有public方法调用第三方公开APIgetDeclaredMethod仅本类声明的所有方法含private调用私有工具方法、注解解析很多人在这一步踩坑方法名写错一个字母或者参数类型传成包装类型导致找不到方法。反射的方法查找是精确匹配方法名和参数列表的所以参数类型必须和声明完全一致比如参数是int.class就不能传Integer.class。invoke方法的使用规则也要记牢// 非静态方法第一个参数传目标实例 Method say Dog.class.getDeclaredMethod(say, String.class); say.setAccessible(true); say.invoke(dog, 你好); // 静态方法第一个参数传null Method sleep Dog.class.getDeclaredMethod(sleep); sleep.invoke(null);反射调用可变参数方法时是个容易翻车的地方。比如一个方法声明为foo(String... args)反射拿Method时参数类型要写成String[].class调用时还要注意不要把数组拆开Method m ArgTest.class.getMethod(foo, String[].class); m.invoke(obj, new Object[]{ new String[]{a, b} });之所以要包一层new Object[]是因为invoke的签名本身是Object... args如果你直接传String[]编译器会把它当成多个参数处理而不是一个数组参数。还有一个常见的“坑中坑”被调方法内部抛出的异常会被反射包装成InvocationTargetException抛出来。很多人看到InvocationTargetException就懵了其实真正的堆栈在cause里。排查问题时一定要记得先unwrap看e.getCause()否则会浪费大量时间在无关的反射包装层上。3.3 读写字段final字段不是一定不能改字段操作的获取方式同样是getField和getDeclaredField区别和上面方法一样一个是public全链路一个是本类全部。修改字段的核心方法是field.set(obj, value)读取是field.get(obj)。如果你要修改的是static字段set的第一个参数传null即可。至于final字段这里有一个面试常考的知识点对于实例final字段早期JDK在setAccessible(true)后仍然可以修改HotSpot JVM下实测可行但从JDK 17开始强封装限制使得这种修改越来越难甚至会抛异常。对于static final字段中的编译期常量修改是无效的。因为编译期常量的值已经被编译器直接写进引用它的字节码里了你运行期改Class对象里的字段值调用方依然能用原来的字面量。更经典的是Integer缓存的问题。Integer.valueOf(1)返回的是内部缓存的Integer对象如果用反射修改这个对象的value字段那么整个JVM里所有值为1的Integer都跟着变。这个操作虽然能跑通但绝对是生产环境禁止的“危险操作”面试里拿出来分析可以千万别在真实代码里乱改。动手做一遍这些操作你会明显感觉到反射并不复杂它只是一套在不同入口和不同权限范围之间组合的API。难点从来不是API本身而是什么时候用、用完之后怎么避免破坏系统的安全边界。4. 为什么反射会慢性能开销拆解与优化4.1 慢在哪三处网上看到很多“反射性能很差”的说法但很少有人讲清楚差在哪里。根据我的实测和阅读JVM实现文档反射的性能开销主要来自三个环节。第一是参数处理。invoke方法的签名是Object target, Object... args这意味着每次调用都需要把实参装箱成Object对象还要放进一个Object数组里。如果方法参数是int、long这样的基本类型装箱拆箱就在所难免。直接调用完全不需要这一步。第二是动态查找。getMethod、getDeclaredField这些操作每次都要在类的元数据里做遍历匹配。虽然HotSpot会对查找结果做一些缓存但相对于编译期就定位好的直接调用还是要多走一层间接寻址。第三是访问检查。每次invoke时JVM都需要确认调用方是否有权限访问这个Method、Field或者Constructor。在setAccessible(false)的情况下这个检查链路尤其长。这也是为什么setAccessible(true)往往能带来可观的性能提升。还有一个隐性开销JIT编译器很难对一个反射调用点做深度的内联优化。直接调用foo()JIT可以把方法内联到调用方甚至做逃逸分析但反射调用在运行期才确定目标在哪里热点优化很难生效。4.2 性能到底差多少我在JDK 8和JDK 17上都跑过简单的基准测试同一个空方法直接调用经过JIT优化后大约是几个纳秒量级而反射invoke大约是在几十到几百纳秒量级差别通常在几十倍。但如果把Method对象缓存起来并调用setAccessible(true)差距可以缩小到一个数量级以内。要注意的是这个差距在绝对时间上仍然很小。一次反射调用几百纳秒如果应用里每天调用几万次完全不是问题。真正需要警惕的是在热循环里高频使用反射比如for循环里逐行做字段拷贝、在每次网络请求的路径上反复获取Method对象这时候性能损耗会随调用量线性放大。4.3 优化手段从缓存到MethodHandle如果确实需要在高频路径上用反射我建议按下面的顺序尝试缓存反射对象。getMethod、getDeclaredField这类查找操作比invoke本身还要贵最好在类加载或应用启动阶段把Method、Constructor、Field对象一次性准备好运行时只做invoke或set。调用setAccessible(true)。这能跳过访问检查在很多场景下带来明显的速度提升。用MethodHandle替代Method。MethodHandle从JDK 7开始提供它的设计目标本来就是为了支持JVM动态语言性能上更接近invokedynamic并且没有那么多数组分配和包装层。MethodHandles.Lookup lookup MethodHandles.lookup(); MethodHandle handle lookup.findVirtual(Dog.class, say, MethodType.methodType(void.class, String.class)); handle.invoke(dog, hello);最彻底的做法是用字节码生成。CGLIB、ASM、Byte Buddy这些库可以在运行期生成目标类的子类或代理类把反射调用转换成直接调用。Spring的AOP在默认情况下用的就是CGLIB代理而不是简单的反射。顺便说一句写业务代码时尽量不要为了“省事”在每次请求里循环反射拷贝对象。我之前见过一个内部工具用反射做大量字段拷贝上线后CPU飙高定位后改成启动期构建字段处理缓存性能直接降了一个数量级。反射是为了解决“运行期不确定性”而存在的不是用来替代普通Java方法调用的。5. 框架代码里的反射它才是框架的“地基”5.1 Spring、MyBatis、Jackson里的反射身影很多人觉得反射平时用不到但只要你用框架反射就在你身边。举三个最典型的例子。Spring IoC容器是反射的重度用户。BeanDefinition里记录的是类的全限定名容器启动时通过Class.forName加载类用Constructor.newInstance创建实例。字段注入、Autowired的解析、Value的赋值底层都是反射在做。可以说没有反射就没有Spring容器。MyBatis里更明显。你定义Mapper接口它没有实现类MyBatis在运行期用JDK动态代理生成Mapper的代理对象。当你调用接口方法时代理对象能拿到Method对象从Method上的Select等注解解析出SQL执行完之后再把ResultSet里的列用反射映射回POJO的字段。这部分我们在最后一节会动手复现。序列化框架也离不开反射。Jackson和Gson虽然优先使用Getter/Setter但在很多POJO没有标准访问器时为了序列化私有字段它们同样会通过反射强行读取。所以有人开玩笑说别以为看框架官方文档就懂框架了真正的大头都在反射和代理的底层实现里。5.2 面试考点从“会背”到“能讲”面试题里反射相关的几个问题表面上是考API本质考的其实是对运行期类型系统的理解。把这些问题的逻辑理清楚比背答案有用得多。反射为什么能破坏单例因为单例的防线只有private构造器而getDeclaredConstructor配合setAccessible(true)可以绕过访问控制。这也是为什么很多资深开发会把枚举作为单例的推荐方案——枚举在JVM层面保证了实例唯一性反射也没办法。反射和泛型擦除有什么关系泛型在运行期会擦除List 和List 在运行时是同一个Class。但这里有个细微差别方法签名和字段上的泛型信息会保留在Class文件里通过Type接口可以取回来。下一章会展开讲。反射慢怎么优化三个关键词缓存Method、setAccessible、MethodHandle。能说出这三个再补一句字节码生成方案面试官基本会满意。框架里为什么大量用反射框架在编译期不知道用户会传进来什么类它必须把“类发现”延迟到运行期。反射本质上是框架和业务代码之间的解耦桥梁。想透这些考点再看Spring源码理解路径会顺畅很多。反射不是孤立的知识它是理解Java生态的一把钥匙。6. 泛型擦除、模块化与安全限制绕不开的边界6.1 泛型信息到底拿不拿得到Java泛型在运行期几乎完全擦除这是很多人的第一反应。但“几乎”这个词很关键类上的泛型参数确实不保留但字段、方法返回值、方法参数上的泛型签名信息是保留在Class文件里的。反射可以通过Type接口把它们读回来。举个例子假设有一个接口方法返回List public class UserService { public ListUser listUsers() { return new ArrayList(); } }用普通反射只能拿到returnType List.class但用getGenericReturnType就能拿到完整的泛型信息Method m UserService.class.getMethod(listUsers); Type returnType m.getGenericReturnType(); if (returnType instanceof ParameterizedType pt) { Type arg pt.getActualTypeArguments()[0]; // User Class? clazz (Class?) arg; System.out.println(clazz.getName()); // com.example.User }Type接口下有四个子接口搞清楚它们各自代表什么才能写明白通用框架ParameterizedType参数化类型比如List 。TypeVariable类型变量比如泛型方法里的T。WildcardType通配符类型比如List? extends Number。GenericArrayType泛型数组比如T[]。手写ORM或者JSON框架时解析泛型返回类型是刚需。MyBatis的ResultHandler能自动把查询结果映射成List 背后就是通过Method的泛型签名知道目标元素类型再按字段名反射装配。6.2 模块化系统给反射上的锁从JDK 9引入模块系统JPMS开始反射的“万能”就打了折扣。模块化规定一个模块的包如果不显式opens给另一个模块另外一个模块哪怕是反射也不能访问它内部即使调用了setAccessible(true)也不行否则抛InaccessibleObjectException。这个限制在实际项目里的最常见表现是Spring Boot应用从JDK 8升到JDK 17后启动时偶尔报类似“Unable to make field accessible”的错误。通常的解决办法是在启动参数里加--add-opens把对应的包打开java --add-opens java.base/java.langALL-UNNAMED -jar app.jar理解这个限制对排错很有帮助。看报错别急着怪框架先想想是不是模块系统把反射访问拦住了。6.3 setAccessible的权限正在收窄反射曾是安全问题的重灾区历史上出现过多条利用反射绕过访问控制、构造反序列化漏洞的攻击链。也正因为如此JDK官方一直在逐步收窄setAccessible的权限。JDK 8及之前有SecurityManager兜底JDK 17之后默认强封装用户代码无法通过反射访问JDK内部模块的私有成员。不过对于用户自己代码里的类setAccessible(true)基本是畅通无阻的。这一点日常开发影响不大但做工具库、Agent类应用时要额外小心考虑用MethodHandles.Lookup或者Unsafe这类更底层的替代方案前一定要想清楚安全边界。一句话总结反射的能力不是无限膨胀的JDK在权限和安全之间反复权衡现在的趋势是“用户类的反射依旧灵活系统类的反射层层加锁”。写代码时遵循最小权限原则只在真正需要运行期动态操作时使用反射而不是把它当成绕过一切约束的万能工具。7. 综合实战手写一个基于反射的迷你ORM映射器7.1 目标与设计前面讲了大量原理这一节我带你做一个能跑的最小项目把反射、注解、动态代理、结果映射串起来。我们复刻MyBatis最核心的一小段逻辑通过Mapper接口上的Select注解动态代理拦截方法调用把SQL中的#{}占位符替换成PreparedStatement的参数执行查询后用反射把ResultSet映射成POJO。先定义注解Retention(RetentionPolicy.RUNTIME) Target(ElementType.METHOD) public interface Select { String value(); }定义一个Mapper接口public interface UserMapper { Select(select * from user where id #{id}) User findById(int id); }7.2 实现动态代理与结果映射核心是InvocationHandler的invoke方法。当调用mapper.findById(1)时实际进入这个invoke方法method参数就是被调用的接口方法public class MapperProxyT implements InvocationHandler { private final ClassT mapperInterface; public MapperProxy(ClassT mapperInterface) { this.mapperInterface mapperInterface; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // Object类的方法直接放行 if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } Select select method.getAnnotation(Select.class); if (select null) { throw new UnsupportedOperationException(no Select on method.getName()); } String sql select.value(); // 保存参数顺序并替换 #{} 为 ? int[] index {0}; String preparedSql sql.replaceAll(#\\{.*?}, match - ?); // 这里要用一个参数容器记录名称到位置的映射 // 简化版本直接按方法参数列表顺序绑定 return query(preparedSql, args); } }实际生产里需要解析#{}里的参数名和SQL字段的对应关系我这里做了简化按参数顺序绑定。重点看两个点一个是通过method.getAnnotation拿到注解一个是通过反射把结果集映射成对象。映射部分的反射操作是这样的private T T mapRow(ResultSet rs, ClassT clazz) throws Exception { ConstructorT constructor clazz.getDeclaredConstructor(); constructor.setAccessible(true); T obj constructor.newInstance(); ResultSetMetaData meta rs.getMetaData(); for (int i 1; i meta.getColumnCount(); i) { String column meta.getColumnLabel(i); // 真实项目中要做驼峰命名转换user_name - userName Field field clazz.getDeclaredField(column); field.setAccessible(true); field.set(obj, rs.getObject(i)); } return obj; }最后通过Proxy.newProxyInstance生成Mapper代理并调用UserMapper mapper (UserMapper) Proxy.newProxyInstance( UserMapper.class.getClassLoader(), new Class[]{UserMapper.class}, new MapperProxy(UserMapper.class) ); User user mapper.findById(1); System.out.println(user.getName());这个迷你ORM虽然简陋但已经把MyBatis最核心的反射路径走通了一遍接口没有实现类也能被调用SQL字符串能被动态解析ResultSet能按列名映射回POJO。跑通这个例子再回头看MyBatis的MapperRegistry、ResultSetHandler你会觉得亲切很多。7.3 还可以继续扩展的方向这个骨架想变成真正可用的工具至少还能加四块内容一是参数绑定解析#{}里的参数名和args数组的映射关系二是类型转换rs.getObject返回的数据库类型和Java字段类型不一定一致需要TypeHandler机制三是泛型返回类型解析比如接口方法返回List 时通过getGenericReturnType拿到User.class再组装List四是缓存把解析好的Method到SQL的映射关系缓存下来避免每次调用都重新反射解析。建议动手改一版。加上缓存和驼峰转换之后这个迷你框架已经有了一个小型ORM的雏形拿来给团队内部的特殊查询场景用也不是不可以。我个人在实际项目里的习惯是凡是用反射的地方都会在类加载或应用启动阶段做一次自检把反射对象提前准备好运行时只做调用。这个方法帮你把最大的一部分性能损耗消化在启动阶段也让问题尽早暴露。反射是一把好用的钥匙但别把它当成万能钥匙到处乱拧放在框架层或工具层、集中在初始化阶段才是它最舒服的位置。