序
最近几天在工作中遇到了一个动态署理所带来的坑，遂简略的研讨了一波aop履行流程的源码，期望对各位有所帮助。
关于AOP履行顺序不清楚的jym，可以看一下这篇文章：Spring AOP 履行顺序问题
文章结构
本文想以一个问题提出AOP动态署理的问题，通过问题的考虑，以一个简略的例子来解读Spring AOP大致做了什么，最后再做一波总结。
简略的问题
简略的切面类
简略的署理类
问题其实很简略，this.dy2()会不会走切面，打印出before?
答案是：不会。
答案有些朋友有可能答对了，但是为什么呢？
我当时错误的考虑是，controller目标现已是cglib动态署理的目标了，也就是增强目标了，dy()办法走切面肯定是不会有问题的，但是为什么dy2()不走切面呢？this目标不是现已署理过的增强的controller么，那么dy2()办法应该也是增强的，必定也会走切面，为什么最后却不走切面呢？
考虑中。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
回答：首要一开始就现已搞错了，this目标和增强后的controller目标本来就不是同一个目标，this目标仅仅controller目标自身。你可以直接从spring容器中获取增强后的controller然后与this进行比照就会发现他们并不是同一个目标。
为什么会这样呢？
简略的源码剖析
在这儿我只会做要害当地和本文有关的源码解读，以后我会写一篇详细的Spring AOP履行流程的源码剖析和Spring创立动态署理源码剖析。
Spring AOP 创立动态署理源码剖析
Spring AOP 动态署理履行流程源码剖析
首要Spring的AOP采用的动态署理是jdk和cglib。
对应的接口是AopProxy,对应的类是CglibAopProxy和JdkDynamicAopProxy。
本文以CglibAopProxy来做相关剖析。
这个办法里面的东西很多，以及后续的涉及东西也会很多，所以我会直接定位到最要害的当地忽略掉很多东西，仅仅为了定位到反射掉用自己类的当地，然后证明所谓的切面也就是一层一层的履行对应的增强办法，最后反射再掉用自己的实践办法，所以这就证明了一点那就是上述controller中的this其实就是它自身的而不是增强的目标。
target为什么是未增强的目标呢？这要涉及到bean动态署理的源码，我也大致截一下图便利了解。
总结
源码的剖析非常的粗糙，但也仅仅为了证明 不管是jdk仍是cglib动态署理确实是动态生成了署理类，但是署理类履行增强办法的时分仅仅判别是否有切面，然后依照切面顺序履行切面办法，最后通过反射来调用实践办法，而反射的目标确是本来的目标而不是增强后的署理目标。
尾
非常感谢能看到这儿的JYM，如果本文有误请不吝赐教。
