原文网址：Spring之AOP系列--使用场景/原理_IT利刃出鞘的博客-CSDN博客

简介

本文介绍Spring AOP的使用场景、原理、配置、使用方式。

(资料图片仅供参考)

AOP使用场景

Spring AOP解决了什么问题？

问题使用SpringAOP之后

除了核心逻辑，还要关注非核心逻辑把非核心业务封装起来，只写核心业务即可

代码重复率高（比如输出同样的日志格式）公共非核心的封装起来，格式在公共部分给出即可。

使用场景

权限管理、异常处理、操作日志、事务控制。

实际项目中AOP的用法

权限管理 情景1：控制用户的功能权限 方案详述：在@ControllerAdvice里边，处理全局请求，控制权限。权限管理的其他方案：（除了AOP之外的方案） 在过滤器或者拦截器中处理使用Shiro中间件异常处理 情景1：在@ControllerAdvice里边，处理全局异常情景2：将Dubbo接口作为切面，统一处理Dubbo接口里边的异常操作日志 情景1：按产品的需求，有的接口需要记录操作日志 自定义注解，需要记录操作日志的，则在Controller的方法上加此注解AOP中判断，如果有这个自定义注解，则将参数异步写到日志数据库将数据同步到ES 情景1：增删改数据时，同时要处理MySQL和ES 将相关类作为切面，若数据库提交，则写到ES；若回滚，则不写到ES事务控制 情景1：使用Spring的@Transactional

AOP有哪几种通知，如果方法执行失败，哪个通知不会执行？

前置，后置，环绕，返回，异常。失败后，返回不会执行（即使失败，后置也会执行）。

AOP原理（实现方式）

Spring AOP的动态代理主要有两种方式实现，JDK动态代理和cglib动态代理。 见：Java设计模式--代理模式--静态代理/动态代理--使用/详解/实例_IT利刃出鞘的博客-CSDN博客

项JDK动态代理cglib动态代理

类名java.lang.reflect.InvocationHandlerorg.springframework.cglib.proxy包下的原生接口源自cglib库。

方法拦截器public Object invoke(Object proxy, Method method, Object[] args) throws Throwable;org.springframework.cglib.proxy.Callback、 org.springframework.cglib.proxy.MethodInterceptor

public interface MethodInterceptor extends Callback {Object intercept(Object obj, Method m, Object[] args, MethodProxy mp) throws Throwable }

调用方法method.invoke(Object, args)

该动态代理是基于接口的动态代理，所以并没有一个原始方法的调用过程，整个方法都是被拦截的。调用其他同类对象的原方法：mp.invoke(Object obj, Object[] args)

调用原始(父类)方法：mp.invokeSuper(Object obj, Object[] args)

SpringBoot对AOP的配置

简介

如果引入的是spring-aop包，则需要使用@EnableAspectJAutoProxy开启aop功能；如果引入的是spring-boot-starter-aop，则AOP就直接可以用了，无需加注解之类的开启它。

对于SpringBoot

spring-boot-starter-aop  （此包里包含了spring-aop与aspectjweaver）

对于Spring

spring-aop：AOP核心功能，例如代理工厂等等aspectjweaver：支持切入点表达式、aop相关注解等。（本依赖包含aspectjrt） aspectjrt：支持aop相关注解等。

AOP的启用

导入包即可，默认开启：spring.aop.auto=true  //等价于@EnableAspectJAutoProxy

JDK代理与CGLIB代理

SpringBoot 1.5.x：默认使用JDK代理，即：spring.aop.proxy-target-class=false  若设置为true，则使用CGLIB动态代理。 SpringBoot 2.x：默认使用CGLIB代理，即：spring.aop.proxy-target-class=true。

对应的自动配置类为：org.springframework.boot.autoconfigure.aop.AopAutoConfiguration

为什么SpringBoot 2.x：默认使用CGLIB代理？

见spring的issue：https://github.com/spring-projects/spring-boot/issues/5423

即：我们应该使用@EnableTransactionManagement(proxyTargetClass = true)来防止人们不使用接口时出现讨厌的代理问题。

讨厌的代理问题

假设，我们有一个UserServiceImpl和UserService类，此时需要在UserContoller中使用UserService。在 Spring 中通常都习惯这样写代码：

@AutowiredUserService userService;

在这种情况下，无论是使用 JDK 动态代理，还是 CGLIB 都不会出现问题。

但是，如果你的代码是这样的呢：

@AutowiredUserServiceImpl userService;

这个时候，如果我们是使用 JDK 动态代理，那在启动时就会报错：

SpringAOP与 Aspectj

注意

SpringAOP功能已经基本够用了，除非要在接口上动态代理或者方法拦截精确到getter和setter。这些奇葩的需求，一般不使用Aspectj。

问题：既然一般用不到Aspectj，为什么都要引入Aspectjweaver包？

答案

SpringAOP如果使用xml来配置，是不需要引入Aspectjweaver包的。项目中引入Aspectjweaver包仅仅是为了使用它的注解和切入点表达式。SpringAOP在运行时，用的核心功能是它自己的那一套（动态代理），与Aspectj的编译器或者织入器无任何关系。

无论是使用spring aop还是 aspectj都需要aspectjweaver.jar spring-aop.jar这两个jar包。

简介

项Spring AOPAspectJ

