Spring 源码阅读 69:基于 JDK 的 AOP 代理拦截器链执行(3)- MethodInterceptor 分析

简介: 【1月更文挑战第4天】本文详细分析了 Spring AOP 中五种增强类型对应的拦截器中增强方法的执行逻辑,结合上一篇中分析的 ReflectiveMethodInvocation 中proceed方法的执行逻辑,就组成了完整的拦截器链递归调用的逻辑。

本文详细分析了 Spring AOP 中五种增强类型对应的拦截器中增强方法的执行逻辑,结合上一篇中分析的 ReflectiveMethodInvocation 中proceed方法的执行逻辑,就组成了完整的拦截器链递归调用的逻辑。

基于 Spring Framework v5.2.6.RELEASE

相关阅读:Spring 源码阅读 61:基于 JDK 动态代理的 AOP 代理回调方法 invoke 分析

接上一篇:Spring 源码阅读 68:基于 JDK 的 AOP 代理拦截器链执行(2)- ReflectiveMethodInvocation 分析

概述

上一篇详细分析了 ReflectiveMethodInvocation 中的proceed方法的逻辑,它通过递归的方式,完成拦截器链中增强逻辑的逐层执行。当方法中每次根据索引获取到的当前拦截器需要执行增强逻辑的时候,由于proceed方法并没有直接在方法体内调用自身,而是调用了拦截器的invoke方法,之后拦截器的invoke方法又调用了proceed方法,因此,每一次递归都是通过proceed方法和拦截器的invoke方法共同完成的。

所以,这一篇来分析拦截器的invoke方法,针对 5 种增强类型,拦截器的具体类型也有 5 种,它们的invoke方法实现各不相同,本文会逐个分析。

MethodInterceptor 分析

首先,这 5 种拦截器都是 MethodInterceptor 接口的实现,而invoke方法正是在 MethodInterceptor 接口中定义的。

@FunctionalInterfacepublicinterfaceMethodInterceptorextendsInterceptor {
Objectinvoke(MethodInvocationinvocation) throwsThrowable;
}

invoke方法被调用的时候,传入的invocation参数就是之前创建的 ReflectiveMethodInvocation 对象,在invoke方法的具体实现中,正是通过它调用proceed方法完成了递归。

在之前的文章中,分析过 JdkDynamicAopProxy 的invoke方法获取拦截器链的步骤,也从中了解了 5 中增强类型的拦截器的具体类型,它们分别是:

  • 实现了 MethodInterceptor 接口的三个 Advice 实现类 AspectJAroundAdvice / AspectJAfterThrowingAdvice / AspectJAfterAdvice
  • 两个通过适配器封装了 Advice 对象的拦截器类型 MethodBeforeAdviceInterceptor / AfterReturningAdviceInterceptor。

下面进入分析的环节,分析的主要内容是他们的invoke方法。

AspectJAroundAdvice 分析

// org.springframework.aop.aspectj.AspectJAroundAdvice#invoke@OverridepublicObjectinvoke(MethodInvocationmi) throwsThrowable {
if (!(miinstanceofProxyMethodInvocation)) {
thrownewIllegalStateException("MethodInvocation is not a Spring ProxyMethodInvocation: "+mi);
   }
ProxyMethodInvocationpmi= (ProxyMethodInvocation) mi;
ProceedingJoinPointpjp=lazyGetProceedingJoinPoint(pmi);
JoinPointMatchjpm=getJoinPointMatch(pmi);
returninvokeAdviceMethod(pjp, jpm, null, null);
}

方法中,首先会确保参数传入的mi是否是是 ProxyMethodInvocation 的实现类,根据前面的逻辑,我们知道这里传入参数的对象是之前创建的 ReflectiveMethodInvocation 对象,前面创建 ReflectiveMethodInvocation 对象的时候,我们曾经分析过它的类关系,它是 ProxyMethodInvocation 接口的实现类。因此,这个方法中后续的流程会正常执行。

接下来,通过lazyGetProceedingJoinPoint方法得到了一个 ProceedingJoinPoint 对象pjp,我们看一下这个方法中作了什么。

// org.springframework.aop.aspectj.AspectJAroundAdvice#lazyGetProceedingJoinPointprotectedProceedingJoinPointlazyGetProceedingJoinPoint(ProxyMethodInvocationrmi) {
returnnewMethodInvocationProceedingJoinPoint(rmi);
}

