Spring-AOP源码分析随手记(二)

你的名字 2023-06-20 06:19 129阅读 0赞

这次来分析下切面的执行过程。

1.怎么看？

怎么开始看源码呢？就直接从被增强的方法调用那里打断点，看看怎么执行的：

![image][]

然后就来到了这：

![image][image 1]

![image][image 2]

2.初步分析

里面有段：

if (this.advised.exposeProxy) {
       // Make invocation available if necessary.
       oldProxy = AopContext.setCurrentProxy(proxy);
       setProxyContext = true;
    }

就是上篇文章讲到的注解配置暴露代理对象，放到AopContext的ThreadLocal里去，之后就可以随时用 AopContext.currentProxy())取到代理对象。

接下来有段重要的：

List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

获取拦截器链，就是把这次相关的增强器转化成拦截器获取出来

然后：

if (chain.isEmpty()) {
       // We can skip creating a MethodInvocation: just invoke the target directly
       // Note that the final invoker must be an InvokerInterceptor so we know it does
       // nothing but a reflective operation on the target, and no hot swapping or fancy proxying.
       Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
       retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);
    }
    else {
       // We need to create a method invocation...
       invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
       // Proceed to the joinpoint through the interceptor chain.
       retVal = invocation.proceed();
    }

这里就是判断拦截器链有没有东西，如果是空的就直接通过反射调用，不是空就进行else逻辑了，那else是重点了，即invocation.proceed();

3.invocation.proceed()

public Object proceed() throws Throwable {
       // We start with an index of -1 and increment early.
       if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
          return invokeJoinpoint();
       }
    
       Object interceptorOrInterceptionAdvice =
             this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
       if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
          // Evaluate dynamic method matcher here: static part will already have
          // been evaluated and found to match.
          InterceptorAndDynamicMethodMatcher dm =
                (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
          if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
             return dm.interceptor.invoke(this);
          }
          else {
             // Dynamic matching failed.
             // Skip this interceptor and invoke the next in the chain.
             return proceed();
          }
       }
       else {
          // It's an interceptor, so we just invoke it: The pointcut will have
          // been evaluated statically before this object was constructed.
          return ((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
       }
    }

第一个if是递归的终止条件，明显是根据下标进行终止的条件

后面进行前++，又调用了

((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);

然而这里面是：

public Object invoke(MethodInvocation mi) throws Throwable {
       MethodInvocation oldInvocation = invocation.get();
       invocation.set(mi);
       try {
          return mi.proceed();
       }
       finally {
          invocation.set(oldInvocation);
       }
    }

又跑回proceed方法去了，递归。

第二次来到的时候下标就是0了（第一次是-1，默认的），前++为1的下标的话，取出来的东西继续调用invoke发现进的是AspectJAfterThrowingAdvice的invoke了（第一次是ExposeInvocationInterceptor的invoke，记录下MethodInvocation供后面执行链获取）

这个AspectJAfterThrowingAdvice的invoke的源码如下（不一样）：

public Object invoke(MethodInvocation mi) throws Throwable {
       try {
          return mi.proceed();
       }
       catch (Throwable ex) {
          if (shouldInvokeOnThrowing(ex)) {
             invokeAdviceMethod(getJoinPointMatch(), null, ex);
          }
          throw ex;
       }
    }

继续递归，不过这次把调用链try起来了，出异常就走异常增强通知invokeAdviceMethod

继续debug，又是递归到invoke，但这次是AfterReturningAdviceInterceptor的：

public Object invoke(MethodInvocation mi) throws Throwable {
       Object retVal = mi.proceed();
       this.advice.afterReturning(retVal, mi.getMethod(), mi.getArguments(), mi.getThis());
       return retVal;
    }

提一下啊，递归是栈结构！所以我们先看到了异常调用代码和返回通知代码！

继续递归proceed到了后置通知AspectJAfterAdvice类的invoke:

public Object invoke(MethodInvocation mi) throws Throwable {
       try {
          return mi.proceed();
       }
       finally {
          invokeAdviceMethod(getJoinPointMatch(), null, null);
       }
    }

看到没，后置通知类的invokeAdviceMethod调用是用的finally，所以后置通知始终执行！

继续递归

跳到了前置通知类MethodBeforeAdviceInterceptor的invoke

public Object invoke(MethodInvocation mi) throws Throwable {
       this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis());
       return mi.proceed();
    }

注意这里不一样了！它是先调用自己再调执行链，这也就是为什么前置通知早于方法执行

before方法执行完之后，进proceed了，递归即将结束：

![image][image 3]

所有的增强器取出来了，并执行了before 这里递归就结束了，调用目标方法：invokeJoinpoint

然后是后置通知各种，有异常就走之前try finally那里。

至此aop具体逻辑结束！

总结下易翻车点：

1.注意看自己的源码是哪个类，不然很懵逼，因为调了很多个类的同名方法invoke。

2.注意看是递归，和递归结束条件

3.注意invoke的实现，对于不同的增强器的逻辑是不一样的

4.增强器那个集合是有顺序好的

[image]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xOTQ3MjMzNC01MjliODNjNTBiNTZmZDAy?x-oss-process=image/format,png
[image 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xOTQ3MjMzNC0zMzg0ZmNhMTUwYzQ0MGEw?x-oss-process=image/format,png
[image 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xOTQ3MjMzNC0yODRjZDJhNTVhOWUxMWNh?x-oss-process=image/format,png
[image 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xOTQ3MjMzNC01ZWU2YzIyYWJhZTQ5NDY1?x-oss-process=image/format,png