共计 5888 个字符,预计需要花费 15 分钟才能阅读完成。
前言
在上篇 如何实现 AOP(上)介绍了 AOP
技术呈现的起因和一些重要的概念,在咱们本人实现之前有必要先理解一下 AOP
底层到底是如何运作的,所以这篇再来看看 AOP
实现所依赖的一些外围根底技术。AOP
是应用 动静代理
和字节码生成技术
来实现的,在 运行期(留神:不是编译期!)为指标对象生成代理对象,而后将横切逻辑织入到生成的代理对象中,最初零碎应用的是带有横切逻辑的代理对象,而不是被代理对象,由代理对象转发到被代理对象。
代理模式
动静代理的本源是设计模式中的代理模式,代理模式在 GoF 中的形容如下:
Provide a surrogate or placeholder for another object to control access to it.
从其定义能够看出,代理模式次要是为了管制对象的拜访,通常也会领有被代理者的所有性能。通过代理模式咱们能够在不扭转被代理类的状况下,通过引入代理类来给被代理类增加一些性能,此时脑海里飘过计算机科学界中一句驰名的话(P.S. 基础知识很重要啊,能够参见 这篇):
计算机科学的任何一个问题,都能够通过减少一个中间层来解决。
代理模式其实在现实生活中也常常会接触到,比方在一线城市租房时大部分都是找的租房中介去看的房子、谈价格以及签合同,是因为房子的房东曾经把房子全权托管给了中介解决了,这里的租房中介其实就是充当了代理模式中的代理对象的解决,而真正的被代理对象 (指标对象) 其实是房子的房东,而和咱们打交道都是租房中介(代理对象)。代理模式类图构造如下图所示:
图中各个局部的含意如下:
- ISubject 是被代理对象所能提供能力的形象。
- SubjectImpl 是被代理的具体实现类。
- SubjectProxy 是代理的实现类,通常该类持有
ISubject
接口的实例。 - Client 是访问者的形象角色,要拜访
ISubject
类型的资源。
能够看到 SubjectImpl
和 SubjectProxy
都实现了雷同的接口 ISubject
,在代理对象 SubjectProxy
内持有 ISubject
的援用,当 Client
拜访 doOperation()
时,代理对象将申请转发给被代理对象,单单从这个过程来看,代理对象如果只是为了转发申请,是不是有点多此一举了?再联合代理模式的定义思考一下,在转发之前(后者之后)不就能够增加一些访问控制了吗。
在代理对象 (SubjectProxy
) 将申请转发给被代理对象 (SubejctImpl
) 之前或者之后都是依据须要增加一些解决逻辑,而不须要批改被代理对象的具体实现逻辑,假如 SubjectImpl
是咱们零碎中 Joinpoint
所在的对象,此时 SubjectImpl
就是咱们的指标对象了,只须要为这个指标对象创立一个代理对象,而后将横切逻辑增加到代理对象中,对外暴露出创立进去的代理对象就能够将将横切逻辑和原来的逻辑交融在一起了。
动静代理
到目前为止,一切都是那么美妙,当只为同一个指标对象类型增加横切逻辑时,只须要创立一个代理对象即可,然而在 Joinpoint
雷同而指标对象类型不同时,须要为每个不同的指标对象类型都独自创立一个代理对象,而这些代理对象的横切逻辑其实都是一样的,依据 DRY 准则,须要寻找另一种技术来解决这个问题。
在 JDK 1.3
引入的 动静代理机制
能够为指定的接口在 运行期
动静的去生成代理对象,应用这个 动静代理机制
能够解决上述问题,这样咱们就能够不当时为每个原始类创立代理类,而是在运行时 动静生成
代理类。在 Java
中,应用动静代理是比较简单的,它自身就曾经应用反射实现了动静代理的语法,次要是由一个类 Proxy
和一个接口 InvocationHandler
组成,应用动静代理机制实现前文示例如下:
/**
* @author mghio
* @since 2021-05-29
*/
public interface Subject {void doOperation();
}
public class SubjectImpl implements Subject {
@Override
public void doOperation() {System.out.println("SubjectImpl doOperation...");
}
}
public class JDKInvocationHandler implements InvocationHandler {
private final Subject target;
public JDKInvocationHandler(Subject target) {this.target = target;}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// add pre process logic if necessary
System.out.println("Proxy before JDKInvocationHandler doOperation...");
Object result = method.invoke(target, args);
System.out.println("Proxy after JDKInvocationHandler doOperation...");
// add post process logic if necessary
return result;
}
}
public class Client {public static void main(String[] args) {
// 将生成的代理类保留在根目录下(com/sun/proxy/XXX.class)System.setProperty("sun.misc.ProxyGenerator.saveGeneratedFiles", "true");
Subject target = new SubjectImpl();
Subject proxy = (Subject) Proxy.newProxyInstance(SubjectImpl.class.getClassLoader(),
new Class[]{Subject.class}, new JDKInvocationHandler(target));
proxy.doOperation();}
}
由以上代码可知,应用 JDK
的动静代理只有 3 步:
- 定义公共接口
Subject
,创立被代理对象SubjectImpl
- 创立被代理对象的解决对象
JDKInvocationHandler
,持有指标对象Subject
的援用 - 应用
JDK
的Proxy
类的静态方法newProxyInstance
创立代理对象
通过设置 sun.misc.ProxyGenerator.saveGeneratedFiles
属性,能够将动静生成的代理类保留在我的项目根目录下,运行下面的示例代码生成的代理类如下:
public final class $Proxy0 extends Proxy implements Subject {
private static Method m1;
private static Method m2;
private static Method m3;
private static Method m0;
static {
try {m1 = Class.forName("java.lang.Object").getMethod("equals", Class.forName("java.lang.Object"));
m2 = Class.forName("java.lang.Object").getMethod("toString");
m3 = Class.forName("cn.mghio.designpattern.proxy.dynamicproxy.Subject").getMethod("doOperation");
m0 = Class.forName("java.lang.Object").getMethod("hashCode");
} catch (NoSuchMethodException var2) {throw new NoSuchMethodError(var2.getMessage());
} catch (ClassNotFoundException var3) {throw new NoClassDefFoundError(var3.getMessage());
}
}
public $Proxy0(InvocationHandler var1) throws {super(var1);
}
public final void doOperation() throws {
try {super.h.invoke(this, m3, (Object[])null);
} catch (RuntimeException | Error var2) {throw var2;} catch (Throwable var3) {throw new UndeclaredThrowableException(var3);
}
}
// omit toString、equals、hashCode method...
}
从动静生成的代理类的代码能够看出,JDK
动静代理生成的代理类是继承 JDK
中提供的 Proxy
和实现被代理类所实现的接口。进一步能够从这个实现形式得出两点:1. 应用 JDK
动静代理时为什么只能应用 接口援用指向代理
,而不能应用被代理的具体类援用指向代理;2. 被代理类必须实现接口,因为 JDK
动静代理生成的代理类必须继承自 Proxy
,而 Java
不反对多重继承,所以只能通过实现接口的形式。
在默认状况下,Spring AOP
发现了指标对象实现了接口,会应用 JDK
动静代理机制为其动静生成代理对象,尽管提倡 面向接口编程
,然而也有指标对象没有实现接口的场景,当被代理的指标对象没有实现接口时就无奈应用 JDK
动静代理了,那么这种状况下就须要应用第三方工具来帮忙了。
字节码生成技术
当指标对象没有实现接口时,能够通过动静字节码生成来继承指标对象来动静生成相应的子类,在生成的子类中 重写
父类指标对象的行为,而后将横切逻辑放在子类,在零碎中应用指标对象的子类,最终的成果是代理模式是一样的,CGLIB 动静字节码生成类库(它自身其实也是一个形象层,更底层是 ASM)能够动静生成和批改一个类的字节码。当以上示例代码指标对象未实现接口时批改为 CGLIB
动静生成字节码形式实现如下:
/**
* @author mghio
* @since 2021-05-29
*/
public class RealSubject {public void doOperation() {System.out.println("RealSubject doOperation...");
}
}
public class CglibMethodInterceptor implements MethodInterceptor {
@Override
public Object intercept(Object o, Method method, Object[] args, MethodProxy methodProxy)
throws Throwable {
// add pre process logic if necessary
System.out.println("Cglib before RealSubject doOperation...");
Object result = methodProxy.invokeSuper(o, args);
System.out.println("Cglib after RealSubject doOperation...");
// add post process logic if necessary
return result;
}
}
public class Client {public static void main(String[] args) {
// 将生成的动静代理类保留到文件中
System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY,
"/Users/mghio/IdeaProjects/designpattern/cglib/proxy/");
// 1. 创立 Enhancer 对象
Enhancer enhancer = new Enhancer();
// 2. 设置被代理类
enhancer.setSuperclass(RealSubject.class);
// 3. 设置回调对象(实现 MethodInterceptor 接口)
enhancer.setCallback(new CglibMethodInterceptor());
// 4. 创立代理对象
RealSubject proxy = (RealSubject) enhancer.create();
proxy.doOperation();}
}
应用 CGLIB
生成代理对象须要 4 步:
- 创立
Enhancer
对象,动静生成字节码的绝大部分逻辑都是在这个类中实现的。 - 设置被代理类(指标对象),生成的代理类会继承自这个接口,也就意味着这个类不能是
final
类型的。 - 设置回调对象(实现
MethodInterceptor
接口),在这里依据须要增加横切逻辑。 - 调用
Enhaner
的create()
办法创立代理对象。
在设置 DebuggingClassWriter.DEBUG_LOCATION_PROPERTY
属性后,反编译已保留的动静生成代理类如下:
从反编译后的代码能够看出 CGLIB
生成的代理类是通过继承被代理类 RealSubject
实现 Factory
接口实现的,要能被继承也就要求被代理类不能是 final
类型的。看到这里你可能会问:既然 JDK
动静代理要求被代理类实现接口,而 CGLIB
动静字节码生成要求不能是 final
类,那对于那些没有实现接口同时还是 final
类,要怎么动静代理呢?好问题,这个就留给你本人去思考了。
总结
本文简要介绍了 Spring AOP
实现所依赖的外围根底技术,从动静代理的本源代理模式到动静代理和动静字节码生成技术,为下篇入手实现简易版的 AOP
打下基础,在理解了所依赖的根底技术后,在具体实现时就会更加丝滑,动静代理
和动静字节码生成
比照如下:
比照项 | JDK 动静代理 | CGLIB |
---|---|---|
生成代理类的形式 | 继承 JDK 中 Proxy ,实现被代理类的所有接口 |
继承被代理类,实现 CGLIB 的 Factory 接口 |
被代理对象的要求 | 必须实现接口,能够是 final 类 |
非 final 类,办法也要是非 final 类型的 |
集成形式 | JDK 内置 |
第三方动静字节码生成类库 |