问题:动态代理是基于什么原理?
基础是反射机制,但稍微有些不全面。功能才是目的,实现的方法有很多。动态代理,是延伸出来的一种广泛应用于产品开发中的技术,很多繁琐的重复编程,都可以被动态代理机制优雅地解决。
动态类型:运行时检查
静态类型:编译期检查
强类型:不同类型变量赋值时,需要显示地(强制)进行类型转换。
弱类型:
通常认为,Java是静态的强类型语言。
但因为提供了反射等机制,也具备了部分动态类型语言的能力。
写个小Demo,更好理解和说明。
反射机制是 Java语言提供的一种基础功能,赋予程序在运行时自省(introspect,官方用语)的能力。通过反射我们可以直接操作类或者对象,比如获取某个对象的类定义,获取类声明的属性和方法,调用方法或者构造对象,甚至可以运行时修改类定义。
看java.lang或java.lang.reflect包下的相关抽象。
Class、Method、Field、Constructor等。
反射提供的 AccessibleObject.setAccessible
(boolean flag)。它的子类也大都重写了这个方法,这里的所谓 accessible 可以理解成修饰成员的 public、protected、private,这意味着我们可以在运行时修改成员访问限制。
可以绕过API的访问控制。但在Java9后,这个方法的使用可能会存在一些争议,因为Jigsaw项目新增的模块化系统,出于强封装性的考虑,对反射访问进行了限制。Jigsaw引入了所谓 Open 的概念,只有当被反射操作的模块和指定的包对反射调用者模块Open,才能使用setAccessible;否则,被认为是不合法(illegal)操作。如果我们的实体类是定义在模块里面,我们需要在模块描述符中明确声明:
module MyEntities {
// Open for reflection
opens com.mycorp to java.persistence;
}
因为反射机制使用广泛,根据社区讨论,目前,Java 9 仍然保留了兼容 Java 8 的行为。
Java反射最大的好处就是能在运行期间,获得某个类的结构、成员变量,用来实例化。
下列是具体使用场景:假如我们有两个程序员,一个程序员在写程序的时候,需要使用第二个程序员所写的类,但第二个程序员并没完成他所写的类。那么第一个程序员的代码能否通过编译呢?这是不能通过编译的。利用Java反射的机制,就可以让第一个程序员在没有得到第二个程序员所写的类的时候,来完成自身代码的编译。Java的反射机制它知道类的基本结构,这种对Java类结构探知的能力,我们称为Java类的“自审”。大家都用过Jcreator和eclipse。当我们构建出一个对象的时候,去调用该对象的方法和属性的时候。一按点,编译工具就会自动的把该对象能够使用的所有的方法和属性全部都列出来,供用户进行选择。这就是利用了Java反射的原理,是对我们创建对象的探知、自审。
运行Object o = new Object();
(方法区存的是类的信息,不是存类对象的,类加载器加载类是通过方法区上类的信息在堆上创建一个类的Class对象,这个Class对象是唯一的,由JVM保证唯一,之后对这个类的创建都是根据这个Class对象来操作的。)
(你可以理解成类存在方法区中,类的class对象存在于堆中,这个class对象会作为运行时创建该类对象的模版。这个class对象是唯一对应该类的,要区分所谓的实例和class对象。为什么需要class对象,你想下如果一个加载进方法区的类,在jvm运行时是动态加载进来的,没有这个class对象你思考该如何访问一个未知的类并创建对象呢?没错就是这个class作为访问接口。
)
相当于代码写死了给JVM去跑,跑完就结束了。JVM关闭,程序就停止。
类要有加载进JVM才能被使用。
要让Java程序能够运行,那么就得让Java类要被Java虚拟机加载。Java类如果不被Java虚拟机加载,是不能正常运行的。现在我们运行的所有的程序都是在编译期的时候就已经知道了你所需要的那个类的已经被加载了。
Java的反射机制是在编译并不确定是哪个类被加载了,而是在程序运行的时候才加载、探知、自审。使用在编译期并不知道的类。这样的特点就是反射。
当我们的程序在运行时,需要动态的加载一些类这些类可能之前用不到所以不用加载到JVM,而是在运行时根据需要才加载。
java的反射机制就是增加程序的灵活性,避免将程序写死到代码里,例如:实例化一个person()对象,不使用反射,new person(); 如果想变成实例化其他类,那么必须修改源代码,并重新编译。
使用反射: class.forName(“person”).newInstance();而且这个类描述可以写到配置文件中,如**.xml,这样如果想实例化其他类,只要修改配置文件的"类描述"就可以了,不需要重新修改代码并编译。
首先,它是一个代理机制。代理可以看作是对调用目标的一个包装,这样我们对目标代码的调用不是直接发生的,而是通过代理完成。其实很多动态代理场景,我认为也可以看作是装饰器(Decorator)模式的应用。
通过代理可以让调用者与实现者之间解耦。比如进行 RPC 调用,框架内部的寻址、序列化、反序列化等,对于调用者往往是没有太大意义的,通过代理,可以提供更加友善的界面。
代理的发展经历了静态到动态的过程,源于静态代理引入的额外工作。
实现动态代理的方式很多,比如JDK自身提供的动态代理,就是主要利用了上面提到的反射机制。还有其他的实现方式,比如利用传说中更高性能的字节码操作机制,类似ASM、cglib(基于 ASM)、Javassist 等。
代理模式是为了提供额外或不同的操作,而插入的用来替代”实际”对象的对象,这些操作涉及到与”实际”对象的通信,因此代理通常充当中间人角色。
动态代理可以动态地创建并代理并动态地处理对所代理方法的调用。
Spring AOP支持两种模式的动态代理。JDK Proxy或cglib。
以接口为中心。
优点:
优点:
在主流 JDK 版本中,JDK Proxy 在典型场景可以提供对等的性能水平,数量级的差距基本上不是广泛存在的。而且,反射机制性能在现代JDK中,自身已经得到了极大的改进和优化,同时,JDK很多功能也不完全是反射,同样使用了 ASM 进行字节码操作。
我们在选型中,性能未必是唯一考量,可靠性、可维护性、编程工作量等往往是更主要的考虑因素,毕竟标准类库和反射编程的门槛要低得多,代码量也是更加可控的,如果我们比较下不同开源项目在动态代理开发上的投入,也能看到这一点。
动态代理应用非常广泛,虽然最初多是因为RPC等使用进入我们视线,但是动态代理的使用场景远远不仅如此,它完美符合 Spring AOP 等切面编程。
(RPC:远程过程调用协议)