封面 :洛小汐
做者 :潘潘html
事实上,对于不少Java编程人员来讲,可能只须要达到从入门到上手的编程水准,就能很好的完成大部分研发工做。除非本身强主动获取,或者工做倒逼你学习,不然咱们好像不必去真正了解Java编程,或者深刻研究JDK运行原理、或者在实际工做中某个模块写一套设计模式、或者纠结一个线程安全问题。java
我以为彻底不必了解,由于不少知识内容,我技术储备上仅仅点到为止,就能胜任工做,何须深刻?确实,我也和有些朋友同样,8年编程生涯以来大部分时候都存在这种思想,直到某一天忽然有机会来了,你就要负责某个系统的架构规划设计、你就要全权保障整个企业的信息化安全、你就要管理底下几十上百号研发兄弟,但你知道你只擅长if/else,你清楚的知道你写过一个下单方法有9000行代码,你刚刚接到一个运维同事的电话,说你某个SQL执行后CPU飙到100%...git
对,这就是你我如今或将来,都终将会面临同时躲不过的问题,因此我想寻思着要不就来一个 「一文读懂」 系列,咱们深刻浅出,跟你们一块研究学习,从Java基础到核心,从单体框架到微服务集群,从数据库到服务器,咱们都一块儿分享,同步成长,Java之路,应不忘初心,终生学习。github
因而,有了咱们第一话 「Java动态代理」 。数据库
最先的代理模式,咱们大体能够联想到三国时期,孟德君挟天子以令诸侯是代理模式,是权利代理;现此生活中相似房产中介、票务中介是代理模式,是业务代理;还有***浏览网页是代理模式,是***代理;回到咱们编程世界里呢,之前你用的远程方法调用(RMI)是代理、企业JavaBeans(EJB)是代理,如今流行的众多RPC框架(如dubbo)也是代理,包括咱们的Java动态代理,他们都是对象代理。编程
Java 动态代理机制的出现,使得 Java 开发人员不用手工编写代理类,只要简单地指定一组接口及委托类对象,便能动态地得到代理类。代理类会负责将全部的方法调用分派到委托对象上反射执行,在分派执行的过程当中,开发人员还能够按需调整委托类对象及其功能,这是一套很是灵活有弹性的代理框架。设计模式
代理是一种常见的设计模式,其目的就是为 ”调用方“ 提供一个代理类以控制对 ”被调用方“ 的访问。代理类负责为委托类预处理消息,过滤消息并转发消息,以及进行消息被委托类执行后的后续处理。数组
能够发现,代理类与委托类,实现了同一个接口,因此对于客户端请求来讲没有丝毫的区别,这也是Java面向接口编程的特色。代理模式使用代理对象(代理类)完成用户请求,有效的屏蔽了用户对真实对象(委托类)的访问,也能够很好地隐藏和保护委托类对象。同时也为添加不一样控制策略争取了空间,从而在设计上得到了更大的灵活性。Java 动态代理机制以巧妙的方式近乎完美地实践了代理模式的设计理念。缓存
正如现实世界的代理人被受权执行当事人的一些事宜,无需当事人出面,从第三方的角度看,彷佛当事人并不存在,由于他只和代理人通讯。而事实上代理人是要有当事人的受权,而且在核心问题上还须要请示当事人,同时代理人除了转发完成当事人的受权事宜以外,还能够在执行受权事宜先后增长额外的一些事务。安全
代理对象 = 目标对象 + 加强事务
要了解 Java 动态代理的机制,首先须要了解两个相关的类或接口:
// 方法 1: 该方法用于获取指定代理对象所关联的调用处理器 static InvocationHandler getInvocationHandler(Object proxy) // 方法 2:该方法用于获取关联于指定类装载器和一组接口的动态代理类的类对象 static Class getProxyClass( ClassLoader loader, Class[] interfaces) // 方法 3:该方法用于判断指定类对象是不是一个动态代理类 static boolean isProxyClass(Class cl) // 方法 4:该方法用于为指定类装载器、一组接口及调用处理器生成动态代理类实例 static Object newProxyInstance( ClassLoader loader, Class[] interfaces, InvocationHandler h)
// 该方法负责集中处理动态代理类上的全部方法调用。 // 第一个参数既是代理类实例, // 第二个参数是被调用的方法对象 // 第三个方法是调用参数。 // 调用处理器根据这三个参数 // 进行预处理或分派到委托类实例上反射执行 Object invoke(Object proxy, Method method, Object[] args)
每次生成动态代理类对象时都须要指定一个实现了该接口的调用处理器对象(参见 Proxy 静态方法 4 的第三个参数)。
每次生成动态代理类对象时都须要指定一个类装载器对象(参见 Proxy 静态方法 4 的第一个参数)
首先让咱们来了解一下如何使用 Java 动态代理。具体有以下四步骤:
// InvocationHandlerImpl 实现了 InvocationHandler 接口, // 并能实现方法调用从代理类到委托类的分派转发 // 其内部一般包含指向委托类实例的引用, // 用于真正执行分派转发过来的方法调用 InvocationHandler handler = new InvocationHandlerImpl(..); // 经过 Proxy 为包括 Interface 接口在内的一组接口 // 动态建立代理类的类对象 Class clazz = Proxy.getProxyClass( classLoader, new Class[] { Interface.class, ... }); // 经过反射从生成的类对象得到构造函数对象 Constructor constructor = clazz.getConstructor( new Class[] { InvocationHandler.class }); // 经过构造函数对象建立动态代理类实例 Interface Proxy = (Interface)constructor.newInstance( new Object[] { handler });
实际使用过程更加简单,由于 Proxy 的静态方法 newProxyInstance 已经为咱们封装了步骤 2 到步骤 4 的过程,因此简化后的过程以下
// InvocationHandlerImpl 实现了 InvocationHandler 接口, // 并能实现方法调用从代理类到委托类的分派转发 InvocationHandler handler = new InvocationHandlerImpl(..); // 经过 Proxy 直接建立动态代理类实例 Interface proxy = (Interface)Proxy.newProxyInstance( classLoader, new Class[] { Interface.class }, handler );
接下来让咱们来了解一下 Java 动态代理机制的一些特色。
首先是动态生成的代理类自己的一些特色。
由图可见,Proxy 类是它的父类,这个规则适用于全部由 Proxy 建立的动态代理类。并且该类还实现了其所代理的一组接口,这就是为何它可以被安全地类型转换到其所代理的某接口的根本缘由。
接下来让咱们了解一下代理类实例的一些特色。每一个实例都会关联一个调用处理器对象,能够经过 Proxy 提供的静态方法 getInvocationHandler 去得到代理类实例的调用处理器对象。在代理类实例上调用其代理的接口中所声明的方法时,这些方法最终都会由调用处理器的 invoke 方法执行,此外,值得注意的是,代理类的根类 java.lang.Object 中有三个方法也一样会被分派到调用处理器的 invoke 方法执行,它们是 hashCode,equals 和 toString,可能的缘由有:
首先,要注意不能有重复的接口,以免动态代理类代码生成时的编译错误。其次,这些接口对于类装载器必须可见,不然类装载器将没法连接它们,将会致使类定义失败。再次,需被代理的全部非 public 的接口必须在同一个包中,不然代理类生成也会失败。最后,接口的数目不能超过 65535,这是 JVM 设定的限制。
/** * Proxy.java * Generate a proxy class. Must call the checkProxyAccess method * to perform permission checks before calling this. */ private static Class<?> getProxyClass0( ClassLoader loader,Class<?>... interfaces) { if (interfaces.length > 65535) { throw new IllegalArgumentException("interface limit exceeded"); } // If the proxy class defined by the given loader implementing // the given interfaces exists, this will simply return the cached copy; // otherwise, it will create the proxy class via the ProxyClassFactory return proxyClassCache.get(loader, interfaces); }
最后再来了解一下异常处理方面的特色。从调用处理器接口声明的方法中能够看到理论上它可以抛出任何类型的异常,由于全部的异常都继承于 Throwable 接口,但事实是否如此呢?答案是否认的,缘由是咱们必须遵照一个继承原则:即子类覆盖父类或实现父接口的方法时,抛出的异常必须在原方法支持的异常列表以内。因此虽然调用处理器理论上讲可以,但实际上每每受限制,除非父接口中的方法支持抛 Throwable 异常。那么若是在 invoke 方法中的确产生了接口方法声明中不支持的异常,那将如何呢?放心,Java 动态代理类已经为咱们设计好了解决方法:它将会抛出 UndeclaredThrowableException 异常。这个异常是一个 RuntimeException 类型,因此不会引发编译错误。经过该异常的 getCause 方法,还能够得到原来那个不受支持的异常对象,以便于错误诊断。
机制和特色都介绍过了,接下来让咱们经过源代码来了解一下 Proxy 究竟是如何实现的。
首先记住 Proxy 的几个重要的静态变量:
// 映射表:用于维护类装载器对象到其对应的代理类缓存 private static Map loaderToCache = new WeakHashMap(); // 标记:用于标记一个动态代理类正在被建立中 private static Object pendingGenerationMarker = new Object(); // 同步表:记录已经被建立的动态代理类类型,主要被方法 isProxyClass 进行相关的判断 private static Map proxyClasses = Collections.synchronizedMap(new WeakHashMap()); // 关联的调用处理器引用 protected InvocationHandler h;
而后,来看一下 Proxy 的构造方法:
// 因为 Proxy 内部从不直接调用构造函数, // 因此 private 类型意味着禁止任何调用 private Proxy() {} // 因为 Proxy 内部从不直接调用构造函数, // 因此 protected 意味着只有子类能够调用 protected Proxy(InvocationHandler h) {this.h = h;}
接着,能够快速浏览一下 newProxyInstance 方法,由于其至关简单:
/** * 将方法调用分派到指定调用处理器 * 并返回指定接口的代理类实例 */ public static Object newProxyInstance( ClassLoader loader, Class<?>[] interfaces, InvocationHandler h) throws IllegalArgumentException { // 检查 h 不为空,不然抛异常 if (h == null) { throw new NullPointerException(); } // 得到与制定类装载器和一组接口相关的代理类类型对象 Class cl = getProxyClass(loader, interfaces); // 经过反射获取构造函数对象并生成代理类实例 try { Constructor cons = cl.getConstructor(constructorParams); return (Object) cons.newInstance(new Object[]{h}); } catch (NoSuchMethodException e) { throw new InternalError(e.toString()); } catch (IllegalAccessException e) { throw new InternalError(e.toString()); } catch (InstantiationException e) { throw new InternalError(e.toString()); } catch (InvocationTargetException e) { throw new InternalError(e.toString()); } }
因而可知,动态代理真正的关键是在 getProxyClass 方法,该方法负责为一组接口动态地生成代理类类型对象。在该方法内部,您将能看到 Proxy 内的各路英雄(静态变量)悉数登场。有点火烧眉毛了么?那就让咱们一块儿走进 Proxy 最最神秘的殿堂去欣赏一番吧。该方法总共能够分为四个步骤:
第 1 步,对这组接口进行必定程度的安全检查,包括检查接口类对象是否对类装载器可见而且与类装载器所能识别的接口类对象是彻底相同的,还会检查确保是 interface 类型而不是 class 类型。这个步骤经过一个循环来完成,检查经过后将会获得一个包含全部接口名称的字符串数组,记为 String[] interfaceNames
。整体上这部分实现比较直观,因此略去大部分代码,仅保留如何判断某类或接口是否对特定类装载器可见的相关代码。
try { // 指定接口名字、类装载器对象, // 同时制定 initializeBoolean // 为 false 表示无须初始化类 // // 若是方法返回正常这表示可见, // 不然会抛出 ClassNotFoundException // 异常表示不可见 interfaceClass = Class.forName(interfaceName, false, loader); } catch (ClassNotFoundException e) { }
第 2 步,从 loaderToCache 映射表中获取以类装载器对象为关键字所对应的缓存表,若是不存在就建立一个新的缓存表并更新到 loaderToCache。缓存表是一个 HashMap 实例,正常状况下它将存放键值对(接口名字列表,动态生成的代理类的类对象引用)。当代理类正在被建立时它会临时保存(接口名字列表,pendingGenerationMarker)。标记 pendingGenerationMarke 的做用是通知后续的同类请求(接口数组相同且组内接口排列顺序也相同)代理类正在被建立,请保持等待直至建立完成。
do { // 以接口名字列表做为关键字得到对应 cache 值 Object value = cache.get(key); if (value instanceof Reference) { proxyClass = (Class) ((Reference) value).get(); } if (proxyClass != null) { // 若是已经建立,直接返回 return proxyClass; } else if (value == pendingGenerationMarker) { // 代理类正在被建立,保持等待 try { cache.wait(); } catch (InterruptedException e) { } // 等待被唤醒后, // 再次循环检查, // 以确保建立完成, // 不然从新等待 continue; } else { // 标记代理类正在被建立 cache.put(key, pendingGenerationMarker); // break 跳出循环已进入建立过程 break; } while (true);
第 3 步,动态建立代理类的类对象。首先是肯定代理类所在的包,其原则如前所述,若是都为 public 接口,则包名为空字符串表示顶层包;若是全部非 public 接口都在同一个包,则包名与这些接口的包名相同;若是有多个非 public 接口且不一样包,则抛异常终止代理类的生成。肯定了包后,就开始生成代理类的类名,一样如前所述按格式” $ProxyN ”生成。类名也肯定了,接下来就是见证奇迹的发生 —— 动态生成代理类:
// 动态地生成代理类的字节码数组 byte[] proxyClassFile = ProxyGenerator.generateProxyClass( proxyName, interfaces); try { // 动态地定义新生成的代理类 proxyClass = defineClass0( loader, proxyName, proxyClassFile, 0, proxyClassFile.length); } catch (ClassFormatError e) { throw new IllegalArgumentException(e.toString()); } // 把生成的代理类的类对象 // 记录进 proxyClasses 表 proxyClasses.put(proxyClass, null);
因而可知,全部的代码生成的工做都由神秘的 ProxyGenerator 所完成了,当你尝试去探索这个类时,你所能得到的信息仅仅是它位于并未公开的 sun.misc 包,有若干常量、变量和方法以完成这个神奇的代码生成的过程,可是 sun 并无提供源代码以供研读。至于动态类的定义,则由 Proxy 的 native 静态方法 defineClass0 执行。
第 4 步,代码生成过程进入结尾部分,根据结果更新缓存表,若是成功则将代理类的类对象引用更新进缓存表,不然清除缓存表中对应关键值,最后唤醒全部可能的正在等待的线程。
走完了以上四个步骤后,至此,全部的代理类生成细节都已介绍完毕,剩下的静态方法如 getInvocationHandler 和 isProxyClass 就显得如此的直观,只需经过查询相关变量就能够完成,因此对其的代码分析就省略了。
分析了 Proxy 类的源代码,相信在读者的脑海中会对 Java 动态代理机制造成一个更加清晰的理解,可是,当探索之旅在 sun.misc.ProxyGenerator 类处嘎然而止,全部的神秘都汇聚于此时,相信很多读者也会对这个 ProxyGenerator 类产生有相似的疑惑:它到底作了什么呢?它是如何生成动态代理类的代码的呢?诚然,这里也没法给出确切的答案。仍是让咱们带着这些疑惑,一块儿开始探索之旅吧。
事物每每不像其看起来的复杂,须要的是咱们可以化繁为简,这样也许就能有更多拨云见日的机会。抛开全部想象中的未知而复杂的神秘因素,若是让咱们用最简单的方法去实现一个代理类,惟一的要求是一样结合调用处理器实施方法的分派转发,您的第一反应将是什么呢?”听起来彷佛并非很复杂”。的确,掐指算算所涉及的工做无非包括几个反射调用,以及对原始类型数据的装箱或拆箱过程,其余的彷佛都已经水到渠成。很是地好,让咱们整理一下思绪,一块儿来完成一次完整的推演过程吧。
// 假设需代理接口 Simulator public interface Simulator { short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB; } // 假设代理类为 SimulatorProxy, 其类声明将以下 final public class SimulatorProxy implements Simulator { // 调用处理器对象的引用 protected InvocationHandler handler; // 以调用处理器为参数的构造函数 public SimulatorProxy(InvocationHandler handler){ this.handler = handler; } // 实现接口方法 simulate public short simulate(int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB { // 第一步是获取 simulate 方法的 Method 对象 java.lang.reflect.Method method = null; try{ method = Simulator.class.getMethod( "simulate", new Class[] {int.class, long.class, String.class} ); } catch(Exception e) { // 异常处理 1(略) } // 第二步是调用 handler 的 invoke 方法分派转发方法调用 Object r = null; try { r = handler.invoke(this, method, // 对于原始类型参数须要进行装箱操做 new Object[] {new Integer(arg1), new Long(arg2), arg3}); }catch(Throwable e) { // 异常处理 2(略) } // 第三步是返回结果(返回类型是原始类型则须要进行拆箱操做) return ((Short)r).shortValue(); } }
模拟推演为了突出通用逻辑因此更多地关注正常流程,而淡化了错误处理,但在实际中错误处理一样很是重要。从以上的推演中咱们能够得出一个很是通用的结构化流程:
在这之中,全部的信息都是能够已知的,好比接口名、方法名、参数类型、返回类型以及所需的装箱和拆箱操做,那么既然咱们手工编写是如此,那又有什么理由不相信 ProxyGenerator 不会作相似的实现呢?至少这是一种比较可能的实现。
接下来让咱们把注意力从新回到先前被淡化的错误处理上来。在异常处理 1 处,因为咱们有理由确保全部的信息如接口名、方法名和参数类型都准确无误,因此这部分异常发生的几率基本为零,因此基本能够忽略。而异常处理 2 处,咱们须要思考得更多一些。回想一下,接口方法可能声明支持一个异常列表,而调用处理器 invoke 方法又可能抛出与接口方法不支持的异常,再回想一下先前说起的 Java 动态代理的关于异常处理的特色,对于不支持的异常,必须抛 UndeclaredThrowableException 运行时异常。因此经过再次推演,咱们能够得出一个更加清晰的异常处理 2 的状况:
Object r = null; try { r = handler.invoke( this, method, new Object[] { new Integer(arg1), new Long(arg2), arg3 } ); } catch( ExceptionA e) { // 接口方法支持 ExceptionA,能够抛出 throw e; } catch( ExceptionB e ) { // 接口方法支持 ExceptionB,能够抛出 throw e; } catch(Throwable e) { // 其余不支持的异常, // 一概抛 UndeclaredThrowableException throw new UndeclaredThrowableException(e); }
这样咱们就完成了对动态代理类的推演实现。推演实现遵循了一个相对固定的模式,能够适用于任意定义的任何接口,并且代码生成所需的信息都是可知的,那么有理由相信即便是机器自动编写的代码也有可能延续这样的风格,至少能够保证这是可行的。
诚然,Proxy 已经设计得很是优美,可是仍是有一点点小小的遗憾之处,那就是它始终没法摆脱仅支持 interface 代理的桎梏,由于它的设计注定了这个遗憾。回想一下那些动态生成的代理类的继承关系图,它们已经注定有一个共同的父类叫 Proxy。Java 的继承机制注定了这些动态代理类们没法实现对 class 的动态代理,缘由是多继承在 Java 中本质上就行不通。
有不少条理由,人们能够否认对 class 代理的必要性,可是一样有一些理由,相信支持 class 动态代理会更美好。接口和类的划分,本就不是很明显,只是到了 Java 中才变得如此的细化。若是只从方法的声明及是否被定义来考量,有一种二者的混合体,它的名字叫抽象类。实现对抽象类的动态代理,相信也有其内在的价值。此外,还有一些历史遗留的类,它们将由于没有实现任何接口而今后与动态代理永世无缘。如此种种,不得不说是一个小小的遗憾。
可是,不完美并不等于不伟大,伟大是一种本质,Java 动态代理就是佐例。
-- 来自IBM Developer 王忠平, 何平
代理模式是先人们针对一类特定问题总结出的经验结晶,并在各个领域中得以灵活应用。特别是在编程领域,不一样语言根据自身的设计规范和特色融会贯通,最终都可以落实到具体的解决方案中,譬如Spring AOP在性能事务上的加强提高,或者是拦截器实如今日志和权限层面的控制过滤等等,都能作到对原接口事务的无侵入,同时还能灵活管控,大范围实施,达到咱们的预期,这就是代理模式,巧妙之处。
[1]Java 动态代理机制分析及扩展:https://developer.ibm.com/zh/articles/j-lo-proxy1/
[2]代理模式原理及实例讲解:https://developer.ibm.com/zh/articles/j-lo-proxy-pattern/
[3]Dynamic Proxy Classes:https://java.sun.com/j2se/1.4.2/docs/guide/reflection/proxy.html
[4]动态代理机制:https://www.ibm.com/developerworks/cn/java/j-jtp08305.html
[5]图片素材来源:https://www.pexels.com/
[6]流程图设计来源:https://www.processon.com/
BIU ~ 文章持续更新,微信搜索「潘潘和他的朋友们」第一时间阅读,随时有惊喜。本文会在 GitHub https://github.com/JavaWorld 收录,热腾腾的技术、框架、面经、解决方案,咱们都会以最美的姿式第一时间送达,欢迎 Star。