前言
非常重要的一个设计模式,也很常见,很多框架都有它的影子。定义就不多说了。两点:
1、为其它对象提供一个代理服务,间接控制对这个对象的访问,联想 Spring 事务机制,在合适的方法上加个 transaction 注解,就分分钟实现了事务。
2、除了1,代理对象还能充当中介的角色。
为什么要有代理模式?
如果希望不给原有对象附加太多的责任(和本对象无关的冗余代码),但是还想能为其实现新功能,那么代理模式就是做这个的。还是联系 Spring 事务机制,很好的应用场景。
实际生活里,可以联系租房,大家租房一般都会找中介,这个中介就是代理对象的角色,它解耦(分离)了房东的一部分责任,因为房东太忙了,或者房东不屑于做这些事情,故交给代理对象去做。
一句话:解耦合,提高扩展性
静态代理模式
顾名思义,代理类被显示的指定了,即代理在代码里被写死了。实现最简单,也很少用,但是能帮助快速理解思想
public interface StaticProxy { void dosth(); }//////////////接下来是很熟悉的做法,实现这个借口public class RealRole implements StaticProxy { @Override public void dosth() { System.out.println("do sth"); } }///////////然后重要的角色——代理类,联系 Spring 事务机制public class ProxyRole implements StaticProxy { private StaticProxy staticProxy; public ProxyRole() { this.staticProxy = new RealRole(); } @Override public void dosth() { // 真正业务逻辑之前的处理,比如加上事务控制 before(); this.staticProxy.dosth(); // 真正的业务逻辑处理,比如数据库的 crud after(); // 善后处理,比如,事务提交 } private void after() { System.out.println("after dosth"); } private void before() { System.out.println("before dosth"); } }////////执行public class ProxyMain { public static void main(String[] args) { StaticProxy staticProxy = new ProxyRole(); staticProxy.dosth(); } }
打印==============
before dosth
do sth
after dosth
如上就是最简单的静态代理模式的实现,很直观,就是使用委托的思想,把责任转移到被代理的对象上,代理类实现非业务相关的功能
缺陷
静态代理非常简单,但是它的缺陷也是显然的,因为静态代理的代理关系在 IDE 编译时就确定了,如果接口改变了,不仅实现类要改变,代理类也要改变,代理类和接口之间的耦合非常严重。
动态代理模式
和静态代理相反,代理类不是写死的,而是动态的创建。又分为两种实现方案:
基于 JDK实现
也很简单,就是利用 Java 的 API 来实现代理类,即我们不用自己写代理类了,也就是上面例子里的类——ProxyRole。到这里,其实也能猜出来,本质就是利用 Java 的反射机制在程序运行期动态的创建接口的实现类,并生产代理对象而已,如此一来,就能避免实现的接口——StaticProxy 改变了,导致代理类也跟着变的场景发生。下面看实现代码:
首先写好需要实现的接口,和具体实现类
public interface DynamicProxy { void dosth(); }////////////public class DynamicRealRole implements DynamicProxy { @Override public void dosth() { System.out.println("do sth"); } }
然后,要实现 JDK 的一个接口——InvocationHandler,Java 的动态代理机制中,有两个重要的类,一个是 InvocationHandler 接口,一个是 Proxy 类。
注意,DynamicProxyRole 不是代理类,代理类我们不需要自己写,它是 JDK 动态生成给我们的(反射机制)
public class DynamicProxyRole implements InvocationHandler { private Object object; // 被代理的对象 public DynamicProxyRole(Object object) { // 构造注入 this.object = object; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { before(); Object ret = method.invoke(object, args); after(); return ret; } private void after() { System.out.println("after dosth"); } private void before() { System.out.println("before dosth"); } }
InvocationHandler 接口只有一个方法 —— invoke,参数也很好理解,分别是:
proxy:代理的真实对象,也就是实现类的对象
method:要调用真实对象的某个方法的Method对象,也就是会调用 dosth 的方法的对象
args:调用真实对象某个方法时接受的参数,没有就是空数组
最后写运行类
public class DynamicMain { private static DynamicProxy realRole = new DynamicRealRole(); // 被代理的类,也就是实现类 private static DynamicProxyRole dynamicProxyRole = new DynamicProxyRole(realRole); public static void main(String[] args) { // 通过JDK动态代理获取被代理对象(实现类的对象)的代理对象,该代理类实现了指定的需要去代理的接口,也就是第2个参数 DynamicProxy dynamicProxyObj = (DynamicProxy) Proxy.newProxyInstance( realRole.getClass().getClassLoader(), // 被代理的类的加载器 realRole.getClass().getInterfaces(), // 被代理的类需要实现的接口,可以有多个 dynamicProxyRole // 必须是实现了 InvocationHandler 接口的类,invoke 方法里写业务逻辑和代理方法 ); dynamicProxyObj.dosth(); } }
Proxy 类的作用是动态创建一个代理对象,也就是代理对象不需要我们自己写。Proxy 提供了许多的方法,用的最多的是 newProxyInstance,注释里也写了:
其中第一个参数是被代理的类的加载器,传入的目的是告诉 JDK 由哪个类加载器对生成的代理进行加载。其实就是真实的类(实现类)的对象的加载器。
第二个参数是代理类需要实现的接口,可以多个。其实就是接口 DynamicProxy,很好理解,在静态代理模式中,我们就需要手动实现这个接口,来实现代理类。
第三个参数就是实现了InvocationHandler接口的类即可,原因是此类里有 invoke 方法,而通过 Proxy 的 newProxyInstance 方法生成的代理类去调用接口方法(dosth)时,对方法(dosth)的调用会自动委托给 InvocationHandler 接口的 invoke 方法,这样也就实现了代理模式。
综上,代理对象就实现了在程序运行时产生。进一步要知道,所有的 JDK 动态代理都会继承 java.lang.reflect.Proxy,同时还会实现我们指定的接口(Proxy 的 newProxyInstance 第二个参数里的接口)。
看到这里,也确定,JDK 动态代理核心就是反射思想的应用,没什么新鲜的东西。
缺陷
JDK 动态代理这种方式只能代理接口,这是其缺陷
基于 CGLib 实现
Java动态代理是基于接口实现的,如果对象没有实现接口,那么可以用 CGLIB 类库实现,它的原理是基于继承实现代理类。代码也不难
首先,写一个类,其没有实现接口,此时前面的 JDK 动态代理就无法使用了。
public class NoInterfaceReal { public void dosth() { System.out.println("do sth"); } }
其次,需要实现CGLIB 类库提供的接口——MethodInterceptor
在这之前,先下载CGLib 包
<!-- https://mvnrepository.com/artifact/cglib/cglib --> <dependency> <groupId>cglib</groupId> <artifactId>cglib</artifactId> <version>3.2.10</version> </dependency>
然后实现其提供的接口——MethodInterceptor,关键方法是 intercept
public class CGLibProxy implements MethodInterceptor { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { before(); Object ret = proxy.invokeSuper(obj, args); after(); return ret; } private void after() { System.out.println("after dosth"); } private void before() { System.out.println("before dosth"); } }
实现了 MethodInterceptor 接口后,后续生成的代理对象对 dosth 方法的调用会被转发到 intercept 方法,自然也就实现了代理模式。
最后,通过 CGLIB 动态代理生成代理对象,就完成了代理模式,非常简单
public class CGLibMain { public static void main(String[] args) { CGLibProxy cgLibProxy = new CGLibProxy(); NoInterfaceReal proxy = (NoInterfaceReal) Enhancer.create(NoInterfaceReal.class, cgLibProxy); proxy.dosth(); } }
通过CGLib 的Enhancer类 create 了一个代理对象,参数传入需要被代理的类(可以不是接口),和实现了 MethodInterceptor 接口的类的对象即可。CGLib 就会为我们自动生成继承了被代理的类的代理对象,通过代理对象调用 dosth 方法,其调用会被委托给第二个参数里的 intercept 方法。
综上得知:
1、CGLib 底层是利用 asm 字节码框架实现的,该框架可以在 Java 程序运行时对字节码进行修改和动态生成,故它可以代理普通类,具体细节是通过继承和重写需要被代理的类(NoInterfaceReal)来实现。
2、CGLib 可以实现对方法的代理,即可以实现拦截(只代理)某个方法。
3、通过CGLib 的 Enhancer 类来create 代理对象。而对这个对象所有非final方法的调用都会委托给 MethodInterceptor 接口的 intercept,我们可以在该方法内部写拦截代码,最后在通过调用MethodProxy 对象的 invokeSuper() 方法,把调用转发给真实对象
缺陷
无法对 final 类、或者 final 方法进行代理
代理模式的性能对比
直接搬运结论:CGLib 底层基于asm 框架实现,比 Java 反射性能好,但是比 JDK 动态代理稍微慢一些
代理模式的缺点
主要是性能问题,什么增加系统复杂度等都不是事儿。同等条件,用代理,肯定比不用代理要慢一些。
代理模式和装饰器模式对比
实现方式上很像,但是目标不一样,后者是为了给类(对象)增加新的功能,不改变API,前者除了这些作用,目标主要是为了使用中间人(代理角色)给本类(对象)减少负担。
代理模式的应用
非常常见了,AOP非常典型,还有各种框架的拦截器机制,数据库切换等工具。。。
" cdata_tag="style">
作者:dashuai的博客