CGLIB代理方法执行基本流程

CGLIB代理的事务

CglibAopProxy的getProxy

在进行增强的时候会去获取拦截器：

CglibAopProxy的getCallbacks

这个里面的方法拦截器内部是我们的事务相关的通知器，里面还有事务拦截器：

DynamicAdvisedInterceptor的intercept

内部跟JdkDynamicAopProxy的invoke很像，都是获取拦截链，其实就是事务拦截器：

但是JdkDynamicAopProxy封装了一个ReflectiveMethodInvocation，最后是用反射调用被代理对象的方法的，这个前面讲过，不多说了。

而CglibAopProxy用的是CglibMethodInvocation是ReflectiveMethodInvocation的子类，这里很重要的就是前几篇说的方法代理MethodProxy：

还有个很重要的就是他覆盖了invokeJoinpoint方法：

因为默认的invokeJoinpoint最后是用方法的反射调用：

CglibMethodInvocation的invokeJoinpoint

他覆盖了这个方法，如果方法代理存在就走代理的，否则还反射。

这里要注意，传入的参数，是被代理对象，不是代理对象，跟我们前面讲的不一样：

话说回来，这里没调用invokeSuper，前面不是说不是要调用invoke这个么，其实是看你传入的obj是什么，比如这里的obj就是被代理对象，而fci.f1就是被代理对象索引增强对象，传进去就直接调用方法啦，比如前面的这样，传进去如果就是CglibObj对象本身，那就直接调用方法了，如果是代理对象，那就无限循环f1方法了：

看下前面的错误用法，传入参数o是代理对象：

一般的拦截器里obj是代理对象，如果直接执行调用方法，就会执行到覆盖的方法，然后就无限循环了。这里也解释了，用CGLIB对象内部方法调用也不会进行事务拦截，因为最终还是调用被代理对象的方法，跟JDK代理反射一样，被代理对象内部方法调用不存在拦截。

为什么这里不能调用invokeSuper

因为这里的传入参数是被代理对象，如果调用了就会去调用下面的方法，首先类型转换就报异常了，因为父类没办法转换到子类，看我们前面生成的代理类的方法索引增强类：

ef630afc是什么鬼，就是代理类啦，你看代理类的静态方法和实例方法就明白了：

在前面生成的代理类CglibObj$$EnhancerByCGLIB$$ef630afc.class中有：

制造类型转换异常

根据上面说的，我人为制造一个对象传进去，虽然不是被代理对象，但是类型一样，只是为了验证上面的类型转化那边就有问题：

结果跟我猜的一样,当然还有无限递归的异常，我就不演示了：

如果你能明白这里为什么报转换异常，说明你懂了CGLIB到底怎么调用方法的。基本上整个流程都讲完了，稍微有点复杂，耐心看看理解下就好了。主要是方法代理中会进行方法索引增强，提升性能。其他的一些细节我就不说了，有需要再研究，精力有限，不可能全部讲完。可见CGLIB创建的时候可能耗点性能，毕竟有字节码生成，而且生成的增强类相对复杂一点，如果你不需要每个方法都拦截，记得配上拦截过滤器就行，CGLIB调用方法肯定比JDK动态代理快，因为有FastClass方法索引的帮助。

好了，今天就到这里了，希望对学习理解有帮助，大神看见勿喷，仅为自己的学习理解，能力有限，请多包涵。