原创作品，可以转载，但是请标注出处地址：https://www.cnblogs.com/V1haoge/p/9619910.html
其实在之前的源码解读里面，关于织入的部分并没有说清楚，那些前置、后置、环绕、异常等通知是如何围绕在目标方法周围执行的呢？
这里面最重要的就是递归，Spring在实现这块逻辑的时候使用的大量的递归调用，完美的实现的织入的逻辑。
我们不凡就以Spring基础系列--AOP实践中的例子来进行一番逻辑追踪，来一探究竟。
我们就从测试类开始：
首先我们通过CglibAopProxy类的intercept方法构建一个方法调用，并执行其proceed方法：
然后进入ReflectiveMethodInvocation类的proceed()方法，由于currentInterceptorIndex下标从-1开始，在进行++自增操作之后变成0，获取interceptorsAndDynamicMethodMatchers中的第一个拦截器。
我们看下interceptorsAndDynamicMethodMatchers中的内容：
第一个是ExposeInvocationInterceptor，这个正是之前在Spring基础系列-AOP源码分析中源码11里提到的，获取通知链的时候会将其放到通知链首位，用于暴露方法调用到ThreadLocal中。
由于其为一个简单的拦截器，上面的判断是不成立的，所以直接执行最后一行：
然后进入到ExposeInvocationInterceptor方法的invoke方法中
在这个方法中我们可以看到，90行处，将方法调用mi放到了invocation中。那invocation是什么呢？如下
private static final ThreadLocal<MethodInvocation> invocation = new NamedThreadLocal<>("Current AOP method invocation");
可见，是将方法调用保存到了ThreadLocal中，这个invocation保存的正是当前AOP的方法调用。
然后执行mi.proceed()方法，这就是一个递归调用了。在这里执行proceed方法，将会继续执行下一个通知，执行逻辑又回到ReflectiveMethodInvocation类的proceed()方法，这时currentInterceptorIndex自增之后为1，正好指向interceptorsAndDynamicMethodMatchers中的下一个通知：
很显然，下一个通知为后置异常通知afterThrowingTest。
执行这个通知的invoke方法，代码调到AspectJAfterThrowingAdvice类的invoke方法。
在异常通知的invoke方法中直接递归调用proceed方法，并将剩下所有的调用执行全部try...catch住，在最后catch块中执行其通知逻辑。
除开普通的拦截器之外，最先执行的通知是异常通知，它会将剩下所有的调用逻辑全部catch住，也就是说在这期间发生的任何异常都会被捕捉到，而且一旦哪一步发生了异常，那么执行就会被中断，到这里执行catch逻辑。
这下又回到了ReflectiveMethodInvocation类的proceed方法。currentInterceptorIndex再次自增为2，指向通知链中第三个通知：
后置返回通知，遵从以上的逻辑我们看看下一步的行为：
在AfterReturningAdviceInterceptor类中
果然去执行后置返回通知的invoke方法去啦，第一步任然是递归调用，又回到了ReflectiveMethodInvocation类的proceed方法去执行第四个通知：
这个是后置终点通知，这个通知有点特殊哦，我们来看看其invoke方法
它也是先直接进行递归调用，将其逻辑放在最后，这个是真正的最后，直接放到了finally块中，这表示什么，这表示，无论接下来的调用操作是否会发生异常，这部分逻辑永远会执行。
现在又一次回去了ReflectiveMethodInvocation类的proceed方法去执行第五个通知：
嗯，这次是环绕通知，这个通知不同于其他通知，其他通知只执行于方法的一点，这个通知却需要执行于方法的两处。所以它会拥有一个ProceedJoinPoint参数，这个参数就是用来区分这两处执行逻辑的：目标方法之前与之后。
直接执行到最后一句，首次要执行invokeAdviceMethod方法了：
然后执行invokeAdviceMethodWithGivenArgs方法：
它要直接执行通知方法中的逻辑，想想为什么没有在进行递归调用而是直接执行的通知方法呢？
因为环绕通知将递归调用挪移到了通知逻辑中，由程序员自定义执行，来看看我自定义的环绕通知逻辑：
我们先不考虑具体的逻辑，先看看大体结构，显示一段逻辑，然后执行jp.proceed(os)方法。然后又是一段逻辑。所谓的环绕就是将逻辑围绕在目标执行前后。
通知的内容真正开始执行了，这里首先执行了环绕通知的前置部分。
我们执行递归调用之后，我们发现逻辑跑到了MethodInvocationProceedingJoinPoint中，这是啥类呢？
这竟然是ProceedJoinPoint的实现类，我们执行jp.proceed(os)方法当然会跑到这里了，
其实ProceedJoinPoint的proceed方法有两个重载，一个有参数，一个无参数，分别用于针对目标方法有参数和目标发无参数的情况，所以这里这两个方法其实逻辑类似，只是有参数的方法会针对参数进行一番操作，将参数设置到方法调用中，这么做，新的方法参数会替换就的方法参数，这也是我们可以在环绕通知中修改参数的原理所在。
第99行就是重设参数的逻辑，方法调用中原先其实已经保存有参数：原有的参数。
第100行代码是重点，这里这里创建了一个方法调用的一个浅拷贝，并使用这个浅拷贝来执行递归调用proceed方法。
为什么使用浅拷贝呢？因为我们还希望使用与原来的方法调用相同的拦截器链和其他对象引用，只不过是需要当前的环绕通知的独立性罢了（这个可能就是再之前提到的环绕通知会导致其他一些通知功能失效的原因所在了吧）
逻辑又回到ReflectiveMethodInvocation类的proceed方法去执行第六个通知：
这最后一个通知必然就是剩余的前置通知了。让我们看看其invoke方法执行。来自：MethodBeforeAdviceInterceptor
这里执行通知的前置通知逻辑：来自：AspectJMethodBeforeAdvice
调用跑到AbstractAspectJAdvice中：
再调用：
这里就是真正调用通知逻辑了：来自AspectTest
然后就是一路后退到MethodBeforeAdviceInterceptor类中的invoke方法，继续执行下一步：
这又是一递归调用，这个调用将会使逻辑再次返回到ReflectiveMethodInvocation类的proceed方法，这一次，由于 所有的通知链中的通知都走过一次，剩余的就是目标方法了。来自：CglibAopProxy
所以这次直接执行目标方法了，哈哈。来自：AspectDemo
反射调用目标方法。
执行完目标方法，然后递归退回到AspectTest类中的环绕通知aroundTest中去执行环绕通知的后置部分逻辑。
执行完后，继续递归退回，到AspectJAfterAdvice类的invoke方法，去执行finally中的逻辑：
再次执行AbstractAspectJAdvice类的invokeAdviceMethod方法：
调用invokeAdviceMethodWithGivenArgs方法
这次执行后置终点通知中的内容：
然后再次递归回退到AfterReturningAdviceInterceptor类的invoke方法：
调用AspectJAfterReturningAdvice类的afterReturning方法：
这里不再罗列AbstractAspectJAdvice类中的那两个方法啦，直接出通知方法：
这次退回到AspectJAfterThrowingAdvice类的invoke方法：
由于整套逻辑未发生异常，所以此处不执行catch块中的逻辑。然后再次递归回退到了ExposeInvocationInterceptor类的invoke方法，来执行finally块中的逻辑：
这句话将invocation中保存的方法调用置空了。最后回退到DynamicAdvisedInterceptor类的intercept方法继续下面的逻辑。
好了，到此为止，想说的都说啦，下面就是一些补充：
这里是为了统一说明，所以讲所有的通知全部罗列，在一起调用，很明显返回值的部分就不正确，我想说的是，尽量别把环绕通知和别的通知一起使用，这个通知还是单独使用比较好。
怎么样？如果你全都看完了，那么有啥感想吗？
织入的实现就是依靠一个顺序通知链，再加上递归实现的。有没有感觉这里的递归用的非常的漂亮。层层嵌套，将后执行的部分放到通知链前面，在递归链中以先执行下一条通知的方式层层深入，最里面是首先执行的通知（前置通知，先把环绕通知撇开），然后再层层退出，执行各自通知的逻辑包括目标方法的逻辑。
之前我有个疑惑就是在ReflectiveMethodInvocation类的proceed方法中，前三行代码，顺序执行通知链，最后执行目标方法，那么怎么实现后置的通知呢。看完上面的代码追踪，就了解了吧！