织入时机只能运行时织入。支持编译时、编译后和加载时织入。不支持运行时织入

原理代理由目标对象创建的, 且切面应用在这些代理上运行前织入。

性能比 AspectJ 慢多了更好的性能

切入(编织)位置仅支持方法切入点。且只匹配public方法支持所有切入点：

public, protected, private皆可。

字段、方法、构造函数、静态初始值设定项、最终类/方法等皆可

管理的类只能在由 Spring 容器管理的 bean 上实现可在所有域对象上实现

编程语言在纯 Java 中实现使用 Java 编程语言的扩展实现。

目标

Spring aop 旨在提供一个跨 Spring IoC 的简单的 aop 实现, 以解决程序员面临的最常见问题。它不打算作为一个完整的 AOP 解决方案 —— 它只能应用于由 Spring 容器管理的 bean

AspectJ 是原始的 aop 技术, 目的是提供完整的 aop 解决方案。它更健壮, 但也比 Spring AOP 复杂得多。还值得注意的是, AspectJ 可以在所有域对象中应用。

织入

AspectJ 和 Spring AOP 都使用不同类型的编织, 这会影响它们在性能和易用性方面的行为。

AspectJ 使用三种不同类型的Weaving: 1.编译时 Weaving: AspectJ 编译器作为输入我们的方面的源代码和我们的应用, 并产生一个织入类文件作为输出； 2.编译后 Weaving: 这也称为二进制织入。它是用来织入现有的类文件和 JAR 文件与我们的方面； 3.加载时间 Weaving: 这就像前二进制织入, 不同的是织入被推迟, 直到类加载程序加载类文件到 JVM。

内部结构与应用

Spring aop 是基于代理的 aop 框架。这意味着, 要实现目标对象的各个方面, 它将创建该对象的代理。使用以下两种方法之一实现: 1.JDK 动态代理 —— Spring AOP 的首选方式。只要目标对象实现甚至一个接口, 就会使用 JDK 动态代理； 2.CGLIB 代理 —— 如果目标对象没有实现接口, 则可以使用 CGLIB 代理。 我们可以从 官方文档 中了解有关 Spring AOP 代理机制的更多信息。

AspectJ 在运行时不做任何事情, 因为类是直接用方面进行编译的。 与 Spring AOP 不同, 它不需要任何设计模式。为了编织代码的各个方面, 它引入了称为 AspectJ 编译器 (ajc) 的编译器, 通过它编译我们的程序, 然后通过提供一个小型 (100K) 运行时库来运行它。

joinpoints

Spring AOP 是基于代理模式的。因此, 它需要将目标 Java 类分类, 并相应地应用交叉问题。但这是有限制的。我们不能在 "最终" 类中应用交叉问题 (或方面), 因为它们不能被重写, 因此会导致运行时异常。同样适用于静态和最终方法。不能将 Spring 方面应用于它们, 因为它们不能被覆盖。因此, 由于这些限制, Spring AOP 只支持方法执行连接点。

AspectJ 在运行前直接将横切关注点编织到实际代码中。与 Spring AOP 不同, 它不需要对目标对象进行子类, 因此也支持许多其他 joinpoints。

支持的 joinpoints 的摘要:

JoinpointSpring AOP SupportedAspectJ Supported

Method CallNoYes

Method ExecutionYesYes

Constructor CallNoYes

Constructor ExecutionNoYes

Static initializer executionNoYes

Object initializationNoYes

Field referenceNoYes

Field assignmentNoYes

Handler executionNoYes

Advice executionNoYes

简单性

Spring AOP 显然更简单, 因为它不会在我们的构建过程中引入任何额外的编译器或织入。它使用运行时编织, 因此它与我们通常的构建过程无缝集成。虽然它看起来很简单, 但它只适用于由 Spring 管理的 bean。

AspectJ：我们需要引入 AspectJ 编译器 (ajc) 并重新打包所有的库 (除非我们切换到编译后或加载时间的织入)。当然,，这比前者更复杂,，因为它引入了 AspectJ Java 工具 (包括编译器 (ajc)、调试器 (ajdb)、文档生成器 (ajdoc)、程序结构浏览器 (ajbrowser))，我们需要将它们与我们的 IDE 或构建工具集成。

性能

就性能而言,，编译时织入比运行时织入快得多。

Spring AOP 是基于代理的框架, 因此在应用程序启动时会创建代理。另外, 每个方面还有一些方法调用, 这会对性能产生负面影响。

AspectJ 在应用程序执行之前将这些方面编织到主代码中, 因此没有额外的运行时开销, 与 Spring AOP 不同。

基于这些原因,，AspectJ 的速度几乎比 Spring AOP 快8到35倍。

这两个框架是完全兼容的。 我们可以随时利用Spring AOP，并且仍然使用AspectJ来获得前者不支持的连接点。

其他网址

原理

Java设计模式--静态代理与动态代理_IT利刃出鞘的博客-CSDN博客Spring中的AOP原理_Java_ChaunceyChen的博客-CSDN博客Spring AOP实现原理_Java_yanweihpu的博客-CSDN博客

实现方式

springCloud AOP功能实现 - 尘叙缘的个人空间 - OSCHINA - 中文开源技术交流社区

Spring 5 AOP 默认改用 CGLIB 了？从现象到源码的深度分析 - 云+社区 - 腾讯云