JDK动态代理和CGLIB代理的机制和选择

JDK动态代理和CGLIB代理的机制和选择

一、实现原理的本质区别

JDK动态代理是基于接口实现的。它利用Java反射机制，在运行时动态生成一个实现了目标接口的代理类。这个代理类实现了跟目标对象相同的接口，当调用接口方法时，会转发给InvocationHandler的invoke方法，我们在invoke方法里可以添加增强逻辑，然后再通过反射调用真实对象的方法。CGLIB代理是基于继承实现的。CGLIB的全称是Code Generation Library，它是一个强大的字节码生成库。CGLIB在运行时动态生成目标类的子类，通过覆盖父类的方法来实现增强。当调用方法时，会先执行子类（代理类）的逻辑，然后通过super调用父类（真实对象）的方法。这是最核心的区别：一个依赖接口，一个依赖继承。

二、使用前提和限制

JDK动态代理的要求：

• 必须有接口：目标类必须实现至少一个接口，否则无法使用

• 代理对象和目标对象都实现相同的接口

• 只能代理接口中定义的方法

CGLIB代理的要求：

• 不需要接口：普通类就可以代理

• 但有一些限制：

• 目标类不能是final类，因为需要生成子类

• 目标方法不能是final方法，因为子类无法覆盖final方法

• 目标方法不能是static方法，static方法属于类不属于实例，无法被子类覆盖

• 目标方法不能是private方法，private方法子类无法访问

三、性能对比

这个问题很多人有误解，我说说实际情况：早期版本（JDK 1.6及以前）：

• JDK动态代理比较慢，因为每次方法调用都要通过反射

• CGLIB快很多，因为它直接生成字节码，调用是通过FastClass机制，避免了反射

现代版本（JDK 1.8及以后）：

• JDK动态代理经过大量优化，性能已经非常接近CGLIB了

• 在某些场景下，JDK动态代理甚至比CGLIB更快

• 实际项目中，两者的性能差异基本可以忽略不计

我在实际项目中做过测试，对于普通业务场景，两者的性能差异在纳秒级别，完全不是瓶颈所在。创建代理对象的速度：

• JDK动态代理创建代理对象更快，因为逻辑相对简单

• CGLIB创建代理对象较慢，因为需要生成子类的字节码并加载

方法调用速度：

• 现代JDK版本下，两者差异很小

• CGLIB有FastClass机制，避免反射调用

• 但JDK的反射也有方法内联等优化

四、Spring中的选择策略

Spring框架对代理方式的选择有一套自动决策机制：默认策略（Spring 4.x及之前）：

• 如果目标对象实现了接口 → 使用JDK动态代理

• 如果目标对象没有实现接口 → 使用CGLIB代理

Spring Boot 2.x之后的变化：

• Spring Boot 2.x默认强制使用CGLIB代理，即使有接口也用CGLIB

• 原因是避免接口和实现类注入时的一些问题

强制指定代理方式：可以通过配置强制使用CGLIB：

• 配置文件设置：spring.aop.proxy-target-class=true

• 或者注解：@EnableAspectJAutoProxy(proxyTargetClass = true)

设置为true就强制使用CGLIB，false就是默认策略。

五、两者的优缺点对比

JDK动态代理：优点：

• JDK原生支持，不需要额外依赖

• 代理对象生成速度快

• 更符合"面向接口编程"的设计原则

缺点：

• 必须有接口，限制较大

• 只能代理接口方法，如果直接调用实现类的特有方法就代理不到

CGLIB代理：优点：

• 不需要接口，适用范围更广

• 可以代理普通类

• Spring的@Configuration类的增强就是用CGLIB

缺点：

• 需要引入额外的依赖（不过Spring已经内置了）

• 不能代理final类和final方法

• 创建代理对象稍慢一些

• 子类会继承父类的所有方法，类体积可能较大

六、实际项目中的选择建议

根据我的实践经验：推荐用CGLIB的场景：

• 开发Spring Boot应用，直接用默认配置（Spring Boot 2.x已经默认CGLIB）

• 目标类没有实现接口

• 不想因为代理问题强制定义接口

• 需要代理@Configuration配置类（必须用CGLIB）

推荐用JDK动态代理的场景：

• 已经有良好的接口设计，严格遵循面向接口编程

• 目标类是final的（虽然这种情况不多）

• 想减少对第三方库的依赖

• 明确只需要代理接口方法

我的实践建议：说实话，在现代Spring Boot项目中，我一般不会特意去选择，就用框架的默认配置（CGLIB）。原因是：

1. 性能差异可以忽略

2. CGLIB更灵活，不会因为没接口而出问题

3. Spring Boot团队选择CGLIB作为默认，说明这是经过深思熟虑的

除非有特殊需求，比如严格的架构规范要求面向接口，或者遗留项目已经是JDK代理，才会去调整。

七、常见的坑和问题

我在项目中遇到过几个相关的问题：问题1：注入类型不匹配如果用JDK动态代理，代理对象的类型是接口，不能强转成实现类。比如：

• 定义了UserService接口和UserServiceImpl实现

• JDK代理生成的代理对象类型是UserService

• 如果你用@Autowired注入UserServiceImpl类型，就会报错

这时要么改成注入接口类型，要么改用CGLIB代理。问题2：final方法无法被代理用CGLIB时，如果方法是final的，切面不会生效。我之前就遇到过一个坑：一个Service方法加了@Transactional，但方法被标记成final了，结果事务死活不生效，排查了半天才发现。问题3：private方法调用不管是JDK还是CGLIB代理，都无法代理private方法。有些同学在类内部调了private方法，发现事务或缓存注解不生效，就是这个原因。问题4：同类内部调用这是最常见的坑。类内部的方法互相调用，比如methodA调用methodB，这时调用的是this.methodB()，不是代理对象，所以切面不生效。要解决要么把方法拆到另一个Bean，要么自己注入自己（虽然不优雅），要么用AspectJ。

八、底层实现的一点补充

JDK动态代理：

• 使用Proxy.newProxyInstance创建代理对象

• 需要传入类加载器、接口数组、InvocationHandler

• 生成的代理类名字类似$Proxy0、$Proxy1这样

• 所有方法调用都会转到InvocationHandler.invoke

CGLIB代理：

• 使用Enhancer类生成子类

• 通过ASM直接操作字节码

• 使用MethodInterceptor拦截方法调用

• 生成的类名类似UserService$$EnhancerBySpringCGLIB$$12345678

• 使用FastClass机制提高调用效率，避免反射

总结

简单来说：

• JDK动态代理：基于接口、使用反射、JDK原生、有接口才能用

• CGLIB代理：基于继承、生成字节码、功能更强、不能代理final

选择建议：

• Spring Boot 2.x项目：用默认的CGLIB就好

• 有良好接口设计的项目：JDK动态代理也完全够用

• 性能不是选择的主要因素，两者差异可以忽略

• 关键是理解限制：final类/方法、内部调用等问题

在实际工作中，我们更应该关注的是如何正确使用AOP，避免常见的坑，而不是纠结用哪种代理方式。毕竟Spring已经帮我们做了最优选择。