很多朋友第一次接触Java反射和代理是在看Spring源码或者准备面试的时候。说实话我当初也是被“反射机制”、“动态代理”、“CGLIB”这一串名词搞得有点晕直到自己动手写过一个迷你版框架才真正把这些概念串起来。这篇东西我就用自己的视角把反射和代理这两块底层的机制掰开揉碎讲清楚再带着你从零写一个简化版IoC容器和事务代理让你看完直接能上手而不是停留在背概念。这篇文章适合的人群很明确正在啃Spring、MyBatis这类框架源码的开发者准备Java面试被问到“反射和代理”脑袋空白的同学以及写业务代码久了、想往底层看一眼的进阶选手。我会尽量把每一步的原理解释透告诉你为什么框架作者要这么做踩坑的地方也会单独标出来。1. 框架为什么绕不开反射和代理1.1 从IoC容器说起我们先回忆一下Spring IoC的核心行为你不用自己new对象而是告诉Spring“我要一个UserService”容器就给你一个已经注入好依赖的实例。这个过程有个关键矛盾——编译期Spring根本不知道你要什么类它只能在运行时根据字符串类名去加载、创建、装配。这个“运行时按类名创建对象并注入属性”的能力就是反射给的。你可以把它理解为一种“晚绑定”代码写在前面但具体绑到哪个类、哪个方法拖到运行那一刻才决定。我见过不少同学能背出IoC的官方定义但问他“Spring到底怎么把bean创建出来的”就卡住了。其实核心就两步骤一是扫描class文件把类名和注解信息存进一个注册表二是获取类名后用反射创建实例再用反射读取字段上的注解把依赖对象塞进去。这里面每一步都在用Class、Constructor、Field、Method这些反射API。所以不搞懂反射你看到的Spring源码就像一本加密的天书每行都在调用那些“看起来神秘”的方法但你不明白它们背后做了什么。1.2 AOP的代理基础Spring AOP能实现日志、事务、权限这些横切逻辑靠的不是在业务代码里硬编码而是悄悄给目标对象穿上一个“替身马甲”。这个替身马甲就是代理对象。代理的核心思想其实很简单调用方以为自己操作的是真实对象实际却先经过了一个替身替身在调用前后穿插了额外逻辑。静态代理就像你雇了一个贴身助理每个请求都要亲手写一个助理类动态代理则像你雇了一个万能助理一个助理类能同时服务无数个业务对象具体拦截逻辑以回调形式注入即可。但动态代理在Java里不是只有一种实现方式JDK自己带了一套第三方CGLIB又提供了另一套。Spring在用的过程中还得根据目标类是否实现接口来取舍。你光知道“动态代理”四个字不深入理解这两套机制的细节和差异面试时一追问就露馅。1.3 框架设计的本质如果非要用一句话总结框架的本质就是“把繁琐的通用逻辑抽出来让你只需要关注业务”。但通用逻辑怎么才能通用答案是你说的类我都不认识那就只能靠反射去动态发现、动态调用你想要增强逻辑而不用改业务代码那就只能靠代理去动态包装。我习惯把反射看作“元编程”的基础能力把代理看作“结构化拦截”的实现手段。两者经常配合使用框架先通过反射拿到目标类的元信息再通过代理生成一个包装后的对象最后把这个包装对象交给调用方。理解了这条链路再看任何主流框架都会有一种豁然开朗的感觉。2. 反射机制核心细节2.1 获取Class对象的三种方式与类加载时机反射的入口是Class对象获取它的方式有讲究。第一种直接通过类名获取比如UserService.class。这种方式不会触发类的静态初始化只是把已经加载好的Class对象拿过来。第二种通过实例获取比如userService.getClass()。这种方式只有在已经持有对象实例时才能用局限性很明显。第三种最常用也最能体现反射价值的方式是通过字符串类名加载Class.forName(com.demo.UserService)。重点在于forName()会触发类的初始化——也就是说静态代码块、静态变量赋值都会执行。这个差异在面试里经常被问到实际开发中也有影响比如你用forName加载JDBC驱动时就是为了触发驱动类里的静态注册逻辑。我自己在实际项目中遇到过一个小坑类不在当前classpath里forName会直接抛ClassNotFoundException。所以用反射加载类时尽量把异常处理写好别让它直接炸到上层。Class? clazz Class.forName(com.demo.UserServiceImpl); Object instance clazz.getDeclaredConstructor().newInstance();newInstance()这个方法在JDK 9之后被标记为废弃推荐用getDeclaredConstructor().newInstance()来代替。原因主要是它只能调用无参构造且异常处理不够清晰。我在写底层工具时一直用新写法更安全也更好排查问题。2.2 构造器、方法、字段的访问规则拿到Class之后接下来就是通过它去操作构造器、方法和字段。获取成员的方式要特别区分两组APIgetMethod系列只返回public成员而且会包含从父类继承来的。getDeclaredMethod系列返回当前类自己声明的所有成员不管修饰符是public还是private但不包含父类的。这个区别在实战中非常关键。比如我想调用一个私有方法用getMethod肯定找不到必须用getDeclaredMethod然后再调用setAccessible(true)。方法调用的基本写法是Method method clazz.getDeclaredMethod(doSomething, String.class); method.setAccessible(true); Object result method.invoke(instance, 参数);invoke的第一个参数是目标对象后面跟方法参数。如果这个方法是静态方法第一个参数传null即可。这里我强调一下invoke返回的类型是Object如果目标是基本类型返回的会是包装类型需要自动拆箱或者强制转换。字段访问也同样简单Field field clazz.getDeclaredField(userName); field.setAccessible(true); Object value field.get(instance); field.set(instance, 新名字);但要注意Java 9开始引入了模块系统如果你在模块化项目里反射访问私有成员光有setAccessible(true)还不够可能需要加--add-opens参数。这个我在做高版本JDK项目时踩过明明代码没问题就是报InaccessibleObjectException折腾了一阵才发现是模块封装的问题。2.3 setAccessible为什么能打破封装很多新手对setAccessible的原理很困惑为什么Java号称强封装却允许反射强行访问私有成员因为setAccessible(true)本质是在JVM层面修改了语言访问检查的开关它绕过了编译器强制的那套访问控制。这跟“封装”并不冲突——封装是面向使用者的规范而反射是给框架开发者提供的后门能力。不过要注意从JDK 17开始强封装已经成为默认策略再想在运行时广泛使用反射得显式开启。所以我说现在的Java开发者不仅要会反射API还要懂一些模块系统的规则否则高版本JDK上跑老项目会有一堆莫名其妙的反射异常。2.4 反射性能问题与优化思路反射慢这话是对的但也得分场景。它的开销主要来自三块类型安全检查、方法查找、以及invoke时的参数包装和异常处理。简单测试过一个空方法调用反射调用比直接调用慢一到两个数量级但如果方法本身耗时超过0.1毫秒这个差距就基本可以忽略。框架层面都会做缓存优化。例如Spring会缓存Method和Field对象避免每次调用都重新查找。我在自己的工具代码里也养成一个习惯把需要频繁反射调用的Method对象缓存到Map里key是方法签名value是Method对象性能提升非常明显。另一个优化思路是使用MethodHandles.Lookup它比传统反射更轻量JDK内部和很多高并发框架都在用。但MethodHandles的API抽象程度更高新手理解起来有一定门槛这个等我们基础扎实后再进阶就好。提示不要因为在循环里大量使用反射就觉得是框架垃圾。先检查自己的用法把能缓存的都缓存性能往往就够了。3. 代理机制从静态代理到JDK动态代理、CGLIB3.1 静态代理的局限静态代理指的是为每个目标类手写一个代理类两者实现同一个接口代理类持有目标对象的引用在调用目标方法前后加入额外逻辑。一个最简单的登录代理大概长这样public class UserServiceProxy implements UserService { private final UserService target; public UserServiceProxy(UserService target) { this.target target; } Override public void login(String name) { System.out.println(登录前校验); target.login(name); System.out.println(登录后记录日志); } }问题随之而来如果需要代理的类有几十个每个接口都要写一个代理类工作量爆炸并且一旦接口新增方法代理类也要同步修改。静态代理只适合单个类的简单增强完全撑不起框架级的需求。3.2 JDK动态代理的工作机制JDK动态代理解决了“一个代理类服务多个目标类”的问题。它的核心是java.lang.reflect.Proxy和InvocationHandler两个类。使用流程分四步定义接口JDK代理强制要求目标类实现接口。实现InvocationHandler在invoke方法里写增强逻辑。调用Proxy.newProxyInstance创建代理对象。用代理对象替代目标对象使用。代码示例public class LogHandler implements InvocationHandler { private final Object target; public LogHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println(方法执行前: method.getName()); Object result method.invoke(target, args); System.out.println(方法执行后: method.getName()); return result; } }创建代理对象时要传入三个参数类加载器、接口数组、处理器UserService proxyInstance (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, new LogHandler(new UserServiceImpl()) ); proxyInstance.login(admin);关键点在于Proxy.newProxyInstance真的会在运行时生成一个新的类字节码这个类实现了传入的接口并把所有方法调用转发到InvocationHandler.invoke方法。也就是说你看到的所有接口方法最终都会走同一个invoke在invoke里通过Method去区分是哪个方法被调用了。我在理解它的过程中最触动我的是这个代理类不是写在磁盘上的.java文件编译出来的而是JVM在运行时根据接口定义动态“拼”出来的字节码。所以它能保证适配任意接口哪怕这个接口是某个依赖包里刚新增的代理类也不需要提前知晓。JDK动态代理的限制也很明显——目标类必须实现接口。如果你的业务类没有接口Spring的默认策略就会切换。3.3 CGLIB怎么实现继承式代理CGLIB走的是另一条路它通过生成目标类的子类来实现代理。因为Java的类默认允许继承除非是final类CGLIB就动态生成一个子类覆盖目标方法在方法中插入增强逻辑。一个经典示例长这样Enhancer enhancer new Enhancer(); enhancer.setSuperclass(UserServiceImpl.class); enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) - { System.out.println(前置增强); Object result proxy.invokeSuper(obj, args); System.out.println(后置增强); return result; }); UserServiceImpl proxy (UserServiceImpl) enhancer.create(); proxy.login(admin);注意看MethodInterceptor的写法这里调用的不是method.invoke(target, args)而是proxy.invokeSuper(obj, args)。这两者的区别非常关键method.invoke(target)是直接调用原始目标对象的方法可能绕过代理的过程中一些增强而invokeSuper是从生成的子类角度调用父类方法保证方法调用链上的增强不会重复生效。CGLIB也有自己的限制如果目标类是final的或者方法是final的就无法代理而且CGLIB在低版本中存在对Java 17以上模块访问的限制现在Spring社区更推荐用ByteBuddy来实现类似能力但思路还是一样——生成子类。3.4 Spring AOP的代理选型逻辑Spring AOP在选择代理方式时有一个明确策略目标类实现了接口优先用JDK动态代理没有实现接口退而使用CGLIB。这个策略可以手动用spring.aop.proxy-target-classtrue强制切换但在Spring Boot 2.x之后默认就开始优先使用CGLIB了。为什么Spring Boot要改默认策略因为越来越多的业务类根本不写接口了而且CGLIB经过优化后性能差距已不明显直接坚持实现接口反而增加代码冗余。我把两种代理方式的特点整理成一张表方便你对比对比维度JDK动态代理CGLIB底层原理运行时生成接口实现类运行时生成目标类子类是否有接口要求目标必须实现接口目标不能是final类方法拦截入口InvocationHandler.invokeMethodInterceptor.intercept对final的支持接口方法天然不支持finalfinal类、final方法无法代理性能感受创建代理相对快调用时经过字节码增强优化后差距小适用场景面向接口编程的老项目没有接口的普通类这个表格背后是一个选型原则能针对接口编程就面向接口代理方式也随之自然形成如果领域模型真的不需要接口那就用CGLIB不必为用代理而强行加接口。4. 实战手写迷你IoC容器与事务代理4.1 环境准备与目标拆解理论说了那么多我建议你像我一样亲手实现一个超简化版的框架。我们的目标很小但很完整写一个注解驱动的IoC容器再通过动态代理实现一个模拟的事务拦截器。最终效果是调用一个业务方法时容器自动创建对象、自动注入依赖、自动开启“事务”方法成功后自动提交异常后自动回滚。技术栈就是纯JDK不需要任何第三方依赖。我用的JDK版本是17但代码兼容8以上的大部分版本。你直接在IDEA里新建一个普通Java工程就行这也说明反射和代理本身就是Java语言自带的威力不需要引入Spring才能拥有。我们的目录结构模拟一下真实项目src/main/java/com/demo/ annotation/ Component.java AutoWired.java Transactional.java container/ ApplicationContext.java TransactionProxy.java service/ OrderService.java UserService.java Main.java4.2 自定义三个核心注解先定义我们自己的注解让框架能识别哪些类需要被容器管理、哪些字段需要注入、哪些方法要开启事务。Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) public interface Component { String value() default ; }Target(ElementType.FIELD) Retention(RetentionPolicy.RUNTIME) public interface AutoWired { }Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface Transactional { }这里有一个很关键的细节Retention一定要设置成RetentionPolicy.RUNTIME否则注解只存在于源码阶段反射根本拿不到。我第一次写框架时就是因为没写这行导致运行时怎么都扫不到注解查了半天才发现是保留策略的问题。4.3 实现容器扫描、创建与依赖注入我们的ApplicationContext负责三件事扫描包路径下所有标注了Component的类创建实例完成字段注入。扫包这块我简化成扫描classpath下固定目录里的class文件然后把类名收集起来。public class ApplicationContext { private final MapString, Object beanMap new ConcurrentHashMap(); public ApplicationContext(String packageName) throws Exception { ListClass? classes scanPackage(packageName); for (Class? clazz : classes) { if (clazz.isAnnotationPresent(Component.class)) { String beanName clazz.getAnnotation(Component.class).value(); if (beanName.isEmpty()) { beanName lowerFirst(clazz.getSimpleName()); } Object instance clazz.getDeclaredConstructor().newInstance(); beanMap.put(beanName, instance); } } // 所有实例创建完成后统一执行依赖注入 beanMap.values().forEach(this::injectFields); } // ... 省略扫包、注入方法 }注入字段的办法就是遍历Class的getDeclaredFields找到标注了AutoWired的字段然后从beanMap中按类型取出对应对象暴力设置进去private void injectFields(Object bean) { Class? clazz bean.getClass(); Field[] fields clazz.getDeclaredFields(); for (Field field : fields) { if (field.isAnnotationPresent(AutoWired.class)) { String beanName lowerFirst(field.getType().getSimpleName()); Object dependency beanMap.get(beanName); if (dependency null) { throw new RuntimeException(找不到依赖: beanName); } field.setAccessible(true); try { field.set(bean, dependency); } catch (IllegalAccessException e) { throw new RuntimeException(依赖注入失败, e); } } } }这里使用了field.setAccessible(true)模拟了Spring设置字段可访问的过程。实际编码中会反复遇到这个点记得每次改成true都能访问私有字段。4.4 用动态代理实现事务拦截业务类中我们定义一个OrderService和UserService让UserService依赖OrderService并且在方法上标注Transactional。容器在对外提供bean的时候不能直接返回原始对象而是返回代理对象。我们的事务代理用JDK动态代理来做因此业务类必须实现接口。如果不想写接口可以把这块替换成CGLIB原理完全一致。我教案里用的就是接口模式因为可读性更好。public class TransactionProxy implements InvocationHandler { private final Object target; public TransactionProxy(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { boolean transactional method.isAnnotationPresent(Transactional.class); if (!transactional) { return method.invoke(target, args); } System.out.println(开启事务 ...); try { Object result method.invoke(target, args); System.out.println(提交事务 ...); return result; } catch (Exception e) { System.out.println(回滚事务 ...); throw e; } } }这里有个面试高频考点method.isAnnotationPresent(Transactional.class)是判断方法上是否标注了某个注解。通过反射读取方法上的注解决定要不要增强这正是AOP的实现核心之一。但有个细节必须提醒你当我们对接口方法进行代理时method对象来自JDK代理生成的方法它和实现类上的方法不是同一个Method对象所以注解可能不会被继承到代理方法上。实测下来Spring为我们处理了这个问题但自己写的时候如果想判断实现类上的方法注解可能需要从target.getClass().getMethod(...)重新获取一次。这个点我在第一次做实验时踩得很深输出结果半天都和预期不符。4.5 手动拼接流程与结果分析容器对外获取bean的方法我写成这样SuppressWarnings(unchecked) public T T getBean(ClassT clazz) { String beanName lowerFirst(clazz.getSimpleName()); Object rawBean beanMap.get(beanName); if (rawBean null) { throw new RuntimeException(bean不存在: beanName); } // 每次返回代理对象方便观察事务增强 return (T) Proxy.newProxyInstance( clazz.getClassLoader(), new Class[]{clazz}, new TransactionProxy(rawBean) ); }然后写一个主入口跑起来public class Main { public static void main(String[] args) throws Exception { ApplicationContext context new ApplicationContext(com.demo); UserService userService context.getBean(UserService.class); userService.login(admin); System.out.println(----); try { userService.buy(admin, 199); } catch (RuntimeException e) { System.out.println(捕获到异常: e.getMessage()); } } }预期输出大致如下创建容器扫描到类: OrderService, UserService 开始注入依赖: UserService - OrderService 用户登录成功: admin ---- 开启事务 ... 用户下单成功: admin 购买了 199 元商品 提交事务 ... ---- 开启事务 ... 用户下单失败商品库存不足 回滚事务 ... 捕获到异常: 库存不足看到这个结果你就能直观体会到框架做了什么业务类本身完全没有事务逻辑但通过代理我们给每个方法方法外面裹了一层事务控制。你写的业务方法里看不到一行事务代码可事务就是生效了。这就是AOP“横切关注点”的落地方式。5. 常见问题与排查技巧实录5.1 反射常见异常速查表反射过程中异常类型多我把最常见的情况整理出来异常描述可能原因解决办法ClassNotFoundException类名拼错或类不在classpath检查字符串类名和依赖包NoSuchMethodException方法名/参数类型不匹配确认方法签名注意基本类型和包装类型IllegalAccessException没有调用setAccessible(true)或模块不允许加setAccessible必要时加--add-opensInvocationTargetException目标方法本身抛了异常被反射包了一层用getCause()获取真正的异常InstantiationException目标类没有无参构造器或是抽象类/接口改用getDeclaredConstructor(...)获取指定构造器ClassCastException反射返回的Object强制转换类型错误确认实际返回类型null也要防一手这里面最容易被绕晕的是InvocationTargetException很多人反射调方法时发现异常信息莫名其妙其实是真正的异常被反射包装了。调试时一定要e.getCause()否则你永远找不到问题根源。5.2 代理对象类型转换失败JDK动态代理生成的代理对象只能转换成接口类型不能转换成目标类类型。如果你这样写UserServiceImpl proxy (UserServiceImpl) Proxy.newProxyInstance(...);必然抛ClassCastException因为生成的代理类只实现了UserService接口和UserServiceImpl没有任何继承关系。这个限制让我在早期开发时一度以为代理出了bug后来才意识到是类型系统的问题。解决办法很简单变量类型用接口声明或者用CGLIB生成子类代理。5.3 CGLIB代理对final方法的失效CGLIB通过生成子类覆盖方法子类是没法覆盖final方法的。所以实际项目中如果某个方法被标记为finalCGLIB增强会在该方法是静默失效的往往表现为加了Transactional事务却不起作用。排查这类问题时我建议优先检查方法是不是final其次是类是不是final再就是方法是不是static。这些修饰符会让代理策略失效。Spring官方也明确建议不要在Transactional方法上使用final修饰。5.4 泛型擦除导致的ClassCastException反射在获取方法参数类型时泛型信息会被擦除。比如ListString在运行期拿到的是List.class而不是String.class。如果反射代码里强制把方法返回的泛型类型转成具体类型很容易踩到ClassCastException。有一个不算广为人知的处理方式通过method.getGenericReturnType()获取ParameterizedType再从中提取真实类型参数。我在写通用工具类时用这种方式实现“反序列化带泛型的返回值”实测能拿到String这个真实类型。但从复杂度讲这已经是进阶内容了初学阶段能理解泛型擦除的概念即可。5.5 为什么总是要在调试时禁止断点进入代理类最后分享一个调试习惯我在看框架源码时只要发现断点进入了$Proxy或者CGLIB的FastClass基本不会在里面单步跟踪而是直接看调用栈的顶层和底层。代理生成的代码可读性极差不是给人看的你是来看你自己的业务逻辑和框架拦截点而非代理内部的字节码。所以调试时把“Do not step into the proxy classes”打开能省下大量时间。我对反射和代理的一点实践体会写得再多不如动手跑一遍。就我自己的经验来说把那套迷你IoC容器跑通之后再去看Spring的ClassPathBeanDefinitionScanner、AutowiredAnnotationBeanPostProcessor、TransactionInterceptor这些类会有一种相见恨晚的熟悉感。反射和代理这套知识不是孤立的它是一条通往框架底层的主干道。理解了它们你看源码不再是看天书面试时也能把“Spring怎么实现IoC、AOP”讲得有条有理。最后再提醒一句面试背概念只能过初筛真想让面试官眼前一亮你就把你手写的这个简化框架的过程讲清楚这比背一万字八股文都管用。
Java反射与动态代理：从原理到手写迷你IoC容器实战
很多朋友第一次接触Java反射和代理是在看Spring源码或者准备面试的时候。说实话我当初也是被“反射机制”、“动态代理”、“CGLIB”这一串名词搞得有点晕直到自己动手写过一个迷你版框架才真正把这些概念串起来。这篇东西我就用自己的视角把反射和代理这两块底层的机制掰开揉碎讲清楚再带着你从零写一个简化版IoC容器和事务代理让你看完直接能上手而不是停留在背概念。这篇文章适合的人群很明确正在啃Spring、MyBatis这类框架源码的开发者准备Java面试被问到“反射和代理”脑袋空白的同学以及写业务代码久了、想往底层看一眼的进阶选手。我会尽量把每一步的原理解释透告诉你为什么框架作者要这么做踩坑的地方也会单独标出来。1. 框架为什么绕不开反射和代理1.1 从IoC容器说起我们先回忆一下Spring IoC的核心行为你不用自己new对象而是告诉Spring“我要一个UserService”容器就给你一个已经注入好依赖的实例。这个过程有个关键矛盾——编译期Spring根本不知道你要什么类它只能在运行时根据字符串类名去加载、创建、装配。这个“运行时按类名创建对象并注入属性”的能力就是反射给的。你可以把它理解为一种“晚绑定”代码写在前面但具体绑到哪个类、哪个方法拖到运行那一刻才决定。我见过不少同学能背出IoC的官方定义但问他“Spring到底怎么把bean创建出来的”就卡住了。其实核心就两步骤一是扫描class文件把类名和注解信息存进一个注册表二是获取类名后用反射创建实例再用反射读取字段上的注解把依赖对象塞进去。这里面每一步都在用Class、Constructor、Field、Method这些反射API。所以不搞懂反射你看到的Spring源码就像一本加密的天书每行都在调用那些“看起来神秘”的方法但你不明白它们背后做了什么。1.2 AOP的代理基础Spring AOP能实现日志、事务、权限这些横切逻辑靠的不是在业务代码里硬编码而是悄悄给目标对象穿上一个“替身马甲”。这个替身马甲就是代理对象。代理的核心思想其实很简单调用方以为自己操作的是真实对象实际却先经过了一个替身替身在调用前后穿插了额外逻辑。静态代理就像你雇了一个贴身助理每个请求都要亲手写一个助理类动态代理则像你雇了一个万能助理一个助理类能同时服务无数个业务对象具体拦截逻辑以回调形式注入即可。但动态代理在Java里不是只有一种实现方式JDK自己带了一套第三方CGLIB又提供了另一套。Spring在用的过程中还得根据目标类是否实现接口来取舍。你光知道“动态代理”四个字不深入理解这两套机制的细节和差异面试时一追问就露馅。1.3 框架设计的本质如果非要用一句话总结框架的本质就是“把繁琐的通用逻辑抽出来让你只需要关注业务”。但通用逻辑怎么才能通用答案是你说的类我都不认识那就只能靠反射去动态发现、动态调用你想要增强逻辑而不用改业务代码那就只能靠代理去动态包装。我习惯把反射看作“元编程”的基础能力把代理看作“结构化拦截”的实现手段。两者经常配合使用框架先通过反射拿到目标类的元信息再通过代理生成一个包装后的对象最后把这个包装对象交给调用方。理解了这条链路再看任何主流框架都会有一种豁然开朗的感觉。2. 反射机制核心细节2.1 获取Class对象的三种方式与类加载时机反射的入口是Class对象获取它的方式有讲究。第一种直接通过类名获取比如UserService.class。这种方式不会触发类的静态初始化只是把已经加载好的Class对象拿过来。第二种通过实例获取比如userService.getClass()。这种方式只有在已经持有对象实例时才能用局限性很明显。第三种最常用也最能体现反射价值的方式是通过字符串类名加载Class.forName(com.demo.UserService)。重点在于forName()会触发类的初始化——也就是说静态代码块、静态变量赋值都会执行。这个差异在面试里经常被问到实际开发中也有影响比如你用forName加载JDBC驱动时就是为了触发驱动类里的静态注册逻辑。我自己在实际项目中遇到过一个小坑类不在当前classpath里forName会直接抛ClassNotFoundException。所以用反射加载类时尽量把异常处理写好别让它直接炸到上层。Class? clazz Class.forName(com.demo.UserServiceImpl); Object instance clazz.getDeclaredConstructor().newInstance();newInstance()这个方法在JDK 9之后被标记为废弃推荐用getDeclaredConstructor().newInstance()来代替。原因主要是它只能调用无参构造且异常处理不够清晰。我在写底层工具时一直用新写法更安全也更好排查问题。2.2 构造器、方法、字段的访问规则拿到Class之后接下来就是通过它去操作构造器、方法和字段。获取成员的方式要特别区分两组APIgetMethod系列只返回public成员而且会包含从父类继承来的。getDeclaredMethod系列返回当前类自己声明的所有成员不管修饰符是public还是private但不包含父类的。这个区别在实战中非常关键。比如我想调用一个私有方法用getMethod肯定找不到必须用getDeclaredMethod然后再调用setAccessible(true)。方法调用的基本写法是Method method clazz.getDeclaredMethod(doSomething, String.class); method.setAccessible(true); Object result method.invoke(instance, 参数);invoke的第一个参数是目标对象后面跟方法参数。如果这个方法是静态方法第一个参数传null即可。这里我强调一下invoke返回的类型是Object如果目标是基本类型返回的会是包装类型需要自动拆箱或者强制转换。字段访问也同样简单Field field clazz.getDeclaredField(userName); field.setAccessible(true); Object value field.get(instance); field.set(instance, 新名字);但要注意Java 9开始引入了模块系统如果你在模块化项目里反射访问私有成员光有setAccessible(true)还不够可能需要加--add-opens参数。这个我在做高版本JDK项目时踩过明明代码没问题就是报InaccessibleObjectException折腾了一阵才发现是模块封装的问题。2.3 setAccessible为什么能打破封装很多新手对setAccessible的原理很困惑为什么Java号称强封装却允许反射强行访问私有成员因为setAccessible(true)本质是在JVM层面修改了语言访问检查的开关它绕过了编译器强制的那套访问控制。这跟“封装”并不冲突——封装是面向使用者的规范而反射是给框架开发者提供的后门能力。不过要注意从JDK 17开始强封装已经成为默认策略再想在运行时广泛使用反射得显式开启。所以我说现在的Java开发者不仅要会反射API还要懂一些模块系统的规则否则高版本JDK上跑老项目会有一堆莫名其妙的反射异常。2.4 反射性能问题与优化思路反射慢这话是对的但也得分场景。它的开销主要来自三块类型安全检查、方法查找、以及invoke时的参数包装和异常处理。简单测试过一个空方法调用反射调用比直接调用慢一到两个数量级但如果方法本身耗时超过0.1毫秒这个差距就基本可以忽略。框架层面都会做缓存优化。例如Spring会缓存Method和Field对象避免每次调用都重新查找。我在自己的工具代码里也养成一个习惯把需要频繁反射调用的Method对象缓存到Map里key是方法签名value是Method对象性能提升非常明显。另一个优化思路是使用MethodHandles.Lookup它比传统反射更轻量JDK内部和很多高并发框架都在用。但MethodHandles的API抽象程度更高新手理解起来有一定门槛这个等我们基础扎实后再进阶就好。提示不要因为在循环里大量使用反射就觉得是框架垃圾。先检查自己的用法把能缓存的都缓存性能往往就够了。3. 代理机制从静态代理到JDK动态代理、CGLIB3.1 静态代理的局限静态代理指的是为每个目标类手写一个代理类两者实现同一个接口代理类持有目标对象的引用在调用目标方法前后加入额外逻辑。一个最简单的登录代理大概长这样public class UserServiceProxy implements UserService { private final UserService target; public UserServiceProxy(UserService target) { this.target target; } Override public void login(String name) { System.out.println(登录前校验); target.login(name); System.out.println(登录后记录日志); } }问题随之而来如果需要代理的类有几十个每个接口都要写一个代理类工作量爆炸并且一旦接口新增方法代理类也要同步修改。静态代理只适合单个类的简单增强完全撑不起框架级的需求。3.2 JDK动态代理的工作机制JDK动态代理解决了“一个代理类服务多个目标类”的问题。它的核心是java.lang.reflect.Proxy和InvocationHandler两个类。使用流程分四步定义接口JDK代理强制要求目标类实现接口。实现InvocationHandler在invoke方法里写增强逻辑。调用Proxy.newProxyInstance创建代理对象。用代理对象替代目标对象使用。代码示例public class LogHandler implements InvocationHandler { private final Object target; public LogHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println(方法执行前: method.getName()); Object result method.invoke(target, args); System.out.println(方法执行后: method.getName()); return result; } }创建代理对象时要传入三个参数类加载器、接口数组、处理器UserService proxyInstance (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, new LogHandler(new UserServiceImpl()) ); proxyInstance.login(admin);关键点在于Proxy.newProxyInstance真的会在运行时生成一个新的类字节码这个类实现了传入的接口并把所有方法调用转发到InvocationHandler.invoke方法。也就是说你看到的所有接口方法最终都会走同一个invoke在invoke里通过Method去区分是哪个方法被调用了。我在理解它的过程中最触动我的是这个代理类不是写在磁盘上的.java文件编译出来的而是JVM在运行时根据接口定义动态“拼”出来的字节码。所以它能保证适配任意接口哪怕这个接口是某个依赖包里刚新增的代理类也不需要提前知晓。JDK动态代理的限制也很明显——目标类必须实现接口。如果你的业务类没有接口Spring的默认策略就会切换。3.3 CGLIB怎么实现继承式代理CGLIB走的是另一条路它通过生成目标类的子类来实现代理。因为Java的类默认允许继承除非是final类CGLIB就动态生成一个子类覆盖目标方法在方法中插入增强逻辑。一个经典示例长这样Enhancer enhancer new Enhancer(); enhancer.setSuperclass(UserServiceImpl.class); enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) - { System.out.println(前置增强); Object result proxy.invokeSuper(obj, args); System.out.println(后置增强); return result; }); UserServiceImpl proxy (UserServiceImpl) enhancer.create(); proxy.login(admin);注意看MethodInterceptor的写法这里调用的不是method.invoke(target, args)而是proxy.invokeSuper(obj, args)。这两者的区别非常关键method.invoke(target)是直接调用原始目标对象的方法可能绕过代理的过程中一些增强而invokeSuper是从生成的子类角度调用父类方法保证方法调用链上的增强不会重复生效。CGLIB也有自己的限制如果目标类是final的或者方法是final的就无法代理而且CGLIB在低版本中存在对Java 17以上模块访问的限制现在Spring社区更推荐用ByteBuddy来实现类似能力但思路还是一样——生成子类。3.4 Spring AOP的代理选型逻辑Spring AOP在选择代理方式时有一个明确策略目标类实现了接口优先用JDK动态代理没有实现接口退而使用CGLIB。这个策略可以手动用spring.aop.proxy-target-classtrue强制切换但在Spring Boot 2.x之后默认就开始优先使用CGLIB了。为什么Spring Boot要改默认策略因为越来越多的业务类根本不写接口了而且CGLIB经过优化后性能差距已不明显直接坚持实现接口反而增加代码冗余。我把两种代理方式的特点整理成一张表方便你对比对比维度JDK动态代理CGLIB底层原理运行时生成接口实现类运行时生成目标类子类是否有接口要求目标必须实现接口目标不能是final类方法拦截入口InvocationHandler.invokeMethodInterceptor.intercept对final的支持接口方法天然不支持finalfinal类、final方法无法代理性能感受创建代理相对快调用时经过字节码增强优化后差距小适用场景面向接口编程的老项目没有接口的普通类这个表格背后是一个选型原则能针对接口编程就面向接口代理方式也随之自然形成如果领域模型真的不需要接口那就用CGLIB不必为用代理而强行加接口。4. 实战手写迷你IoC容器与事务代理4.1 环境准备与目标拆解理论说了那么多我建议你像我一样亲手实现一个超简化版的框架。我们的目标很小但很完整写一个注解驱动的IoC容器再通过动态代理实现一个模拟的事务拦截器。最终效果是调用一个业务方法时容器自动创建对象、自动注入依赖、自动开启“事务”方法成功后自动提交异常后自动回滚。技术栈就是纯JDK不需要任何第三方依赖。我用的JDK版本是17但代码兼容8以上的大部分版本。你直接在IDEA里新建一个普通Java工程就行这也说明反射和代理本身就是Java语言自带的威力不需要引入Spring才能拥有。我们的目录结构模拟一下真实项目src/main/java/com/demo/ annotation/ Component.java AutoWired.java Transactional.java container/ ApplicationContext.java TransactionProxy.java service/ OrderService.java UserService.java Main.java4.2 自定义三个核心注解先定义我们自己的注解让框架能识别哪些类需要被容器管理、哪些字段需要注入、哪些方法要开启事务。Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) public interface Component { String value() default ; }Target(ElementType.FIELD) Retention(RetentionPolicy.RUNTIME) public interface AutoWired { }Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface Transactional { }这里有一个很关键的细节Retention一定要设置成RetentionPolicy.RUNTIME否则注解只存在于源码阶段反射根本拿不到。我第一次写框架时就是因为没写这行导致运行时怎么都扫不到注解查了半天才发现是保留策略的问题。4.3 实现容器扫描、创建与依赖注入我们的ApplicationContext负责三件事扫描包路径下所有标注了Component的类创建实例完成字段注入。扫包这块我简化成扫描classpath下固定目录里的class文件然后把类名收集起来。public class ApplicationContext { private final MapString, Object beanMap new ConcurrentHashMap(); public ApplicationContext(String packageName) throws Exception { ListClass? classes scanPackage(packageName); for (Class? clazz : classes) { if (clazz.isAnnotationPresent(Component.class)) { String beanName clazz.getAnnotation(Component.class).value(); if (beanName.isEmpty()) { beanName lowerFirst(clazz.getSimpleName()); } Object instance clazz.getDeclaredConstructor().newInstance(); beanMap.put(beanName, instance); } } // 所有实例创建完成后统一执行依赖注入 beanMap.values().forEach(this::injectFields); } // ... 省略扫包、注入方法 }注入字段的办法就是遍历Class的getDeclaredFields找到标注了AutoWired的字段然后从beanMap中按类型取出对应对象暴力设置进去private void injectFields(Object bean) { Class? clazz bean.getClass(); Field[] fields clazz.getDeclaredFields(); for (Field field : fields) { if (field.isAnnotationPresent(AutoWired.class)) { String beanName lowerFirst(field.getType().getSimpleName()); Object dependency beanMap.get(beanName); if (dependency null) { throw new RuntimeException(找不到依赖: beanName); } field.setAccessible(true); try { field.set(bean, dependency); } catch (IllegalAccessException e) { throw new RuntimeException(依赖注入失败, e); } } } }这里使用了field.setAccessible(true)模拟了Spring设置字段可访问的过程。实际编码中会反复遇到这个点记得每次改成true都能访问私有字段。4.4 用动态代理实现事务拦截业务类中我们定义一个OrderService和UserService让UserService依赖OrderService并且在方法上标注Transactional。容器在对外提供bean的时候不能直接返回原始对象而是返回代理对象。我们的事务代理用JDK动态代理来做因此业务类必须实现接口。如果不想写接口可以把这块替换成CGLIB原理完全一致。我教案里用的就是接口模式因为可读性更好。public class TransactionProxy implements InvocationHandler { private final Object target; public TransactionProxy(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { boolean transactional method.isAnnotationPresent(Transactional.class); if (!transactional) { return method.invoke(target, args); } System.out.println(开启事务 ...); try { Object result method.invoke(target, args); System.out.println(提交事务 ...); return result; } catch (Exception e) { System.out.println(回滚事务 ...); throw e; } } }这里有个面试高频考点method.isAnnotationPresent(Transactional.class)是判断方法上是否标注了某个注解。通过反射读取方法上的注解决定要不要增强这正是AOP的实现核心之一。但有个细节必须提醒你当我们对接口方法进行代理时method对象来自JDK代理生成的方法它和实现类上的方法不是同一个Method对象所以注解可能不会被继承到代理方法上。实测下来Spring为我们处理了这个问题但自己写的时候如果想判断实现类上的方法注解可能需要从target.getClass().getMethod(...)重新获取一次。这个点我在第一次做实验时踩得很深输出结果半天都和预期不符。4.5 手动拼接流程与结果分析容器对外获取bean的方法我写成这样SuppressWarnings(unchecked) public T T getBean(ClassT clazz) { String beanName lowerFirst(clazz.getSimpleName()); Object rawBean beanMap.get(beanName); if (rawBean null) { throw new RuntimeException(bean不存在: beanName); } // 每次返回代理对象方便观察事务增强 return (T) Proxy.newProxyInstance( clazz.getClassLoader(), new Class[]{clazz}, new TransactionProxy(rawBean) ); }然后写一个主入口跑起来public class Main { public static void main(String[] args) throws Exception { ApplicationContext context new ApplicationContext(com.demo); UserService userService context.getBean(UserService.class); userService.login(admin); System.out.println(----); try { userService.buy(admin, 199); } catch (RuntimeException e) { System.out.println(捕获到异常: e.getMessage()); } } }预期输出大致如下创建容器扫描到类: OrderService, UserService 开始注入依赖: UserService - OrderService 用户登录成功: admin ---- 开启事务 ... 用户下单成功: admin 购买了 199 元商品 提交事务 ... ---- 开启事务 ... 用户下单失败商品库存不足 回滚事务 ... 捕获到异常: 库存不足看到这个结果你就能直观体会到框架做了什么业务类本身完全没有事务逻辑但通过代理我们给每个方法方法外面裹了一层事务控制。你写的业务方法里看不到一行事务代码可事务就是生效了。这就是AOP“横切关注点”的落地方式。5. 常见问题与排查技巧实录5.1 反射常见异常速查表反射过程中异常类型多我把最常见的情况整理出来异常描述可能原因解决办法ClassNotFoundException类名拼错或类不在classpath检查字符串类名和依赖包NoSuchMethodException方法名/参数类型不匹配确认方法签名注意基本类型和包装类型IllegalAccessException没有调用setAccessible(true)或模块不允许加setAccessible必要时加--add-opensInvocationTargetException目标方法本身抛了异常被反射包了一层用getCause()获取真正的异常InstantiationException目标类没有无参构造器或是抽象类/接口改用getDeclaredConstructor(...)获取指定构造器ClassCastException反射返回的Object强制转换类型错误确认实际返回类型null也要防一手这里面最容易被绕晕的是InvocationTargetException很多人反射调方法时发现异常信息莫名其妙其实是真正的异常被反射包装了。调试时一定要e.getCause()否则你永远找不到问题根源。5.2 代理对象类型转换失败JDK动态代理生成的代理对象只能转换成接口类型不能转换成目标类类型。如果你这样写UserServiceImpl proxy (UserServiceImpl) Proxy.newProxyInstance(...);必然抛ClassCastException因为生成的代理类只实现了UserService接口和UserServiceImpl没有任何继承关系。这个限制让我在早期开发时一度以为代理出了bug后来才意识到是类型系统的问题。解决办法很简单变量类型用接口声明或者用CGLIB生成子类代理。5.3 CGLIB代理对final方法的失效CGLIB通过生成子类覆盖方法子类是没法覆盖final方法的。所以实际项目中如果某个方法被标记为finalCGLIB增强会在该方法是静默失效的往往表现为加了Transactional事务却不起作用。排查这类问题时我建议优先检查方法是不是final其次是类是不是final再就是方法是不是static。这些修饰符会让代理策略失效。Spring官方也明确建议不要在Transactional方法上使用final修饰。5.4 泛型擦除导致的ClassCastException反射在获取方法参数类型时泛型信息会被擦除。比如ListString在运行期拿到的是List.class而不是String.class。如果反射代码里强制把方法返回的泛型类型转成具体类型很容易踩到ClassCastException。有一个不算广为人知的处理方式通过method.getGenericReturnType()获取ParameterizedType再从中提取真实类型参数。我在写通用工具类时用这种方式实现“反序列化带泛型的返回值”实测能拿到String这个真实类型。但从复杂度讲这已经是进阶内容了初学阶段能理解泛型擦除的概念即可。5.5 为什么总是要在调试时禁止断点进入代理类最后分享一个调试习惯我在看框架源码时只要发现断点进入了$Proxy或者CGLIB的FastClass基本不会在里面单步跟踪而是直接看调用栈的顶层和底层。代理生成的代码可读性极差不是给人看的你是来看你自己的业务逻辑和框架拦截点而非代理内部的字节码。所以调试时把“Do not step into the proxy classes”打开能省下大量时间。我对反射和代理的一点实践体会写得再多不如动手跑一遍。就我自己的经验来说把那套迷你IoC容器跑通之后再去看Spring的ClassPathBeanDefinitionScanner、AutowiredAnnotationBeanPostProcessor、TransactionInterceptor这些类会有一种相见恨晚的熟悉感。反射和代理这套知识不是孤立的它是一条通往框架底层的主干道。理解了它们你看源码不再是看天书面试时也能把“Spring怎么实现IoC、AOP”讲得有条有理。最后再提醒一句面试背概念只能过初筛真想让面试官眼前一亮你就把你手写的这个简化框架的过程讲清楚这比背一万字八股文都管用。