Spring AOP

基础介绍

产生背景

“存在即合理”,任何一种理论或技术的产生,必然有它的原因。了解它产生的背景、为了解决的问题有助于我们更好地把握AOP(Aspect-OrientedProgramming)的概念。
软件开发一直在寻求一种高效开发、护展、维护的方式。从面向过程的开发实践中,前人将关注点抽象出来,对行为和属性进行聚合,形成了面向对象的开发思想,其在一定程度上影响了软件开发的过程。鉴于此,我们在开发的过程中会对软件开发进行抽象、分割成各个模块或对象。例如,我们会对API进行抽象成四个模块:Controller,Service,Gateway,Command.这很好地解决了业务级别的开发,但对于系统级别的开发我们很难聚焦。比如、对于每一个模块需要进行打日志、代码监控、异常处理。以打日志为例,我只能将日志代码嵌套在各个对象上,而无法关注日志本身,而这种现象又偏离了OOP思想。

为了能够更好地将系统级别的代码抽离出来,去掉与对象的耦合,就产生了面向AOP(面向切面)。如上图所示,OOP属于一种横向扩展,AOP是一种纵向扩展。AOP依托于OOP,进一步将系统级别的代码抽象出来,进行纵向排列,实现低耦合。至于AOP的确切的概念,我不希望给出抽象复杂的表述,只需要了解其作用即可。

相关概念

  1. PointCut

    即在哪个地方进行切入,它可以指定某一个点,也可以指定多个点。
    比如类A的methord函数,当然一般的AOP与语言(AOL)会采用多用方式来定义PointCut,比如说利用正则表达式,可以同时指定多个类的多个函数。

  2. Advice

    在切入点干什么,指定在PointCut地方做什么事情(增强),打日志、执行缓存、处理异常等等。

  3. Advisor/Aspect

    PointCut + Advice 形成了切面Aspect,这个概念本身即代表切面的所有元素。但到这一地步并不是完整的,因为还不知道如何将切面植入到代码中,解决此问题的技术就是PROXY

  4. Proxy

    Proxy 即代理,其不能算做AOP的家庭成员,更相当于一个管理部门,它管理 了AOP的如何融入OOP。之所以将其放在这里,是因为Aspect虽然是面向切面核心思想的重要组成部分,但其思想的践行者却是Proxy,也是实现AOP的难点与核心据在。

实现方式

小伙伴们知道,AOP 底层就是动态代理,动态代理有两种实现方式:

  • JDK 动态代理:利用拦截器(必须实现 InvocationHandler)加上反射机制生成一个代理接口的匿名类,在调用具体方法前调用 InvokeHandler 来处理。举个例子,假设有一个接口 A,A 有一个实现类 B,现在要给 B 生成代理对象,那么实际上是给 A 接口自动生成了一个匿名实现类,并且在这个匿名实现类中调用到 B 中的方法。
  • CGLIB 动态代理:利用 ASM 框架,对代理对象类生成的 class 文件加载进来,通过修改其字节码生成子类来处理。举个例子,现在有一个类 A,A 没有接口,现在想给 A 生成一个代理对象,那么实际上是自动给 A 生成了一个子类,在这个子类中覆盖了 A 中的方法,所以,小伙伴们要注意,A 类以及它里边的方法不能是 final 类型的,否则无法生成代理

如果被代理的对象有接口,则可以使用 JDK 动态代理,没有接口就可以使用 CGLIB 动态代理。

在 Spring 中,默认情况下,如果被代理的对象有接口,就使用 JDK 动态代理,如果被代理的对象没有接口,则使用 CGLIB 动态代理。

在 Spring Boot 中,2.0 之前也跟 Spring 中的规则一样,2.0 之后则统一都使用 CGLIB 动态代理。

不过这些都是默认的规则,如果有接口,但是你又希望使用 CGLIB 动态代理,通过修改配置,也都是可以实现的。

底层原理

Spring AOP底层还是基于IOC来实现的。

Spring通过AnnotationAwareAspectJAutoProxyCreator来创建代理类,其类图如下:

我们可以发现它实现了两类接口:
  • BeanFactoryAware属于Bean级生命周期接口方法

  • InstantiationAwareBeanPostProcessor 和 BeanPostProcessor 这两个接口实现,一般称它们的实现类为“后处理器”,是容器级生命周期接口方法

结合Spring Bean的生命周期:

我们可以发现AOP的主要初始话方法再上图红色方框中。

JDK动态代理

回顾代理模式

代理模式,即 为另一个对象提供一个替身或占位符以控制对这个对象的访问。其类图通常如下:

