不正经

这个屌丝很懒，什么也没留下！

热门标签

Spring Aop原理全面详解汇总

作者：不正经 | 2024-05-30 16:40:00

踩

spring aop

近期想法

题外话：最近有在骑车通勤，已经一个多月的时间了，晚上十点半睡，早上六点就醒，感觉还是有所变化，由最初的气喘吁吁变为呼吸均匀，速度也有所提升，也学会大撒把了。很多事情贵在坚持，每天保持一点的技术进步，日积月累就很有效果，既然选择了这条路，便只顾风雨兼程，放平心态，精益求精。（心态最重要也是最难修行的）

该篇主要讲解AOP相关的知识点，其实AOP相关的文章或博客实在是太多了，我还是想着尽量弄一个相对比较全面的，主要还是以我本身的自我理解为主，可能有些理解不够深入或者是有所偏差，也希望大家指出来，以备完善。

什么是AOP

AOP为Aspect Oriented Programming的缩写，意为：面向切面编程，通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。AOP是OOP的延续，是软件开发中的一个热点，也是Spring框架中的一个重要内容，是函数式编程的一种衍生范型。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。
在Spring中提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（transaction）管理）进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。

SpringAOP与Aspectj

在这里插入图片描述
个人理解，AOP是通过“预编译方式”和“运行期间动态代理”实现程序功能的统一维护的一种技术或者说是一种标准。AOP是一个概念，其实现技术有AspectJ和springAOP。springAOP的实现过程中，借用了Aspectj的一些功能，包括@Aspect、@Before、@After、@PonitCut等注解，可以看到这些注解都是org.aspectj.lang.annotation下的。
说明：AspectJ设置LTW，LTW是LoadTimeWeaver，简称LTW，LTW是AOP的一种实现方式，可以再给容器属性赋值的时候进行设置（bean生命周期），本篇不做展开，可自行了解。

SpringAOP体系概述

在这里插入图片描述
当然aop远不止这些，只是提炼了些使用过程中用到更多的一些知识点，包括：概念、处理时机、实现原理（动态代理相关）及AOP的加载流程（这一块会结合源码来看）。接下来会按照这些点展开说明。

概念详解

曾经有段时间，这几个概念我直接理解不了，一度觉得这都是起的什么名字啊，真费解。随着慢慢的理解深入，觉得柳暗花明又一村了。
理解概念是学习任何知识点的第一步，也是深入学习的第一步，因为不论是什么技术，如果只是到会用、功能可以实现的层面那太简单了，但是如果要知其然且知其所以然的话，概念是基础。

连接点- Jointpoint

可切入的地方，是程序执行的一个点。例如，一个方法的执行或者一个异常的处理。在Spring AOP中，一个连接点总是代表一个方法执行。

切入点- Pointcut

粗暴理解就是@PointCut的地方，即为匹配连接点的表达式。在SpringAOP中，一个切入点可以只描述一个具体方法，也可以匹配多个方法。
切入点分为execution方式和annotation方式。execution可以用路径表达式指定哪些类织入切面，annotation可以指定被哪些注解修饰的代码织入切面。如下图：
在这里插入图片描述

通知- Advice

其实就是处理逻辑，包括处理时机及处理操作。处理操作即为我们具体的处理逻辑，常见的包括日志、权限及异常等处理逻辑。而处理时机则指定该处理操作在什么时机进行处理执行，这儿我们说明一下处理时机相关注解概念：

@Before
设置指定的通知处理方法（该注解的value）切入到目标方法之前执行。
@After
设置指定的通知处理方法（该注解的value）切入到目标方法之后执行。
@Around
设置指定的通知处理方法（该注解的value）切入到目标方法前后执行，这个功能强大比较常用。功能约等于@Before+@AfterReturning（后面会讲到）。
注意点:
- @Around通知处理方法的第一个形参必须是ProceedingJoinPoint类型，在通知处理方法体内，调用ProceedingJoinPoint的proceed方法才会执行目标方法。如果程序没有调用ProceedingJoinPoint的proceed方法，则目标方法不会执行。
- 调用ProceedingJoinPoint的proceed方法时，还可以传入一个Object[ ]对象，该数组中的值将被传入目标方法作为实参。如果传入的Object[ ]数组长度与目标方法所需要的参数个数不相等，或者Object[ ]数组元素与目标方法所需参数的类型不匹配，程序就会出现异常。
- 通知处理方法返回类型可以设置为void，如果接收返回值的话，则必须设置为Object。
@AfterReturning
设置指定的通知处理方法切入到目标方法正常执行完毕后运行。

