自己实现 aop 和 spring aop

上文说到，我们可以在 BeanPostProcessor 中对 bean 的初始化前化做手脚，当时也说了，我完全可以生成一个代理类丢回去。

代理类肯定要为用户做一些事情，不可能像学设计模式的时候创建个代理类，然后简单的在前面打印一句话，后面打印一句话，这叫啥事啊，难怪当时听不懂。最好是这个方法的前后过程可以自户自己定义。

小明说，这还不好办，cglib 已经有现成的了，jdk 也可以实现动态代理，看 mybatis 其实也是这么干的，不然你想它一个接口怎么就能找到 xml 的实现呢，可以参照下 mybatis 的代码。

所以首先学习下 cglib 和 jdk 的动态代理，我们来模拟下 mybatis 是如何通过接口来实现方法调用的

cglib

目标接口：

public interface UserOperator {
    User queryUserByName(String name);
}

代理处理类：

import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

public class ProxyHandle implements MethodInterceptor{
    // 实现 MethodInterceptor 的代理拦截接口
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
        System.out.println("获取到 sqlId:"+method);
        System.out.println("获取到执行参数列表："+args[0]);
        System.out.println("解析 spel 表达式，并获取到完整的 sql 语句");
        System.out.println("执行 sql ");
        System.out.println("结果集处理，并返回绑定对象");
        return new User("sanri",1);
    }
}

真正调用处：

Enhancer enhancer = new Enhancer();

enhancer.setSuperclass(UserOperator.class);
enhancer.setCallback(new ProxyHandle());

//可以把这个类添加进 ioc 容器，这就是真正的代理类
UserOperator userOperator = (UserOperator) enhancer.create();

User sanri = userOperator.queryByName("sanri");
System.out.println(sanri);

jdk

import java.lang.reflect.InvocationHandler;
public class ProxyHandler implements InvocationHandler {
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("获取到 sqlId:"+method);
        System.out.println("获取到执行参数列表："+args[0]);
        System.out.println("解析 spel 表达式，并获取到完整的 sql 语句");
        System.out.println("执行 sql ");
        System.out.println("结果集处理，并返回绑定对象");
        return new User("sanri",1);
    }
}

真正调用处：

UserOperator proxyInstance = (UserOperator)Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(), new Class[]{UserOperator.class}, new ProxyHandler());
User sanri = proxyInstance.queryByName("sanri");
System.out.println(sanri);

注：jdk 只能支持代理接口，但 cglib 是接口和实体类都可以代理； jdk 是使用实现接口方式，可以多实现，但 cglib 是继承方式，也支持接口方式。

代理模式和装饰模式的区别：

从这也可以看到代理模式和装饰模式的区别，代理模式的方法签名一般是不动的，但装饰模式是为了方法的增强，一般会使用别的更好的方法来代替原方法。

如何织入

回到正文，这时我们已经可以创建一个代理类了，如何把用户行为给弄进来呢，哎，又只能回调了，我们把现场信息给用户，用户实现我的接口，然后我找到接口的所有实现类进行顺序调用，但这时候小明想到了几个问题

用户不一定每个方法都要做代理逻辑，可能只是部分方法需要，我们应该能够识别出是哪些方法需要做代理逻辑 (Pointcut)
方法加代理逻辑的位置，方法执行前(Before)，方法执行后(After)，方法返回数据后(AfterReturning)，方法出异常后(AfterThrowing)，自定义执行(Around)

根据单一职责原则，得写五个接口，每个接口要包含 getPointCut() 方法和 handler() 方法，或者绕过单一职责原则，在一个接口中定义 6 个方法，用户不想实现留空即可。总得来说，用户只需要提交一份规则给我就行，这个规则你不管是用 json，xml ，或者注解的方式，只要我能够识别在这个 pointcut 下，需要有哪些自定义行为，在另一个 pointcut 下又有哪些自定义行为即可。

现拿到用户行为了和切点了，还需要创建目标类的代理类，并把行为给绑定上去，在什么时候创建代理类呢，肯定在把 bean 交给容器的时候悄悄的换掉啊，上文说到 bean 有一个生命周期是用于做所有 bean 拦截的，并且可以在初始化前和初始化后进行拦截，没错，就是 BeanPostProcessor 我们可以在初始化后生成代理类。

这里需要注意，并不是所有类都需要创建代理。我们可以这样检测，让 pointcut 提供一个方法用于匹配当前方法是否需要代理，当然这也是 pointcut 的职责，如果当前类有一个方法需要代理，那么当前类是需要代理的，否则认为不需要代理，这么做需要遍历所有类的所有方法，如果运气差的话，看上去很耗费性能，但 spring 也是这么干的。。。。。。优化的方案可以这么玩，如果方法需要代理，在类上做一个标识，如果类上存在这个标识，则可以直接创建代理类。

