代理机制及其特点

　　首先让我们来了解一下如何使用Java动态代理。具体有如下四步骤：

　　1.通过实现InvocationHandler接口创建自己的调用处理器;

　　2.通过为Proxy类指定ClassLoader对象和一组interface来创建动态代理类;

　　3.通过反射机制获得动态代理类的构造函数，其唯一参数类型是调用处理器接口类型;

　　4.通过构造函数创建动态代理类实例，构造时调用处理器对象作为参数被传入。

　　实际使用过程更加简单，因为Proxy的静态方法newProxyInstance已经为我们封装了步骤2到步骤4的过程，所以简化后的过程如下：

　　接下来让我们来了解一下Java动态代理机制的一些特点。首先是动态生成的代理类本身的一些特点。

　　1)包：如果所代理的接口都是public的，那么它将被定义在顶层包(即包路径为空)，如果所代理的接口中有非public的接口(因为接口不能被定义为protect或private，所以除public之外就是默认的package访问级别)，那么它将被定义在该接口所在包(假设代理了com.ibm.developerworks包中的某非public接口A，那么新生成的代理类所在的包就是com.ibm.developerworks)，这样设计的目的是为了最大程度的保证动态代理类不会因为包管理的问题而无法被成功定义并访问;

　　2)类修饰符：该代理类具有final和public修饰符，意味着它可以被所有的类访问，但是不能被再度继承;

　　3)类名：格式是“$ProxyN”，其中N是一个逐一递增的阿拉伯数字，代表Proxy类第N次生成的动态代理类，值得注意的一点是，并不是每次调用Proxy的静态方法创建动态代理类都会使得N值增加，原因是如果对同一组接口(包括接口排列的顺序相同)试图重复创建动态代理类，它会很聪明地返回先前已经创建好的代理类的类对象，而不会再尝试去创建一个全新的代理类，这样可以节省不必要的代码重复生成，提高了代理类的创建效率。

　　4)类继承关系：该类的继承关系如图：

　　由图可见，Proxy类是它的父类，这个规则适用于所有由Proxy创建的动态代理类。而且该类还实现了其所代理的一组接口，这就是为什么它能够被安全地类型转换到其所代理的某接口的根本原因。

　　接下来让我们了解一下代理类实例的一些特点。每个实例都会关联一个调用处理器对象，可以通过Proxy提供的静态方法getInvocationHandler去获得代理类实例的调用处理器对象。

　　在代理类实例上调用其代理的接口中所声明的方法时，这些方法最终都会由调用处理器的invoke方法执行，此外，值得注意的是，代理类的根类java.lang.Object中有三个方法也同样会被分派到调用处理器的invoke方法执行，它们是hashCode，equals和toString，可能的原因有：一是因为这些方法为public且非final类型，能够被代理类覆盖;二是因为这些方法往往呈现出一个类的某种特征属性，具有一定的区分度，所以为了保证代理类与委托类对外的一致性，这三个方法也应该被分派到委托类执行。

　　当代理的一组接口有重复声明的方法且该方法被调用时，代理类总是从排在最前面的接口中获取方法对象并分派给调用处理器，而无论代理类实例是否正在以该接口(或继承于该接口的某子接口)的形式被外部引用，因为在代理类内部无法区分其当前的被引用类型。

　　接着来了解一下被代理的一组接口有哪些特点。首先，要注意不能有重复的接口，以避免动态代理类代码生成时的编译错误。其次，这些接口对于类装载器必须可见，否则类装载器将无法链接它们，将会导致类定义失败。再次，需被代理的所有非public的接口必须在同一个包中，否则代理类生成也会失败。最后，接口的数目不能超过65535，这是JVM设定的限制。

　　最后再来了解一下异常处理方面的特点。从调用处理器接口声明的方法中可以看到理论上它能够抛出任何类型的异常，因为所有的异常都继承于Throwable接口，但事实是否如此呢?答案是否定的，原因是我们必须遵守一个继承原则：即子类覆盖父类或实现父接口的方法时，抛出的异常必须在原方法支持的异常列表之内。所以虽然调用处理器理论上讲能够，但实际上往往受限制，除非父接口中的方法支持抛Throwable异常。

　　那么如果在invoke方法中的确产生了接口方法声明中不支持的异常，那将如何呢?放心，Java动态代理类已经为我们设计好了解决方法：它将会抛出UndeclaredThrowableException异常。这个异常是一个RuntimeException类型，所以不会引起编译错误。通过该异常的getCause方法，还可以获得原来那个不受支持的异常对象，以便于错误诊断。