### 实现方式

Spring默认使用JDK的动态代理实现AOP,类如果实现了接口,Spring就会使用这种方式实现动态代理。熟悉Java语言的应该会对JDK动态代理有所了解。JDK实现动态代理需要两个组件:

  • 首先第一个就是InvocationHandler接口。我们在使用JDK的动态代理时,需要编写一个类,去实现这个接口,然后重写invoke方法,这个方法其实就是我们提供的代理方法。
  • 然后JDK动态代理需要使用的第二个组件就是Proxy这个类,我们可以通过这个类的newProxyInstance方法,返回一个代理对象。生成的代理类实现了原来那个类的所有接口,并对接口的方法进行了代理,我们通过代理对象调用这些方法时,底层将通过反射,调用我们实现的invoke方法。

实现原理

JDK的动态代理是基于反射实现。JDK通过反射,生成一个代理类,这个代理类实现了原来那个类的全部接口,并对接口中定义的所有方法进行了代理。当我们通过代理对象执行原来那个类的方法时,代理类底层会通过反射机制,回调我们实现的InvocationHandler接口的invoke方法。并且这个代理类是Proxy类的子类(记住这个结论,后面测试要用)。这就是JDK动态代理大致的实现方式。

优缺点

  • 优点
    1. JDK动态代理是JDK原生的,不需要任何依赖即可使用;
    2. 通过反射机制生成代理类的速度要比CGLib操作字节码生成代理类的速度更快;
  • 缺点
    1. 如果要使用JDK动态代理,被代理的类必须实现了接口,否则无法代理。因为java只支持单继承,而JDK动态代理再创建代理对象时,默认让代理对象继承自Proxy类,因此无法同时继承被代理类,只能通过实现相同接口来实现。
    2. JDK动态代理无法为没有在接口中定义的方法实现代理,假设我们有一个实现了接口的类,我们为它的一个不属于接口中的方法配置了切面,Spring仍然会使用JDK的动态代理,但是由于配置了切面的方法不属于接口,为这个方法配置的切面将不会被织入。
    3. JDK动态代理执行代理方法时,需要通过反射机制进行回调,此时方法执行的效率比较低;

实践测试

下面我们通过一个简单的例子,来验证上面的说法。首先我们需要一个接口和它的一个实现类,然后再为这个实现类的方法配置切面,看看Spring是否真的使用的是JDK的动态代理。假设接口的名称为Human,而实现类为Student

1
2
3
4
5
6
7
8
9
10
11
12
public interface Human {
void display();
}

@Component
public class Student implements Human {

@Override
public void display() {
System.out.println("I am a student");
}
}

然后我们定义一个切面,将这个display方法作为切入点,为它配置一个前置通知,代码如下:

1
2
3
4
5
6
7
8
9
@Aspect
@Component
public class HumanAspect {
// 为Student这个类的所有方法,配置这个前置通知
@Before("execution(* cn.tewuyiang.pojo.Student.*(..))")
public void before() {
System.out.println("before student");
}
}

下面可以开始测试了,我们通过Java类的方式进行配置,然后编写一个单元测试方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 配置类
@Configuration
@ComponentScan(basePackages = "cn.tewuyiang")
@EnableAspectJAutoProxy
public class AOPConfig {
}

// 测试方法
@Test
public void testProxy() {
ApplicationContext context =
new AnnotationConfigApplicationContext(AOPConfig.class);
// 注意,这里只能通过Human.class获取,而无法通过Student.class,因为在Spirng容器中,
// 因为使用JDK动态代理,Ioc容器中,存储的是一个类型为Human的代理对象
Human human = context.getBean(Human.class);
human.display();
// 输出代理类的父类,以此判断是JDK还是CGLib
System.out.println(human.getClass().getSuperclass());
}

注意看上面代码中,最长的那一句注释。由于我们需要代理的类实现了接口,则Spring会使用JDK的动态代理,生成的代理类会实现相同的接口,然后创建一个代理对象存储在Spring容器中。这也就是说,在Spring容器中,这个代理bean的类型不是Student类型,而是Human类型,所以我们不能通过Student.class获取,只能通过Human.class(或者通过它的名称获取)。这也证明了我们上面说过的另一个问题,JDK动态代理无法代理没有定义在接口中的方法。假设Student这个类有另外一个方法,它不是Human接口定义的方法,此时就算我们为它配置了切面,也无法将切面织入。而且由于在Spring容器中保存的代理对象并不是Student类型,而是Human类型,这就导致我们连那个不属于Human的方法都无法调用。这也说明了JDK动态代理的局限性。