注意点
- pointcut/value这两个属性的作用是一样的，它们都用于指定该切入点对应的切入表达式。可以是一个已有的切入点，也可以直接定义切入点表达式。当指定了pointcut属性后，value属性值将会被覆盖。
- returning 自定义的变量，标识目标方法的返回值，自定义变量名必须和通知方法的形参一样。
@AfterThrowing
设置当前通知处理方法在目标方法方法运行抛出异常后执行。

注意点
- pointcut/value这两个属性的作用是一样的，它们都用于指定该切入点对应的切入表达式。可以是一个已有的切入点，也可以直接定义切入点表达式。当指定了pointcut属性后，value属性值将会被覆盖。
- throwing属性指定一个形参名，用于表示Advice方法中可定义与此同名的形参，该形参可用于访问目标方法抛出的异常。除此之外，在Advice方法中定义该参数时，指定的类型，会限制方法必须抛出指定类型的异常。

切面- Aspect

描述通知与切入点的对应关系。

织入- Weaving

就是通过动态代理，在目标对象方法中执行处理内容的过程。

实现原理—动态代理

Spring的AOP实现原理就是通过动态代理实现的。如果我们为Spring的某个bean配置了切面，那么Spring在创建这个bean的时候，实际上创建的是这个bean的一个代理对象，我们后续对bean中方法的调用，实际上调用的是代理类重写的代理方法。而Spring的AOP使用了两种动态代理，分别是JDK的动态代理，以及CGLib的动态代理。

JDK动态代理

描述

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

原理

JDK的动态代理是基于反射实现。JDK通过反射，生成一个代理类，这个代理类实现了原来那个类的全部接口，并对接口中定义的所有方法进行了代理。当我们通过代理对象执行原来那个类的方法时，代理类底层会通过反射机制，回调我们实现的InvocationHandler接口的invoke方法。并且这个代理类是Proxy类的子类。

代码示例

在 SpringBoot 2.x AOP中会默认使用Cglib来实现，但是Spring5中默认还是使用jdk动态代理。Spring AOP 默认使用 JDK 动态代理，如果对象没有实现接口，则使用 CGLIB 代理。当然，也可以强制使用 CGLIB 代理。
这里通过spring boot来演示下JDK动态代理，我们通过application.properties配置将代理默认设置为JDK代理。

spring.aop.proxy-target-class=false
1

首先需要一个接口及其实现类（放一个代码块里了）：

public interface PhliInterface {
    void testDynamic();
}

@Component
public class PhliServiceImpl implements PhliInterface{
    @Override
    public void testDynamic() {
        System.out.println("目标方法执行");
    }
}
1
2
3
4
5
6
7
8
9
10
11

其次，定义一个切面，将这个testDynamic()方法作为切入点，为它配置一个前置通知，代码如下：

@Component
@Aspect
public class TestAspect {

    @Pointcut("execution(* cn.ph.software.proxy.PhliServiceImpl.*(..))")
    public void pointtest() {
    }