这里的逻辑,就是将invoke方法传入的 MethodInvocation 参数,通过构造方法,封装成了一个 MethodInvocationProceedingJoinPoint 对象,它的构造方法中除了把参数赋值给成员变量,并无更多的逻辑。

publicMethodInvocationProceedingJoinPoint(ProxyMethodInvocationmethodInvocation) {
Assert.notNull(methodInvocation, "MethodInvocation must not be null");
this.methodInvocation=methodInvocation;
}

回到invoke方法中,下一步是通过getJoinPointMatch方法获取到一个 JoinPointMatch 对象,它会在之后绑定增强方法的参数值时用到。

方法的最后,就是执行invokeAdviceMethod方法,从它的名字可以看出,这里就是执行增强方法的逻辑,我们进入这个方法查看。

// org.springframework.aop.aspectj.AbstractAspectJAdvice#invokeAdviceMethod(org.aspectj.lang.JoinPoint, org.aspectj.weaver.tools.JoinPointMatch, java.lang.Object, java.lang.Throwable)protectedObjectinvokeAdviceMethod(JoinPointjp, @NullableJoinPointMatchjpMatch,
@NullableObjectreturnValue, @NullableThrowablet) throwsThrowable {
returninvokeAdviceMethodWithGivenArgs(argBinding(jp, jpMatch, returnValue, t));
}

这个方法的实现在父类 AbstractAspectJAdvice 中,方法只有一句,就是执行invokeAdviceMethodWithGivenArgs方法并返回结果,在方法的参数中,argBinding用于根据增强方法的参数列表,来绑定执行增强方法的参数值。我们进入invokeAdviceMethodWithGivenArgs方法查看。

// org.springframework.aop.aspectj.AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgsprotectedObjectinvokeAdviceMethodWithGivenArgs(Object[] args) throwsThrowable {
Object[] actualArgs=args;
if (this.aspectJAdviceMethod.getParameterCount() ==0) {
actualArgs=null;
   }
try {
ReflectionUtils.makeAccessible(this.aspectJAdviceMethod);
// TODO AopUtils.invokeJoinpointUsingReflectionreturnthis.aspectJAdviceMethod.invoke(this.aspectInstanceFactory.getAspectInstance(), actualArgs);
   }
catch (IllegalArgumentExceptionex) {
thrownewAopInvocationException("Mismatch on arguments to advice method ["+this.aspectJAdviceMethod+"]; pointcut expression ["+this.pointcut.getPointcutExpression() +"]", ex);
   }
catch (InvocationTargetExceptionex) {
throwex.getTargetException();
   }
}

这里的逻辑就比较简单了,就是获取到当前拦截器中的增强方法,并通过反射执行这个方法。

我们都知道,AspectJAroundAdvice 是环绕增强,也就是在目标方法执行的前后都有增强逻辑,那么,目标方法(或者下一层拦截器)是什么时候调用的呢?可以通过一个例子来分析。

以下是一个典型的环绕增强的方法:

@Around("point()")
publicvoidaround(ProceedingJoinPointproceedingJoinPoint) throwsThrowable {
System.out.println("Around Before ...");
// 被增强的方法proceedingJoinPoint.proceed();
System.out.println("Around After ...");
}

在一个环绕增强的方法中,会通过方法参数中,代表当前连接点的 ProceedingJoinPoint 对象的proceed()来执行目标方法(或者下一层拦截器),其实就是调用了我们上一篇中分析的 ReflectiveMethodInvocation 的proceed方法。而这个方法被调用时,参数中的 ProceedingJoinPoint 的值,是在前面的步骤中,argBinding方法中进行绑定的。

以上就是 AspectJAroundAdvice 中,增强逻辑的执行过程。

AspectJAfterThrowingAdvice 分析

// org.springframework.aop.aspectj.AspectJAfterThrowingAdvice#invoke@OverridepublicObjectinvoke(MethodInvocationmi) throwsThrowable {
try {
returnmi.proceed();
   }
catch (Throwableex) {
if (shouldInvokeOnThrowing(ex)) {
invokeAdviceMethod(getJoinPointMatch(), null, ex);
      }
throwex;
   }
}

在 AspectJAfterThrowingAdvice 中,invoke方法相对更加简单。AspectJAfterThrowingAdvice 是在方法抛出异常后,执行增强逻辑,在invoke方法中,也能很简单地对应到这样的逻辑。

