设计模式之代理模式
本篇是设计模式系列的第二篇,上一篇单例模式见这里;
首先我们都知道代理也分为静态代理和动态代理。虽然现在像spring这样成熟的框架会有自己的实现方式,开箱即用,我们不用自己实现代理,但是对于深入了解学习还是很有必要的。不管是静态代理还是动态代理,两种代理从虚拟机加载类的角度来讲,本质上都是一样的,都是在原有类的行为基础上,加入一些多出的行为,甚至完全替换原有的行为。
一 静态代理
静态代理采用的方式就是我们手动的将这些行为换进去,然后让编译器帮我们编译,同时也就将字节码在原有类的基础上加入一些其他的东西或者替换原有的东西,产生一个新的与原有类接口相同但是行为却不同的类型。
下面做个比较常见得数据库连接池的例子,实际体会下这种方式的代理。
我们都知道,数据库连接是很珍贵的资源,频繁的开关数据库连接是非常浪费服务器的CPU资源以及内存的,所以我们一般都是使用数据库连接池来解决这一问题,即创造一堆等待被使用的连接,等到用的时候就从池里取一个,不用了再放回去,数据库连接在整个应用启动期间,几乎是不关闭的,除非是超过了最大闲置时间。
解决这一问题的办法就是使用代理模式,因为代理模式可以替代原有类的行为,所以我们要做的就是替换掉connection的close行为。
1 | public class ConnectionProxy implements Connection { |
首先实现原来的Connection接口,因为接口比较多,这里就简单实例下,其他的不变。实际情况中根据自己的需要重写接口。
1 | public class DatasourcePool { |
好了,这下我们的连接池返回的连接全是代理,就算程序员调用了close方法也只会归还给连接池了。
我们使用代理模式解决了上述问题,从静态代理的使用上来看,我们一般是这么做的。
1. 代理类一般要持有一个被代理的对象的引用。
2. 对于我们不关心的方法,全部委托给被代理的对象处理。
3. 自己处理我们关心的方法。
这种代理是死的,不会在运行时动态创建,因为我们相当于在编译期,也就是你在本地编辑完代码后,就给被代理的对象生成了一个不可动态改变的代理类。
静态代理对于这种,被代理的对象很固定,我们只需要去代理一个类或者若干固定的类,数量不是太多的时候,可以使用,而且其实效果比动态代理更好,因为动态代理就是在运行期间动态生成代理类,所以需要消耗的时间会更久一点。就像上述的情况,其实就比较适合使用静态代理。
下面介绍下动态代理,动态代理是JDK自带的功能,它需要你去实现一个InvocationHandler接口,并且调用Proxy的静态方法去产生代理类。
接下来我们依然使用上面的示例,但是这次该用动态代理处理,我们来试一下看如何做。
二 动态代理
1 | public class ConnetionDymicProxy implements InvocationHandler { |
上面是我们针对connection写的动态代理,InvocationHandler接口只有一个invoke方法需要实现,这个方法是用来在生成的代理类用回调使用的,关于动态代理的原理一会做详细的分析,这里我们先只关注用法。很显然,动态代理是将每个方法的具体执行过程交给了我们在invoke方法里处理。而具体的使用方法,我们只需要创造一个ConnectionProxy的实例,并且将调用getConnectionProxy方法的返回结果作为数据库连接池返回的连接就可以了。
上述便是我们针对connection做动态代理的方式,但是我们从中得不到任何好处,除了能少写点代码以外,因为这个动态代理还是只能代理Connection这一个接口,如果我们写出这种动态代理的方式的话,说明我们应该使用静态代理处理这个问题,因为它代表我们其实只希望代理一个类就好。从重构的角度来说,其实更简单点,那就是在你发现你使用静态代理的时候,需要写一大堆重复代码的时候,就请改用动态代理试试吧。
通常情况下,动态代理的使用是为了解决这样一种问题,就是我们需要代理一系列类的某一些方法,最典型的应用就是我们前段时间讨论过的springAOP,我们需要创造出一批代理类,切入到一系列类当中的某一些方法中。下面给出一个经常使用的动态代理方式。
1 | public class DynamicProxy implements InvocationHandler{ |
上述我做了一些注释,其实已经说明一些问题,这个代理类的作用是可以代理任何类,因为它被传入的对象是Object,而不再是具体的类,比如刚才的Connection,这些产生的代理类在调用toString方法时会被插入before方法和after方法。
动态代理有一个强制性要求,就是被代理的类必须实现了某一个接口,或者本身就是接口,就像我们的Connection。
道理其实很简单,这是因为动态代理生成的代理类是继承Proxy类的,并且会实现被你传入newProxyInstance方法的所有接口,所以我们可以将生成的代理强转为任意一个代理的接口或者Proxy去使用,但是Proxy里面几乎全是静态方法,没有实例方法,所以转换成Proxy意义不大,几乎没什么用。假设我们的类没有实现任何接口,那么就意味着你只能将生成的代理类转换成Proxy,那么就算生成了,其实也没什么用,而且就算你传入了接口,可以强转,你也用不了这个没有实现你传入接口的这个类的方法。
你可能会说,假设有个接口A,那我将接口A传给newProxyInstance方法,并代理一个没实现接口A的类B,但类B与接口A有一样的方法可以吗?
答案是可以的,并且JDK的动态代理只认你传入的接口,只要你传入,你就可以强转成这个接口,这个一会解释,但是你无法在invoke方法里调用method.invoke方法,也就是说,你只能全部替换A接口的方法,而不能使用类B中原有与接口A方法描述相同的方法,这是因为invoke中传入的Method的class信息是接口A,而类B因为没实现接口A,所以无法执行传入的Method,会抛出非法参数异常。
下面我贴出测试代码,各位可以自己试一下,具体为何会这样是在后面解释的,这里不再多做解释。
1 | public interface TestInterface { |
这就与你实现接口的表现行为一致了,但是我们本来就只需要一句method.invoke就可以了,就因为没实现接口就要多写两行,所以这种突破JDK动态代理必须实现接口的行为就有点画蛇添足了。因为你本来就实现了该接口的方法,只是差了那一句implements而已。
好了,从现在开始,我们开始详细讲解动态代理的原理,这算是进阶篇:
接下来我们结合源码去看一下,代理类是如何产生的,首先当然就是要进入Proxy的newProxyInstance方法,这里是产生代理的入口,源码如下。
1 | public static Object newProxyInstance(ClassLoader loader, |
这个方法其实很简单,首先获取了代理类的运行时Class引用,然后调用了这个Class中的构造方法,这个构造方法只有一个参数,正是InvocationHandler接口,由此产生了一个代理类的实例。那么关键的地方就在于如何获取的代理类运行时的class信息的呢?我们进入getProxyClass方法看一下。为了方便起见,我直接加注释,这个方法需要解释的地方比较多。
1 | public static Class<?> getProxyClass(ClassLoader loader, |
上面基本上已经解释的很清楚了,下面就是去看一下byte[] proxyClassFile =ProxyGenerator.generateProxyClass(proxyName, interfaces)这句话是如何处理的,也就是如何得到的代理类的class文件的,我们进去源码看一下,我依然会加上注释。
1 | public static byte[] generateProxyClass(String paramString, Class[] paramArrayOfClass) { |
我们继续跟踪到localProxyGenerator.generateClassFile()这一句当中,依然会加上注释。
1 | private byte[] generateClassFile() { |
其实代理类的class文件并不复杂,还是有很多规律可循的,所以上述过程基本上可以让各位了解下JDK动态代理生成代理类时都生成了什么东西。
下面我们可以调用下JDK中生成Class文件的方法,并且写入到本地文件,然后使用反编译工具来看一下生成的代理类到底是什么样子的。下面是生成文件的测试类。我们暂且将生成的类名写成TestProxy,代理的接口就是我们上面的TestInterface。如下。
1 | public class CreateClassTest { |
生成后,我们反编译过来会是如下格式的JAVA文件。我加入了注释,大致说明了下文件中生成的部分与刚才分析的时候写入的过程的对应关系。
1 | //public final的,继承Proxy,实现你传入的接口 |
看到这里就知道invoke方法是干嘛的了,其实就是生成的代理类对每一个方法的处理就是回调invoke方法。从生成的代理类源文件中也可以发现,每一个Method除了hashCode,toString和equals外,都是与所属的接口绑定的,所以这也就解释了为什么我们不实现这个接口,只传入进入的话,不能直接使用method.invoke,而是要转成source对应的method才可以调用。
好了,代理模式就分析到这里了,这里讲的更多的是代理模式的原理,对于如何使用并没有讲述太多,是因为代理模式在平时工作中用的虽然很多,但我们大多是使用的现成的,原因很简单,就是因为spring的AOP已经给我们弄了一个很好的动态代理的框架,所以我们几乎不需要自己去写,只要明白其原理,知道动态代理和静态代理主要处理的问题是那种的,知道在何处用,也能够用起来得心应手就可以了。