    @Before(value = "pointtest()")
    public void beforetest() {
        System.out.println("目标方法开始之前执行");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

最后，写个controller测试一下：

@RestController
@RequestMapping("/phli")
public class PhliController {
	/**注意，这里只能通过PhliInterface注入，而不能直接注入PhliServiceImpl，因为在容器中，
		使用JDK动态代理，Ioc容器中，存储的是一个类型为PhliInterface的代理对象*/
    @Resource
    private PhliInterface phliInterface;
    @GetMapping("/test")
    public void testPhli() {
        phliInterface.testDynamic();
        System.out.println(phliInterface.getClass().getName());
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

注意

这里没有用到@EnableAspectJAutoProxy注解，下面会讲到。
上面代码中，通过@Resource注入的时候。由于我们需要代理的类实现了接口，则JDK动态代理生成的代理类会实现相同的接口，然后创建一个代理对象存储在Spring容器中。这也就是说，在Spring容器中，这个代理bean的类型不是PhliServiceImpl类型，而是PhliInterface类型，所以我们不能通过PhliServiceImpl。这也说明JDK动态代理无法代理没有定义在接口中的方法。假设PhliServiceImpl这个类有另外一个方法，它不是PhliInterface接口定义的方法，此时就算我们为它配置了切面，也无法将切面织入。而且由于在Spring容器中保存的代理对象并不是PhliServiceImpl类型，而是PhliInterface类型，这就导致我们无法调用不属于PhliInterface的方法。这也是JDK动态代理的局限性。

执行结果

在这里插入图片描述
从结果可知，代理类的父类是Proxy，也就是说明使用的是JDK动态代理。

优点

JDK动态代理是JDK原生的，不需要任何依赖即可使用。
通过反射机制生成代理类的速度要比CGLib操作字节码生成代理类的速度更快。

缺点

要使用JDK动态代理，被代理的类必须实现了接口，否则无法代理。
JDK动态代理无法为没有在接口中定义的方法实现代理，这就是上面所提到的局限性。
JDK动态代理执行代理方法时，通过反射机制进行回调，方法执行的效率比较低。

CGLib动态代理

描述

JDK的动态代理存在限制，那就是被代理的类必须是一个实现了接口的类，代理类需要实现相同的接口，代理接口中声明的方法。若需要代理的类没有实现接口，此时JDK的动态代理将没有办法使用，于是Spring会使用CGLib的动态代理来生成代理对象。CGLib直接操作字节码，生成类的子类，重写类的方法完成代理。

原理

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

代码示例

跟JDK动态代理代码类似，把application.properties里面的配置去掉或者是改为true：

spring.aop.proxy-target-class=true
1

controller代码调整如下：

@RestController
@RequestMapping("/phli")
public class PhliController {
    //直接注入PhliServiceImpl
    @Resource
    private PhliServiceImpl phliService;
    @GetMapping("/test")
    public void testPhli() {
        phliService.testDynamic();
        System.out.println(phliService.getClass().getName());
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

注意

CGLib动态代理是生成了PhliServiceImpl的一个子类，所以这个代理对象也是PhliServiceImpl类型（子类也是父类类型），所以可以直接注入PhliServiceImpl。
因为是生成的子类，如果将testDynamic方法添加final修饰符，可以预料到testDynamic方法配置的前置通知不会执行，也就是代理类并没有为testDynamic方法进行代理。因为CGLib无法代理final方法，因为子类无法重写父类的final方法。（这儿就不做代码示例了，final的代码示例大家可以自己测试下）

执行结果

在这里插入图片描述
可以看到通知处理逻辑在目标方法之前执行，且使用的CGLib动态代理。

优点

CGLib代理的类，不需要实现接口，因为是直接继承自需要被代理的类。
CGLib生成的代理类是被代理类的子类。
CGLib生成的代理类，和我们自己编写并编译的类没有太大区别，对方法的调用和直接调用普通类的方式一致，所以CGLib执行代理方法的效率要高于JDK的动态代理。

缺点

CGLib使用的是继承，如果要被代理的类是一个final类，则无法使用CGLib代理；
由于CGLib实现代理方法的方式是重写父类的方法，所以无法对final方法，或者private方法进行代理，因为子类无法重写这些方法；
CGLib生成代理类的方式是通过操作字节码，这种方式生成代理类的速度要比JDK通过反射生成代理类的速度更慢（理论上而言，一般场景下无感知）。

加载过程

这儿会涉及到源码，其实看源码的过程也是学习的过程，虽然有的时候看源码也看不下去，但是也得看啊。。。

不加@EnableAspectJAutoProxy？

之前在动态代理的代码示例部分提到了@EnableAspectJAutoProxy注解，这个注解用于开启aop支持，但是在实例代码部分没有体现，因为在pom文件中有spring-boot-starter-web相关依赖：

<dependency>
   <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>2.5.0</version>
</dependency>
1
2
3
4
5

该依赖会引入spring-boot-autoconfigure的依赖，这是自动装配的依赖，也就是会读取其下的spring.factories文件，在该文件中有下面的配置：
在这里插入图片描述
可以简单看下AopAutoConfiguration这个类

说明

AopAutoConfiguration等同于@EnableAspectJAutoProxy注解，该类起的作用和@EnableAspectJAutoProxy是一样的。
该类上的注解@ConditionalOnProperty，指的是在配置文件中”spring.aop.auto“的配置，如果不配置则为true。可以预料到如果将spring.aop.auto设置为false的话动态代理不会生效。
可以看到上述的代码示例的动态代理类并没有生成，aop没有生效。
在spring.aop.auto=false基础上，在Application启动类上添加@EnableAspectJAutoProxy，再次执行：

可以看到CGLib动态代理生效。

综上，在springboot环境下，由于存在spring-boot-autoconfigure依赖，默认会注入AopAutoConfiguration配置类，该类的作用等同于@EnableAspectJAutoProxy注解，所以在这种情况下可以不加@EnableAspectJAutoProxy注解，AopAutoConfiguration可以通过spring.aop.auto属性控制。

@EnableAspectJAutoProxy源码分析

为方便理解，当然也是为了方便自己梳理，每一步都添加相关说明。

进入@EnableAspectJAutoProxy:
- @Import({AspectJAutoProxyRegistrar.class})：将AspectJAutoProxyRegistrar类注入到Spring IOC容器中被当前Spring管理。
- proxyTargetClass：控制是基于子类继承的CGLIB动态代理还是使用基于接口的JDK动态代理，proxyTargetClass默认是false。
- exposeProxy：控制代理的暴露方式，默认为false，如果设置为true的话，我们就可以通过AopContext.currentProxy()很容易拿到当前代理对象，这在解决Spring事务失效的方法自调用场景下很有用。
进入AspectJAutoProxyRegistrar：
- ImportBeanDefinitionRegistrar接口是也是spring的扩展点之一，它可以支持我们自己写的代码封装成BeanDefinition对象，实现此接口的类会回调postProcessBeanDefinitionRegistry方法，注册到spring容器中。把bean注入到spring容器不止有 @Service @Component等注解方式，还可以实现此接口。
- AopConfigUtils.registerAspectJAnnotationAutoProxyCreatorIfNecessary(registry)，这是真正执行逻辑。
- proxyTargetClass及exposeProxy默认为false，第三部分红框标注部分不执行。
进入registerAspectJAnnotationAutoProxyCreatorIfNecessary方法：
- 可以看下registerOrEscalateApcAsRequired方法，它利用AspectJAutoProxyRegistrar往IOC容器中注册了AnnotationAwareAspectJAutoProxyCreator定义信息，并且名称为name为"org.springframework.aop.config.internalAutoProxyCreator"。@EnableAspectJAutoProxy注解最终往容器中注入了AnnotationAwareAspectJAutoProxyCreator。
接下来着重看一下AnnotationAwareAspectJAutoProxyCreator
查看一下该类的类关系图：
- BeanPostProcessor这个就不多说了，不是本篇的重点，从字面上 BeanPostProcessor 的意思就是 Bean 的后置处理器。主要作用就是帮助我们在bean实例化之后，初始化前后做一些事情，是spring常用的拓展接口。实现该接口是可以支持生成一个bean的代理对象的。
- 重点查看下AnnotationAwareAspectJAutoProxyCreator及其子类所实现的postProcessBeforeInitialization()、postProcessAfterInitialization方法是否包含有生成代理对象的处理逻辑。
- 还有BeanFactoryAware、BeanClassLoaderAware接口，Aware接口的作用是让Bean能拿到容器的一些资源，例如BeanNameAware可以拿到BeanName。所以这两个接口可以保证AnnotationAwareAspectJAutoProxyCreator获取到目标Bean的类加载器和当前的IOC容器，获取类加载器及IOC容器保证了为后续生成代理对象提供了前提。
经过排查定位查找到父类AbstractAutoProxyCreator中包含有postProcessAfterInitialization方法，该方法在bean初始化完成后执行，查看该方法注释得知，生成创建代理对象的逻辑就在这儿！！
查看wrapIfNecessary方法：
继续跟踪查看createProxy方法，该方法最后一行：