首先,进入方法后会直接执行mi.proceed(),也就是执行 ReflectiveMethodInvocation 的proceed方法的下一层递归,如果后续的执行抛出了异常,则执行catch语句块中的内容,其中就包含了增强逻辑的执行。

不过,在执行增强逻辑之前,还通过shouldInvokeOnThrowing方法进行了一次判断,我们查看方判断的逻辑。

// org.springframework.aop.aspectj.AspectJAfterThrowingAdvice#shouldInvokeOnThrowingprivatebooleanshouldInvokeOnThrowing(Throwableex) {
returngetDiscoveredThrowingType().isAssignableFrom(ex.getClass());
}

这里的逻辑比较简单,就是只有抛出的异常是增强方法指定的异常或者其子类的时候,才会执行异常抛出后的增强逻辑,否则,不执行增强逻辑,直接将异常抛出。

那如何在增强方法上指定异常的类型呢,我们还是看一个例子:

@AfterThrowing(value="point()", throwing="ex")
publicvoidafterThrowing(JoinPointjoinPoint, Exceptionex) {
System.out.println("AfterThrowing...");
}

在以上的例子中,@AfterThrowing注解指定了throwing属性为ex,那么增强方法中,ex参数的类型 Exception 就是指定的异常类型。

回到invoke方法中,执行增强逻辑的方式是调用invokeAdviceMethod方法,与环绕增强的增强方法执行时调用的invokeAdviceMethod相比,这里少一个参数,也就是 JoinPoint 参数,这是因为 AspectJAfterThrowingAdvice 类型的增强方法并不需要在增强逻辑中处理目标方法的调用,我们进入这个重载方法查看代码。

protectedObjectinvokeAdviceMethod(
@NullableJoinPointMatchjpMatch, @NullableObjectreturnValue, @NullableThrowableex)
throwsThrowable {
returninvokeAdviceMethodWithGivenArgs(argBinding(getJoinPoint(), jpMatch, returnValue, ex));
}

发现,逻辑上并没有什么区别,就只是少绑定一个参数而已。

另外,这里还有一点需要留意,在调用invokeAdviceMethod方法时,会将抛出的异常对象作为参数传入,这也很好理解 ,因为增强方法中可以包含异常对象的参数。

以上是 AspectJAfterThrowingAdvice 中,增强逻辑的执行过程。

AspectJAfterAdvice 分析

// org.springframework.aop.aspectj.AspectJAfterAdvice#invoke@OverridepublicObjectinvoke(MethodInvocationmi) throwsThrowable {
try {
returnmi.proceed();
   }
finally {
invokeAdviceMethod(getJoinPointMatch(), null, null);
   }
}

在 AspectJAfterAdvice 中,invoke方法的逻辑更加简单。我们知道,后置增强会在目标方法执行之后再执行,而且,无论是否抛出了一场,都会执行。因此,在invoke方法中,会先执行 MethodInvocation 的proceed方法,然后,在finally语句块中,执行增强方法。

增强方法的执行,仍然是通过invokeAdviceMethod方法,这里就不再介绍了。

以上是 AspectJAfterAdvice 中,增强逻辑的执行过程。

MethodBeforeAdviceInterceptor 分析

// org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor#invoke@OverridepublicObjectinvoke(MethodInvocationmi) throwsThrowable {
this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis());
returnmi.proceed();
}

前置增强 MethodBeforeAdvice 与上述的三种增强不同,它并不是 MethodInterceptor 的实现类,因此,其对应的拦截器是封装了 MethodBeforeAdvice 的 MethodBeforeAdviceInterceptor。

因为前置增强是在目标方法执行前执行,既然在执行前,则不会涉及到目标方法的异常和返回值,可以说,前置增强的逻辑和目标方法的逻辑,相对比较独立。因此,在上面的invoke方法中,分别执行两者即可。

这里我们看一下前置增强方法逻辑的执行。首先,advice成员变量就是在 MethodBeforeAdviceInterceptor 中封装的 MethodBeforeAdvice 对象,我们找到它的before方法,具体实现逻辑在 AspectJMethodBeforeAdvice 中。

// org.springframework.aop.aspectj.AspectJMethodBeforeAdvice#before@Overridepublicvoidbefore(Methodmethod, Object[] args, @NullableObjecttarget) throwsThrowable {
invokeAdviceMethod(getJoinPointMatch(), null, null);
}

可以看到,这里依然是通过invokeAdviceMethod方法来执行增强逻辑的,与之前的几种增强方法对应的执行逻辑相同。