现在我们把用户行为绑定到代理类，根据上面 jdk 动态代理和 cglib 动态代理的学习，我们发现，它们都有一个共同的家伙，那就是方法拦截，用于拦截目标类的当前正在执行的方法，并增强其功能，我们可以在创建代理类的时候找到所有的用户行为并按照顺序和类型依次绑定，可以用责任链模式。

看一下 spring 是怎么玩的

spring 也是在 BeanPostProcessor 接口的 postProcessAfterInitialization 生命周期进行拦截，具体的类为 AspectJAwareAdvisorAutoProxyCreator

spring 配置切面有两种方式，使用注解和使用配置，当然，现在流行注解的方式，更方便，但不管是配置还是注解，最后都会被解析成 Advisor(InstantiationModelAwarePointcutAdvisorImpl)，spring 查找了所有实现 Advisor 的类，源代码在 BeanFactoryAdvisorRetrievalHelper.findAdvisorBeans

advisorNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(this.beanFactory, Advisor.class, true, false);

紧接着，spring 会使使用 Advisor 中的 pointcut 来看当前类是否需要创建代理类，跟进方法可以看到 canApply 方法中是遍历了所有方法一个个匹配来看是否需要创建代理类的，如果有一个需要，则直接返回 true 。当然 spring 更严谨一些，它考虑到了可能有接口的方法需要有代理，我上面说在类加标识是不正确的。

然后通过 createProxy 创建了代理类，里面有区分 cglib 还是 aop ，下面单拿 cglib 来说

在 CglibAopProxy.getProxy 中对类进行增强，主要看 Enhancer 类是如何设置的就好了，有一个 callback 参数，我们一般是第 0 个 callback 也即 DynamicAdvisedInterceptor 它是一个 cglib 的 MethodInterceptor

它重写的是 MethodInterceptor 的 intercept 方法，下面看这个方法，this.advised 是前面传过来的用户行为，getInterceptorsAndDynamicInterceptionAdvice 把 Advisor 适配成了 org.aopalliance.intercept.MethodInterceptor 分别对应切面的五种行为

AbstractAspectJAdvice
  |- AspectJAfterReturningAdvice
  |- AspectJAfterAdvice implements org.aopalliance.intercept.MethodInterceptor
  |- AspectJAroundAdvice implements org.aopalliance.intercept.MethodInterceptor
  |- AspectJAfterThrowingAdvice implements org.aopalliance.intercept.MethodInterceptor
  |- AspectJMethodBeforeAdvice

最后它封装一个执行器，根据顺序调用拦截器链，也即用户行为列表，封装执行的时候是强转 org.aopalliance.intercept.MethodInterceptor 来执行的，但 AspectJAfterReturningAdvice 和 AspectJMethodBeforeAdvice 没有实现 org.aopalliance.intercept.MethodInterceptor 怎么办，所以 spring 在获取用户行为链的时候增加了一个适配器，专门用于把这两种转换成 MethodInterceptor

其它说明

cglib 的 callback 只能写一个，filter 用于选择是第几个 callback ，不要认为也是链式的
spring aop 中有比较多的设计模式，学设计模式的可以看下这块的源码，至少责任链，适配器，动态代理都可以在这看到
切面类中如果有两个一样的行为，比如有两个 @Before，排序规则为看方法名的 ascii 码值，只测试过，并没经过源码，有兴趣的可以自己去看一下。

来个示例更容易理解

我们除了使用 @Aspect 注解把切面规则告诉 spring 外，也可以学本身 aop 的实现，我们自己定义一个 Advisor ，因为 spring 就是扫描这个的，然后实现 pointcut 和 invoke 方法，一样可以实现 aop 。

联系上文： spring-data-redis-cache 使用及源码走读我们来看看 spring 的 redis-cache 是如何做切面的

文章说到，主要工作的类是 CacheInterceptor 它是一个 org.aopalliance.intercept.MethodInterceptor

Advisor 是 BeanFactoryCacheOperationSourceAdvisor 也就是说创建代理类会扫描到这个类，最后执行会把其转成 MethodInterceptor，因为它是一个 PointcutAdvisor ，查看 DefaultAdvisorChainFactory.getInterceptorsAndDynamicInterceptionAdvice 方法，第一个就是把 PointcutAdvisor 转成 MethodInterceptor 继续进入获取拦截器的方法，可以知道就是获取的 advice 属性 CacheInterceptor