Spring源码阅读MethodInterceptor解析
概述
上一篇详细分析了 ReflectiveMethodInvocation 中的proceed
方法的逻辑,它通过递归的方式,完成拦截器链中增强逻辑的逐层执行。当方法中每次根据索引获取到的当前拦截器需要执行增强逻辑的时候,由于proceed
方法并没有直接在方法体内调用自身,而是调用了拦截器的invoke
方法,之后拦截器的invoke
方法又调用了proceed
方法,因此,每一次递归都是通过proceed
方法和拦截器的invoke
方法共同完成的。
所以,这一篇来分析拦截器的invoke
方法,针对 5 种增强类型,拦截器的具体类型也有 5 种,它们的invoke
方法实现各不相同,本文会逐个分析。
MethodInterceptor 分析
首先,这 5 种拦截器都是 MethodInterceptor 接口的实现,而invoke
方法正是在 MethodInterceptor 接口中定义的。
@FunctionalInterface public interface MethodInterceptor extends Interceptor { Object invoke(MethodInvocation invocation) throws Throwable; }
在invoke
方法被调用的时候,传入的invocation
参数就是之前创建的 ReflectiveMethodInvocation 对象,在invoke
方法的具体实现中,正是通过它调用proceed
方法完成了递归。
在之前的文章中,分析过 JdkDynamicAopProxy 的invoke
方法获取拦截器链的步骤,也从中了解了 5 中增强类型的拦截器的具体类型,它们分别是:
- 实现了 MethodInterceptor 接口的三个 Advice 实现类 AspectJAroundAdvice / AspectJAfterThrowingAdvice / AspectJAfterAdvice
- 两个通过适配器封装了 Advice 对象的拦截器类型 MethodBeforeAdviceInterceptor / AfterReturningAdviceInterceptor。
下面进入分析的环节,分析的主要内容是他们的invoke
方法。
AspectJAroundAdvice 分析
// org.springframework.aop.aspectj.AspectJAroundAdvice#invoke @Override public Object invoke(MethodInvocation mi) throws Throwable { if (!(mi instanceof ProxyMethodInvocation)) { throw new IllegalStateException("MethodInvocation is not a Spring ProxyMethodInvocation: " + mi); } ProxyMethodInvocation pmi = (ProxyMethodInvocation) mi; ProceedingJoinPoint pjp = lazyGetProceedingJoinPoint(pmi); JoinPointMatch jpm = getJoinPointMatch(pmi); return invokeAdviceMethod(pjp, jpm, null, null); }
方法中,首先会确保参数传入的mi是否是是 ProxyMethodInvocation 的实现类,根据前面的逻辑,我们知道这里传入参数的对象是之前创建的 ReflectiveMethodInvocation 对象,前面创建 ReflectiveMethodInvocation 对象的时候,我们曾经分析过它的类关系,它是 ProxyMethodInvocation 接口的实现类。因此,这个方法中后续的流程会正常执行。
接下来,通过lazyGetProceedingJoinPoint
方法得到了一个 ProceedingJoinPoint 对象pjp
,我们看一下这个方法中作了什么。
// org.springframework.aop.aspectj.AspectJAroundAdvice#lazyGetProceedingJoinPoint protected ProceedingJoinPoint lazyGetProceedingJoinPoint(ProxyMethodInvocation rmi) { return new MethodInvocationProceedingJoinPoint(rmi); }
这里的逻辑,就是将invoke方法传入的 MethodInvocation 参数,通过构造方法,封装成了一个 MethodInvocationProceedingJoinPoint 对象,它的构造方法中除了把参数赋值给成员变量,并无更多的逻辑。
public MethodInvocationProceedingJoinPoint(ProxyMethodInvocation methodInvocation) { 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) protected Object invokeAdviceMethod(JoinPoint jp, @Nullable JoinPointMatch jpMatch, @Nullable Object returnValue, @Nullable Throwable t) throws Throwable { return invokeAdviceMethodWithGivenArgs(argBinding(jp, jpMatch, returnValue, t)); }
这个方法的实现在父类 AbstractAspectJAdvice 中,方法只有一句,就是执行invokeAdviceMethodWithGivenArgs
方法并返回结果,在方法的参数中,argBinding
用于根据增强方法的参数列表,来绑定执行增强方法的参数值。我们进入invokeAdviceMethodWithGivenArgs
方法查看。
// org.springframework.aop.aspectj.AbstractAspectJAdvice#invokeAdviceMethodWithGivenArgs protected Object invokeAdviceMethodWithGivenArgs(Object[] args) throws Throwable { Object[] actualArgs = args; if (this.aspectJAdviceMethod.getParameterCount() == 0) { actualArgs = null; } try { ReflectionUtils.makeAccessible(this.aspectJAdviceMethod); // TODO AopUtils.invokeJoinpointUsingReflection return this.aspectJAdviceMethod.invoke(this.aspectInstanceFactory.getAspectInstance(), actualArgs); } catch (IllegalArgumentException ex) { throw new AopInvocationException("Mismatch on arguments to advice method [" + this.aspectJAdviceMethod + "]; pointcut expression [" + this.pointcut.getPointcutExpression() + "]", ex); } catch (InvocationTargetException ex) { throw ex.getTargetException(); } }
这里的逻辑就比较简单了,就是获取到当前拦截器中的增强方法,并通过反射执行这个方法。
我们都知道,AspectJAroundAdvice 是环绕增强,也就是在目标方法执行的前后都有增强逻辑,那么,目标方法(或者下一层拦截器)是什么时候调用的呢?可以通过一个例子来分析。
以下是一个典型的环绕增强的方法:
@Around("point()") public void around(ProceedingJoinPoint proceedingJoinPoint) throws Throwable { 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 @Override public Object invoke(MethodInvocation mi) throws Throwable { try { return mi.proceed(); } catch (Throwable ex) { if (shouldInvokeOnThrowing(ex)) { invokeAdviceMethod(getJoinPointMatch(), null, ex); } throw ex; } }
在 AspectJAfterThrowingAdvice 中,invoke
方法相对更加简单。AspectJAfterThrowingAdvice 是在方法抛出异常后,执行增强逻辑,在invoke
方法中,也能很简单地对应到这样的逻辑。
首先,进入方法后会直接执行mi.proceed()
,也就是执行 ReflectiveMethodInvocation 的proceed
方法的下一层递归,如果后续的执行抛出了异常,则执行catch
语句块中的内容,其中就包含了增强逻辑的执行。
不过,在执行增强逻辑之前,还通过shouldInvokeOnThrowing
方法进行了一次判断,我们查看方判断的逻辑。
// org.springframework.aop.aspectj.AspectJAfterThrowingAdvice#shouldInvokeOnThrowing private boolean shouldInvokeOnThrowing(Throwable ex) { return getDiscoveredThrowingType().isAssignableFrom(ex.getClass()); }
这里的逻辑比较简单,就是只有抛出的异常是增强方法指定的异常或者其子类的时候,才会执行异常抛出后的增强逻辑,否则,不执行增强逻辑,直接将异常抛出。
那如何在增强方法上指定异常的类型呢,我们还是看一个例子:
@AfterThrowing(value = "point()", throwing = "ex") public void afterThrowing(JoinPoint joinPoint, Exception ex) { System.out.println("AfterThrowing..."); }
在以上的例子中,@AfterThrowing
注解指定了throwing
属性为ex
,那么增强方法中,ex
参数的类型 Exception 就是指定的异常类型。
回到invoke
方法中,执行增强逻辑的方式是调用invokeAdviceMethod
方法,与环绕增强的增强方法执行时调用的invokeAdviceMethod
相比,这里少一个参数,也就是 JoinPoint 参数,这是因为 AspectJAfterThrowingAdvice 类型的增强方法并不需要在增强逻辑中处理目标方法的调用,我们进入这个重载方法查看代码。
protected Object invokeAdviceMethod( @Nullable JoinPointMatch jpMatch, @Nullable Object returnValue, @Nullable Throwable ex) throws Throwable { return invokeAdviceMethodWithGivenArgs(argBinding(getJoinPoint(), jpMatch, returnValue, ex)); }
发现,逻辑上并没有什么区别,就只是少绑定一个参数而已。
另外,这里还有一点需要留意,在调用invokeAdviceMethod
方法时,会将抛出的异常对象作为参数传入,这也很好理解 ,因为增强方法中可以包含异常对象的参数。
以上是 AspectJAfterThrowingAdvice 中,增强逻辑的执行过程。
AspectJAfterAdvice 分析
// org.springframework.aop.aspectj.AspectJAfterAdvice#invoke @Override public Object invoke(MethodInvocation mi) throws Throwable { try { return mi.proceed(); } finally { invokeAdviceMethod(getJoinPointMatch(), null, null); } }
在 AspectJAfterAdvice 中,invoke
方法的逻辑更加简单。我们知道,后置增强会在目标方法执行之后再执行,而且,无论是否抛出了一场,都会执行。因此,在invoke
方法中,会先执行 MethodInvocation 的proceed
方法,然后,在finally
语句块中,执行增强方法。
增强方法的执行,仍然是通过invokeAdviceMethod
方法,这里就不再介绍了。
以上是 AspectJAfterAdvice 中,增强逻辑的执行过程。
MethodBeforeAdviceInterceptor 分析
// org.springframework.aop.framework.adapter.MethodBeforeAdviceInterceptor#invoke @Override public Object invoke(MethodInvocation mi) throws Throwable { this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis()); return mi.proceed(); }
前置增强 MethodBeforeAdvice 与上述的三种增强不同,它并不是 MethodInterceptor 的实现类,因此,其对应的拦截器是封装了 MethodBeforeAdvice 的 MethodBeforeAdviceInterceptor。
因为前置增强是在目标方法执行前执行,既然在执行前,则不会涉及到目标方法的异常和返回值,可以说,前置增强的逻辑和目标方法的逻辑,相对比较独立。因此,在上面的invoke方法中,分别执行两者即可。
这里我们看一下前置增强方法逻辑的执行。首先,advice
成员变量就是在 MethodBeforeAdviceInterceptor 中封装的 MethodBeforeAdvice 对象,我们找到它的before
方法,具体实现逻辑在 AspectJMethodBeforeAdvice 中。
// org.springframework.aop.aspectj.AspectJMethodBeforeAdvice#before @Override public void before(Method method, Object[] args, @Nullable Object target) throws Throwable { invokeAdviceMethod(getJoinPointMatch(), null, null); }
可以看到,这里依然是通过invokeAdviceMethod
方法来执行增强逻辑的,与之前的几种增强方法对应的执行逻辑相同。
以上是 MethodBeforeAdviceInterceptor 中,增强逻辑的执行过程。
AfterReturningAdviceInterceptor 分析
// org.springframework.aop.framework.adapter.AfterReturningAdviceInterceptor#invoke @Override public Object invoke(MethodInvocation mi) throws Throwable { Object retVal = mi.proceed(); this.advice.afterReturning(retVal, mi.getMethod(), mi.getArguments(), mi.getThis()); return retVal; }
在 AfterReturningAdviceInterceptor 的invoke
方法中,会先执行 MethodInvocation 的proceed
方法,并获取返回值,然后,在上一步执行没有发生异常的情况下,执行增强方法,最后将proceed
的返回值返回。
增强方法通过调用advice
成员变量的afterReturning
来完成,这里有一点要留意的是,增强逻辑的执行,会将上一步proceed
得返回值作为参数传入。我们进入afterReturning
方法。
// org.springframework.aop.aspectj.AspectJAfterReturningAdvice#afterReturning @Override public void afterReturning(@Nullable Object returnValue, Method method, Object[] args, @Nullable Object target) throws Throwable { if (shouldInvokeOnReturnValueOf(method, returnValue)) { invokeAdviceMethod(getJoinPointMatch(), returnValue, null); } }
具体的实现逻辑在 AspectJAfterReturningAdvice 中,在执行具体的增强逻辑之前,还会进行一次判断,这里的逻辑跟 AspectJAfterThrowingAdvice 中判断异常的逻辑非常相似,shouldInvokeOnReturnValueOf
方法会判断目标方法的返回值类型跟增强方法上面声明的返回值类型是否匹配,只有匹配的情况下,才会执行增强逻辑。
在增强方法上声明返回值类型的方法参考下面的例子:
@AfterReturning(value = "point()", returning = "o") public void afterReturning(Object o) { System.out.println("AfterReturning..."); }
增强方法依然是通过 invokeAdviceMethod 执行的,只不过这里要讲上一步的返回值传入,以便增强方法能够通过参数绑定获得到这个值。
以上是 AfterReturningAdviceInterceptor 中,增强逻辑的执行过程。
总结
本文详细分析了 Spring AOP 中五种增强类型对应的拦截器中增强方法的执行逻辑,结合上一篇中分析的 ReflectiveMethodInvocation 中proceed
方法的执行逻辑,就组成了完整的拦截器链递归调用的逻辑。
以上就是Spring源码阅读MethodInterceptor解析的详细内容,更多关于Spring MethodInterceptor的资料请关注脚本之家其它相关文章!
相关文章
IDEA+maven+SpringBoot+JPA+Thymeleaf实现Crud及分页
这篇文章主要介绍了不需要电脑任何操作基于IDEA + maven + SpringBoot + JPA + Thymeleaf实现CRUD及分页,需要的朋友可以参考下2018-03-03详解SpringBoot实现fastdfs防盗链功能的示例代码
我们可以通过fastdfs实现一个分布式文件系统,如果fastdfs部署在外网,那么任何一个人知道了上传接口,就可以实现文件的上传和访问。那么如何阻止他人访问我们fastdfs服务器上的文件呢?此处就需要使用fastdfs的防盗链功能,本文就来讲讲如何实现这一功能2022-10-10HttpClient的DnsResolver自定义DNS解析另一种选择深入研究
这篇文章主要为大家介绍了HttpClient的DnsResolver自定义DNS解析另一种选择深入研究,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪2023-10-10
最新评论