我们前面说过,JDK动态代理生成的代理类继承了Proxy这个类,而CGLib生成的代理类,则继承了需要进行代理的那个类,于是我们可以通过输出代理对象所属类的父类,来判断Spring使用了何种代理。下面是输出结果:

1
2
3
before student
I am a student
class java.lang.reflect.Proxy // 注意看,父类是Proxy

通过上面的输出结果,我们发现,代理类的父类是Proxy,也就意味着果然使用的是JDK的动态代理。

CGLib动态代理

实现原理

CGLib实现动态代理的原理是,底层采用了ASM字节码生成框架,直接对需要代理的类的字节码进行操作,生成这个类的一个子类,并重写了类的所有可以重写的方法,在重写的过程中,将我们定义的额外的逻辑(简单理解为Spring中的切面)织入到方法中,对方法进行了增强。而通过字节码操作生成的代理类,和我们自己编写并编译后的类没有太大区别。

优缺点

  • 优点
    1. 使用CGLib代理的类,不需要实现接口,因为CGLib生成的代理类是直接继承自需要被代理的类;
    2. CGLib生成的代理类是原来那个类的子类,这就意味着这个代理类可以为原来那个类中,所有能够被子类重写的方法进行代理;
    3. CGLib生成的代理类,和我们自己编写并编译的类没有太大区别,对方法的调用和直接调用普通类的方式一致,所以CGLib执行代理方法的效率要高于JDK的动态代理;
  • 缺点
    1. 由于CGLib的代理类使用的是继承,这也就意味着如果需要被代理的类是一个final类,则无法使用CGLib代理;
    2. 由于CGLib实现代理方法的方式是重写父类的方法,所以无法对final方法,或者private方法进行代理,因为子类无法重写这些方法;
    3. CGLib生成代理类的方式是通过操作字节码,这种方式生成代理类的速度要比JDK通过反射生成代理类的速度更慢;

实践测试

好,测试完JDK动态代理,我们开始测试CGLib动态代理。我们前面说过,只有当需要代理的类没有实现接口时,Spring才会使用CGLib动态代理,于是我们修改Student这个类的定义,不让他实现接口:

1
2
3
4
5
6
@Component
public class Student {
public void display() {
System.out.println("I am a student");
}
}

由于Student没有实现接口,所以我们的测试方法也需要做一些修改。之前我们是通过Human.class这个类型从Spring容器中获取代理对象,但是现在,由于没有实现接口,所以我们不能再这么写了,而是要写成Student.class,如下:

1
2
3
4
5
6
7
8
9
10
@Test
public void testProxy() {
ApplicationContext context =
new AnnotationConfigApplicationContext(AOPConfig.class);
// 修改为Student.class
Student student = context.getBean(Student.class);
student.display();
// 同样输出父类
System.out.println(student.getClass().getSuperclass());
}

因为CGLib动态代理是生成了Student的一个子类,所以这个代理对象也是Student类型(子类也是父类类型),所以可以通过Student.class获取。下面是输出结果:

1
2
3
before student
I am a student
class cn.tewuyiang.pojo.Student // 此时,父类是Student

可以看到,AOP成功生效,并且代理对象所属类的父类是Student,验证了我们之前的说法。下面我们修改一下Student类的定义,将display方法加上final修饰符,再看看效果:

1
2
3
4
5
6
7
8
9
10
11
@Component
public class Student {
// 加上final修饰符
public final void display() {
System.out.println("I am a student");
}
}

// 输出结果如下:
I am a student
class cn.tewuyiang.pojo.Student

可以看到,输出的父类仍然是Student,也就是说Spring依然使用了CGLib生成代理。但是我们发现,我们为display方法配置的前置通知并没有执行,也就是代理类并没有为display方法进行代理。这也验证了我们之前的说法,CGLib无法代理final方法,因为子类无法重写父类的final方法。下面我们可以试着为Student类加上final修饰符,让他无法被继承,此时看看结果。运行的结果会抛出异常,因为无法生成代理类,这里就不贴出来了,可以自己去试试。

参考资料

  1. https://juejin.cn/post/6844903478582575111#heading-2
  2. https://pdai.tech/md/spring/spring-x-framework-aop-source-1.html#引入
  3. https://www.cnblogs.com/tuyang1129/p/12878549.html
打赏
  • 版权声明: 本博客所有文章除特别声明外,著作权归作者所有。转载请注明出处!
  • Copyrights © 2021-2022 Yin Peng
  • 引擎: Hexo   |  主题:修改自 Ayer
  • 访问人数: | 浏览次数:

请我喝杯咖啡吧~

支付宝
微信