以上是 MethodBeforeAdviceInterceptor 中,增强逻辑的执行过程。

AfterReturningAdviceInterceptor 分析

// org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor#invoke@OverridepublicObjectinvoke(MethodInvocationmi) throwsThrowable {
ObjectretVal=mi.proceed();
this.advice.afterReturning(retVal, mi.getMethod(), mi.getArguments(), mi.getThis());
returnretVal;
}

在 AfterReturningAdviceInterceptor 的invoke方法中,会先执行 MethodInvocation 的proceed方法,并获取返回值,然后,在上一步执行没有发生异常的情况下,执行增强方法,最后将proceed的返回值返回。

增强方法通过调用advice成员变量的afterReturning来完成,这里有一点要留意的是,增强逻辑的执行,会将上一步proceed得返回值作为参数传入。我们进入afterReturning方法。

// org.springframework.aop.aspectj.AspectJAfterReturningAdvice#afterReturning@OverridepublicvoidafterReturning(@NullableObjectreturnValue, Methodmethod, Object[] args, @NullableObjecttarget) throwsThrowable {
if (shouldInvokeOnReturnValueOf(method, returnValue)) {
invokeAdviceMethod(getJoinPointMatch(), returnValue, null);
   }
}

具体的实现逻辑在 AspectJAfterReturningAdvice 中,在执行具体的增强逻辑之前,还会进行一次判断,这里的逻辑跟 AspectJAfterThrowingAdvice 中判断异常的逻辑非常相似,shouldInvokeOnReturnValueOf方法会判断目标方法的返回值类型跟增强方法上面声明的返回值类型是否匹配,只有匹配的情况下,才会执行增强逻辑。

在增强方法上声明返回值类型的方法参考下面的例子:

@AfterReturning(value="point()", returning="o")
publicvoidafterReturning(Objecto) {
System.out.println("AfterReturning...");
}

增强方法依然是通过 invokeAdviceMethod 执行的,只不过这里要讲上一步的返回值传入,以便增强方法能够通过参数绑定获得到这个值。

以上是 AfterReturningAdviceInterceptor 中,增强逻辑的执行过程。

总结

本文详细分析了 Spring AOP 中五种增强类型对应的拦截器中增强方法的执行逻辑,结合上一篇中分析的 ReflectiveMethodInvocation 中proceed方法的执行逻辑,就组成了完整的拦截器链递归调用的逻辑。

目录
相关文章
|
1月前
|
设计模式 Java Maven
Spring Aop 底层责任链思路实现-springaopdi-ceng-ze-ren-lian-si-lu-shi-xian
Spring Aop 底层责任链思路实现-springaopdi-ceng-ze-ren-lian-si-lu-shi-xian
35 1
|
24天前
|
XML Java Maven
Spring之Aop的注解使用
Spring之Aop的注解使用
|
30天前
|
Java Spring
Spring 如何实现 AOP
Spring 如何实现 AOP
17 0
|
30天前
|
Java 应用服务中间件 Maven
SpringBoot 项目瘦身指南
SpringBoot 项目瘦身指南
43 0
|
2月前
|
缓存 Java Maven
Spring Boot自动配置原理
Spring Boot自动配置原理
48 0
|
1月前
|
缓存 安全 Java
Spring Boot 面试题及答案整理,最新面试题
Spring Boot 面试题及答案整理,最新面试题
111 0
|
1月前
|
前端开发 搜索推荐 Java
【Spring底层原理高级进阶】基于Spring Boot和Spring WebFlux的实时推荐系统的核心:响应式编程与 WebFlux 的颠覆性变革
【Spring底层原理高级进阶】基于Spring Boot和Spring WebFlux的实时推荐系统的核心:响应式编程与 WebFlux 的颠覆性变革
|
18天前
|
前端开发 Java 应用服务中间件
Springboot对MVC、tomcat扩展配置
Springboot对MVC、tomcat扩展配置
|
9天前
|
安全 Java 应用服务中间件
江帅帅:Spring Boot 底层级探索系列 03 - 简单配置
江帅帅:Spring Boot 底层级探索系列 03 - 简单配置
25 0
江帅帅:Spring Boot 底层级探索系列 03 - 简单配置
|
11天前
|
XML Java C++
【Spring系列】Sping VS Sping Boot区别与联系
【4月更文挑战第2天】Spring系列第一课:Spring Boot 能力介绍及简单实践
【Spring系列】Sping VS Sping Boot区别与联系