Java实现代理模式
Java实现代理模式
1、代理模式
代理模式是一种比较好理解的设计模式。简单来说就是 我们使用代理对象来代替对真实对象(real object)的访问,这样就可以在不修改原目标对象的前提下,提供额外的功能操作,扩展目标对象的功能。
代理模式的主要作用是扩展目标对象的功能,比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。
代理模式有静态代理和动态代理两种实现方式。
2、静态代理
静态代理中,我们对目标对象的每个方法的增强都是手动完成的(后面会具体演示代码),非常不灵活(比如接口一旦新增加方法,目标对象和代理对象都要进行修改)且麻烦(需要对每个目标类都单独写一个代理类)。 实际应用场景非常非常少,日常开发几乎看不到使用静态代理的场景。
上面我们是从实现和应用角度来说的静态代理,从 JVM 层面来说, 静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。
下面通过代码展示! 1 **. ** 定义发送短信的接口
1 | public interface SmsService { |
2 **. ** 实现发送短信的接口
1 | public class SmsServiceImpl implements SmsService { |
3 **. ** 创建代理类并同样实现发送短信的接口
1 | public class SmsProxy implements SmsService { |
4 **. ** 实际使用
1 | public class 静态代理和动态代理 { |
5.执行结果:
1 | 静态代理 before method send() |
3、动态代理
相比于静态代理来说,动态代理更加灵活。我们不需要针对每个目标类都单独创建一个代理类,并且也不需要我们必须实现接口,我们可以直接代理实现类(CGLIB动态代理机制)。
从 JVM 角度来说,动态代理是在运行时动态生成类字节码,并加载到 JVM 中的。
说到动态代理,Spring AOP、RPC 框架应该是两个不得不提的,它们的实现都依赖了动态代理。
动态代理在我们日常开发中使用的相对较少,但是在框架中的几乎是必用的一门技术。学会了动态代理之后,对于我们理解和学习各种框架的原理也非常有帮助。
就 Java 来说,动态代理的实现方式有很多种,比如 JDK 动态代理、CGLIB 动态代理等等。
guide-rpc-framework使用的是 JDK 动态代理,我们先来看看 JDK 动态代理的使用。
另外,虽然 guide-rpc-framework 没有用到 CGLIB 动态代理 ,我们这里还是简单介绍一下其使用以及和JDK 动态代理的对比。
3.1 JDK 动态代理机制
3.1.1 介绍
在 Java 动态代理机制中 *InvocationHandler*
接口和 Proxy 类是核心。
Proxy 类中使用频率最高的方法是:newProxyInstance() ,这个方法主要用来生成一个代理对象。
1 | public static Object newProxyInstance(ClassLoader loader, |
这个方法一共有 3 个参数:
- **loader:**类加载器,用于加载代理对象。
- **interfaces:**被代理类实现的一些接口;
- **h:**实现了
InvocationHandler
接口的对象;
要实现动态代理的话,还必须需要实现InvocationHandler 来自定义处理逻辑。 当我们的动态代理对象调用一个方法时,这个方法的调用就会被转发到实现InvocationHandler 接口类的 invoke 方法来调用。
1 | public interface InvocationHandler { |
invoke()
方法有下面三个参数:
- **proxy:**动态生成的代理类
- **methoh:**与代理类对象调用的方法相对应
- **args:**当前 method 方法的参数
也就是说:你通过Proxy 类的 newProxyInstance() 创建的代理对象在调用方法的时候,实际会调用到实现InvocationHandler 接口的类的 invoke()方法。 你可以在 invoke() 方法中自定义处理逻辑,比如在方法执行前后做什么事情。
3.1.2 JDK 动态代理类使用步骤
定义一个接口及其实现类; 自定义 InvocationHandler 并重写invoke方法,在 invoke 方法中我们会调用原生方法(被代理类的方法)并自定义一些处理逻辑; 通过 Proxy.newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h) 方法创建代理对象;
3.1.2 代码示例
- 定义发送短信的接口
1 | public interface SmsService { |
- 实现发送短信的接口
1 | public class SmsServiceImpl implements SmsService { |
- 定义一个JDK动态代理类
1 | public class DebugInvocationHandler implements InvocationHandler { |
- 获取代理对象的工厂类
1 | public class JdkProxyFactory { |
- 实际使用
1 | public class 静态代理和动态代理 { |
- 执行结果:
1 | JDK动态代理 before method send |
3.2. CGLIB 动态代理机制
3.2.1. 介绍
JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。为了解决这个问题,我们可以用 CGLIB 动态代理机制来避免。
CGLIB(Code Generation Library)是一个基于ASM的字节码生成库,它允许我们在运行时对字节码进行修改和动态生成。CGLIB 通过继承方式实现代理。很多知名的开源框架都使用到了CGLIB, 例如 Spring 中的 AOP 模块中:如果目标对象实现了接口,则默认采用 JDK 动态代理,否则采用 CGLIB 动态代理。
在 CGLIB 动态代理机制中 MethodInterceptor 接口和 Enhancer 类是核心。
你需要自定义 MethodInterceptor 并重写 intercept 方法,intercept 用于拦截增强被代理类的方法。
1 | public interface MethodInterceptor |
- **obj:**被代理的对象(需要增强的对象)
- **method:**被拦截的方法(需要增强的方法)
- **args:**方法入参
- **proxy:**用于调用原始方法
你可以通过 Enhancer类来动态获取被代理类,当代理类调用方法的时候,实际调用的是 MethodInterceptor 中的 intercept 方法。
3.2.2. CGLIB 动态代理类使用步骤
- 定义一个类;
- 自定义
MethodInterceptor
并重写intercept
方法,intercept
用于拦截增强被代理类的方法,和 JDK 动态代理中的invoke
方法类似; - 通过
Enhancer
类的create()
创建代理类;
3.2.3. 代码示例
不同于 JDK 动态代理不需要额外的依赖。CGLIB(Code Generation Library) 实际是属于一个开源项目,如果你要使用它的话,需要手动添加相关依赖。
1 | <dependency> |
- 实现一个使用阿里云发送短信的类
1 | public class AliSmsService { |
- 自定义 MethodInterceptor(方法拦截器)
1 | public class DebugMethodInterceptor implements MethodInterceptor { |
- 获取代理类
1 | public class CglibProxyFactory { |
实际使用
1
2
3
4
5
6public class 静态代理和动态代理 {
public static void main(String[] args) {
AliSmsService aliSmsService = (AliSmsService) CglibProxyFactory.getProxy(AliSmsService.class);
aliSmsService.send("java");
}
}执行结果:
1 | before method send |
3.3. JDK动态代理和CGLIB动态代理对比
- JDK 动态代理只能代理实现了接口的类或者直接代理接口,而 CGLIB 可以代理未实现任何接口的类。 另外, CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用,因此不能代理声明为 final 类型的类和方法。
- 就二者的效率来说,大部分情况都是 JDK 动态代理更优秀,随着 JDK 版本的升级,这个优势更加明显。
4、静态代理和动态代理的对比
- 灵活性:动态代理更加灵活,不需要必须实现接口,可以直接代理实现类,并且可以不需要针对每个目标类都创建一个代理类。另外,静态代理中,接口一旦新增加方法,目标对象和代理对象都要进行修改,这是非常麻烦的!
- JVM 层面:静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的class文件。而动态代理是在运行时动态生成类字节码,并加载到 JVM 中的。