Spring注解驱动开发学习总结16：AOP原理 – AOP通知方法执行的步骤
回顾下前４篇AOP原理分析的内容：
１、
Spring注解驱动开发学习总结12：AOP原理 – @EnableAspectJAutoProxy注解作用分析
分析了配置类上添加
@EnableAspectJAutoProxy
注解，最终会给容器中注册了一个id为
internalAutoProxyCreator
，类型为
AnnotationAwareAspectJAutoProxyCreator
的组件。
２、
Spring注解驱动开发学习总结13：AOP原理 – AnnotationAwareAspectJAutoProxyCreator后置处理器注入容器的步骤
分析了
AnnotationAwareAspectJAutoProxyCreator
后置处理器注入ioc容器的步骤。
３、
Spring注解驱动开发学习总结14：AOP原理 – AnnotationAwareAspectJAutoProxyCreator后置处理器的调用步骤
分析了
AnnotationAwareAspectJAutoProxyCreator
后置处理器的调用时机和调用步骤。
４、
Spring注解驱动开发学习总结15：AOP原理 – AnnotationAwareAspectJAutoProxyCreator后置处理器返回代理对象的步骤
分析了
AnnotationAwareAspectJAutoProxyCreator
后置处理器给目前方法添加AOP通知方法，并返回代理对象的步骤。
我们之前给mathCalculator类的div方法添加了AOP的：前置通知（@Before）、后置通知（@After）、返回通知（@AfterReturning）、异常通知（@AfterThrowing）。
本文就是重点来
分析下mathCalculator类的div方法前后调用AOP通知方法的具体步骤
。
1、方法栈调用分析
1.1 分析AOP通知方法的调用步骤
首先来到添加了AOP方法的类（MathCalculator）的方法（div）中，可以看到此时的MathCalculator类是一个被Spring CGLIB增强后的MathCalculator类，也就是上一篇博文中分析的代理类。
调试进入下一步
1 分析切点（Pointcut）方法使用AOP方法的步骤：首先会进入intercept方法
1.1 在intercept方法中，在659行，会先通过getInterceptorsAndDynamicInterceptionAdvice方法获取拦截器链chain，如果拦截器链为空，说明该方法没有任何增强，那么直接执行目标方法。
1.2 在intercept方法中，在673行，如果拦截器链不为空，那么就会执行CGLIB的代理方法：
retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();
接着分析1.1中是如何获取到拦截器链的
1.1 通过getInterceptorsAndDynamicInterceptionAdvice方法获取拦截器链chain
1.1.1 分析getInterceptorsAndDynamicInterceptionAdvice方法，在55行会先创建一个拦截器列表，在60-61行，然后再遍历所有的增强器，如果是切面类增强器，则直接加入增强器链。运行结束后，interceptorList共包含５个拦截器
接着分析1.2中，如果拦截器链不为空，是如何执行CGLIB的代理方法的？
1.2 如果拦截器链不为空，那么就会执行CGLIB的代理的处理方法proceed
1.2.1 分析proceed方法，在156-157行，拦截器索引初始值为-1，会先判断当前拦截器索引是否到拦截器的最后一个：
this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() – 1
1.2.1.1 如果到了最后一个，则直接执行切点方法：invokeJoinpoint()。
1.2.1.2 如果没到最后一个，那么取下一个拦截器：ExposeInvocationInterceptor(index=0),并执行它的invoke方法
接着1.2.1.2继续分析ExposeInvocationInterceptor的invoke方法
1.2.1.2 分析ExposeInvocationInterceptor的invoke方法
1.2.1.2.1 分析ExposeInvocationInterceptor的invoke方法，
１）在92行，会再调用该方法的proceed方法。会再次跳转到
1.2.1中的proceed方法，只是此时的拦截器索引值变为了0。
在156行，此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值+1，继续取取下一个拦截器：
AspectJAfterThrowingAdvice（index=1），然后再次调用AspectJAfterThrowingAdvice的invoke方法。
接着分析1.2.1.2.1 中１）AspectJAfterThrowingAdvice的invoke方法
1.2.1.2.2 分析AspectJAfterThrowingAdvice的invoke方法
１）在62行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的proceed方法，只是此时的拦截器索引值变为
了１。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值+1，继续取取下一个拦截器：
AspectJAfterReturningAdvice（index=２），然后再次调用AspectJAfterReturningAdvice的invoke方法。
２）在66-68行，如果该方法执行报错，那么会执行AOP的异常通知方法@AfterThrowing或者抛出异常。
接着分析1.2.1.2.2 中１）的AspectJAfterReturningAdvice的invoke方法
1.2.1.2.3 分析AspectJAfterReturningAdvice的invoke方法
１）在52行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的proceed方法，只是此时的拦截器索引值变为
了2。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值+1，继续取取下一个拦截器：
AspectJAfterAdvice（index=3），然后再次调用AspectJAfterAdvice的invoke方法。
２）如果该方法执行成功，那么会接着执行AOP的返回通知方法@AfterReturning；
如果该方法执行失败，那么就不会执行AOP的返回通知方法@AfterReturning。
接着分析1.2.1.2.3 中１）的AspectJAfterAdvice的invoke方法
1.2.1.2.4 分析AspectJAfterAdvice的invoke方法
１）在47行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的proceed方法，只是此时的拦截器索引值变为
了3。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值+1，继续取取下一个拦截器：
AspectJMethodBeforeAdvice（index=４），然后再次调用AspectJMethodBeforeAdvice的invoke方法。
２）无论该方法是否成功，都会finally执行该AOP的后置通知方法@After。
接着分析1.2.1.2.4 中１）的AspectJMethodBeforeAdvice的invoke方法
1.2.1.2.5 分析AspectJMethodBeforeAdvice的invoke方法
１）在51行，会先执行AOP的前置通知方法@Before。
２）在52行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的proceed方法，只是此时的拦截器索引值变为
了4。
在156行，此时终于达到拦截器的最后一个位置4，那么此时直接就调用该切点的方法，也就是mathCalculator中
被AOP加强的方法了。
执行完之后，然后再倒回去执行1.2.1.2.4，1.2.1.2.3，1.2.1.2.2，1.2.1.2.1中程序剩下的通知方法。
2、小结
我们之前给mathCalculator类的div方法添加了AOP的：前置通知（@Before）、后置通知（@After）、返回通知（@AfterReturning）、异常通知（@AfterThrowing）。
本文就是重点来
分析下mathCalculator类的div方法前后调用AOP通知方法的具体步骤
。
1 进入mathCalculator类的div方法后，下一步首先会进入intercept方法
1.1 在intercept方法中，在659行，会先通过getInterceptorsAndDynamicInterceptionAdvice方
法获取拦截器链chain，如果拦截器链为空，说明该方法没有任何增强，那么直接执行目标
方法。
1.1.1 分析getInterceptorsAndDynamicInterceptionAdvice方法，在55行会先创建一个拦截
器列表，在60-61行，然后再遍历所有的增强器，如果是切面类增强器，则直接加入增
强器链。运行结束后，interceptorList共包含５个拦截器
1.2 在intercept方法中，在673行，如果拦截器链不为空，那么就会执行CGLIB的代理方法：
retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain,
methodProxy).proceed();
1.2.1 分析proceed方法，在156-157行，
拦截器索引初始值为-1
，会先判断当前拦截器
索引是否到拦截器的最后一个：
this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size()
interceptorsAndDynamicMethodMatchers的值为ExposeInvocationInterceptor + 我们
自定义的４个AOP方法，
所以this.interceptorsAndDynamicMethodMatchers.size()-1的值为４
1.2.1.1 如果到了最后一个，则直接执行切点方法：invokeJoinpoint()。
1.2.1.2 如果没到最后一个，那么取下一个拦截器：
ExposeInvocationInterceptor
(index=0),并执行它的invoke方法
1.2.1.2.1 分析
ExposeInvocationInterceptor
的invoke方
法，
１）在92行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的
proceed方法，只是此时的拦截器索引值变为了0。
在156行，此时还是没有达到拦截器的最后一个位置4，那么拦截器
索引值+1，继续取下一个拦截器：
AspectJAfterThrowingAdvice
（index=1），
然后再次调用
AspectJAfterThrowingAdvice
的invoke方法。
1.2.1.2.2 分析
AspectJAfterThrowingAdvice
的invoke方法
１）在62行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的
proceed方法，只是此时的拦截器索引值变为了１。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值
+1，继续取下一个拦截器：
AspectJAfterReturningAdvice
（index=２），
然后再次调用
AspectJAfterReturningAdvice
的invoke方法。
２）在66-68行，如果该方法执行报错，那么会执行AOP的
异常通知方
法@AfterThrowing
或者抛出异常。
1.2.1.2.3 分析
AspectJAfterReturningAdvice
的invoke方法
１）在52行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的
proceed方法，只是此时的拦截器索引值变为了2。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值
+1，继续取下一个拦截器：
AspectJAfterAdvice
（index=3），
然后再次调用
AspectJAfterAdvice
的invoke方法。
２）如果该方法执行成功，那么会接着执行AOP的
返回通知方法
@AfterReturning
；
如果该方法执行失败，那么就不会执行AOP的
返回通知方法
@AfterReturning
。
1.2.1.2.4 分析
AspectJAfterAdvice
的invoke方法
１）在47行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的
proceed方法，只是此时的
拦截器索引值变为了3。
此时还是没有达到拦截器的最后一个位置4，那么拦截器索引值
+1，继续取下一个拦截器：
AspectJMethodBeforeAdvice
（index=４），
然后再次调用
AspectJMethodBeforeAdvice
的invoke方法。
２）无论该方法是否成功，都会finally执行该
AOP的后置通知方法
@After
。
1.2.1.2.5 分析
AspectJMethodBeforeAdvice
的invoke方法
１）在51行，会先执行
AOP的前置通知方法@Before
。
２）在52行，会再调用该方法的proceed方法。会再次跳转到1.2.1中的
proceed方法，只是此时的
拦截器索引值变为了4。
在156行，此时终于达到拦截器的最后一个位置4，那么此时直接就
调用该切点的方法，也就是mathCalculator中被AOP加强的方法
了。
执行完之后，然后再倒回去执行1.2.1.2.4，1.2.1.2.3，1.2.1.2.2，
1.2.1.2.1中程序剩下的通知方法。