概要

过度

我们上文通过介绍AnnotationAwareAspectJAutoProxyCreator后处理器的工作原理，撸通了在后处理中创建动态代理的思路。最后我们得到了一个动态代理，或者是JdkDynamicAopProxy或者是ObjenesisCglibAopProxy。

本文我们粗略介绍一下这两种动态代理的工作原理。【注意，非常粗略，只用于帮助理解，因为这块实在是有点复杂】

内容简介

本文通过结合很早之前对动态代理的基本使用的介绍，介绍了Spring AOP创建的动态代理的执行方法。

所属环节

代理工作原理

上下环节

上文：动态代理的创建

下文：AOP 基本功能介绍完成

源码解析

入口

我们上文根据情况new了JdkDynamicAopProxy或者是ObjenesisCglibAopProxy。接下来我们依次进行介绍。

JdkDynamicAopProxy

我们先回顾前面介绍的动态代理里面的思路：

1. 先得到要代理的目标对象实例
2. 构建一个代理类，实现InvocationHandler接口，在其中保存要增强的目标对象实例，并在其invoke()方法中实现对目标对象调用的增强
3. 利用Proxy.newProxyInstance()根据要代理的接口生成动态代理

因为我们这里不去探究jdk动态代理的实现细节，所以我们关注重点在于主干流程，根据经验，我们找到：

@Override
public Object getProxy() {
  return getProxy(ClassUtils.getDefaultClassLoader());
}

@Override
public Object getProxy(@Nullable ClassLoader classLoader) {
  if (logger.isDebugEnabled()) {
    logger.debug("Creating JDK dynamic proxy: target source is " + this.advised.getTargetSource());
  }
  // 找出 JDK 动态代理要代理的接口
  Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised, true);
  // 看我们找出的对应的接口的方法中有没有对 hashCode(),equals() 这种基本方法的覆盖
  findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
  return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
}

和我们的思路基本一样，接下来看invoke()方法：

// 根据JDK动态代理的依赖包，这里是调用被代理类的方法时实际调用的方法，Spring在这里进行了复杂的操作
// 包括对我们之前梳理出的 Advisor 的链式调用
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
  MethodInvocation invocation;
  Object oldProxy = null;
  boolean setProxyContext = false;

  TargetSource targetSource = this.advised.targetSource;
  Object target = null;

  try {
    // 对一些Object默认方法的处理，如果目标对象没有特别实现，就在代理对象中自行调用默认逻辑
    // 不要细究，关注主干逻辑
    if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) { //equals（）
      // The target does not implement the equals(Object) method itself.
      return equals(args[0]);
    } else if (!this.hashCodeDefined && AopUtils.isHashCodeMethod(method)) {//hashCode（）
      // The target does not implement the hashCode() method itself.
      return hashCode();
    } else if (method.getDeclaringClass() == DecoratingProxy.class) {
      // There is only getDecoratedClass() declared -> dispatch to proxy config.
      return AopProxyUtils.ultimateTargetClass(this.advised);
    } else if (!this.advised.opaque && method.getDeclaringClass().isInterface() &&
               method.getDeclaringClass().isAssignableFrom(Advised.class)) {
      // Service invocations on ProxyConfig with the proxy config...
      return AopUtils.invokeJoinpointUsingReflection(this.advised, method, args);
    }

    Object retVal;

    if (this.advised.exposeProxy) { // 如果有配置，就把当前的代理对象暴露出去
      // Make invocation available if necessary.
      oldProxy = AopContext.setCurrentProxy(proxy);
      setProxyContext = true;
    }

    // Get as late as possible to minimize the time we "own" the target,
    // in case it comes from a pool.
    target = targetSource.getTarget();
    Class<?> targetClass = (target != null ? target.getClass() : null);

    // Get the interception chain for this method.
    List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

    // Check whether we have any advice. If we don't, we can fallback on direct
    // reflective invocation of the target, and avoid creating a MethodInvocation.
    if (chain.isEmpty()) { // 不要纠结分支逻辑，我们看正常情况下的
      // We can skip creating a MethodInvocation: just invoke the target directly
      // Note that the final invoker must be an InvokerInterceptor so we know it does
      // nothing but a reflective operation on the target, and no hot swapping or fancy proxying.
      Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
      retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);
    } else {
      // We need to create a method invocation...
      invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain);
      // Proceed to the joinpoint through the interceptor chain.
      retVal = invocation.proceed();
    }

    // Massage return value if necessary.
    Class<?> returnType = method.getReturnType();
    if (retVal != null && retVal == target &&
        returnType != Object.class && returnType.isInstance(proxy) &&
        !RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
      // Special case: it returned "this" and the return type of the method
      // is type-compatible. Note that we can't help if the target sets
      // a reference to itself in another returned object.
      retVal = proxy;
    } else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {
      throw new AopInvocationException(
        "Null return value from advice does not match primitive return type for: " + method);
    }
    return retVal;
  } finally {
    if (target != null && !targetSource.isStatic()) {
      // Must have come from TargetSource.
      targetSource.releaseTarget(target);
    }
    if (setProxyContext) {
      // Restore old proxy.
      AopContext.setCurrentProxy(oldProxy);
    }
  }
}

如果重点关注主干逻辑的话，整体思路还是比较清晰的：

1.png

整体思路还是比较清晰的，这里只是根据前面筛选出的增强器进行一些安排，具体的实现，包括：

1. 根据方法筛选需要的增强器，构建拦截器链
2. 调用目标方法
3. 调用构建的拦截器链

这三步和 AOP 具体实现密切相关的都委托给了外面的函数。如果有兴趣再深入吧。

CglibAopProxy

同样，我们先回顾前面介绍的动态代理里面的思路，这是CGLib最通用最基本的使用方法：

1. 先得到要代理的目标对象实例
2. 构建一个代理类，实现MethodInterceptor接口。
3. 利用Enhancer根据要代理的对象实例生成动态代理

整体思路相近，只是：

• 在创建时JDK动态代理关注的是接口，所以创建时仅通过接口即可，需要在实现增强的逻辑中自行保存要代理的目标对象
• 在创建时CGLib动态代理关注的是目标对象，所以创建时需要目标对象，不需要在实现增强的逻辑中自行保存目标对象了，因为CGLib会给你传入

我们要关注的还是实现增强的主要逻辑，所以我们关注重点在于主干流程，根据经验，我们找到：

@Override
public Object getProxy() {
  return getProxy(null);
}

@Override
public Object getProxy(@Nullable ClassLoader classLoader) {
  if (logger.isDebugEnabled()) {
    logger.debug("Creating CGLIB proxy: target source is " + this.advised.getTargetSource());
  }

  try {
    Class<?> rootClass = this.advised.getTargetClass();
    Assert.state(rootClass != null, "Target class must be available for creating a CGLIB proxy");

    Class<?> proxySuperClass = rootClass;
    if (ClassUtils.isCglibProxyClass(rootClass)) {
      proxySuperClass = rootClass.getSuperclass();
      Class<?>[] additionalInterfaces = rootClass.getInterfaces();
      for (Class<?> additionalInterface : additionalInterfaces) {
        this.advised.addInterface(additionalInterface);
      }
    }

    // Validate the class, writing log messages as necessary.
    validateClassIfNecessary(proxySuperClass, classLoader);

    // Configure CGLIB Enhancer...
    Enhancer enhancer = createEnhancer();
    if (classLoader != null) {
      enhancer.setClassLoader(classLoader);
      if (classLoader instanceof SmartClassLoader &&
          ((SmartClassLoader) classLoader).isClassReloadable(proxySuperClass)) {
        enhancer.setUseCache(false);
      }
    }
    enhancer.setSuperclass(proxySuperClass);
    enhancer.setInterfaces(AopProxyUtils.completeProxiedInterfaces(this.advised));
    enhancer.setNamingPolicy(SpringNamingPolicy.INSTANCE);
    enhancer.setStrategy(new ClassLoaderAwareUndeclaredThrowableStrategy(classLoader));

    Callback[] callbacks = getCallbacks(rootClass);
    Class<?>[] types = new Class<?>[callbacks.length];
    for (int x = 0; x < types.length; x++) {
      types[x] = callbacks[x].getClass();
    }
    // fixedInterceptorMap only populated at this point, after getCallbacks call above
    enhancer.setCallbackFilter(new ProxyCallbackFilter(
      this.advised.getConfigurationOnlyCopy(), this.fixedInterceptorMap, this.fixedInterceptorOffset));
    enhancer.setCallbackTypes(types);

    // Generate the proxy class and create a proxy instance.
    return createProxyClassAndInstance(enhancer, callbacks);
  } catch (CodeGenerationException | IllegalArgumentException ex) {
    throw new AopConfigException("Could not generate CGLIB subclass of " + this.advised.getTargetClass() +
                                 ": Common causes of this problem include using a final class or a non-visible class",
                                 ex);
  } catch (Throwable ex) {
    // TargetSource.getTarget() failed
    throw new AopConfigException("Unexpected AOP exception", ex);
  }
}

在CGLib中针对MethodInterceptor实现了大量的内部类，例如EqualsInterceptor,HashCodeInterceptor,FixedChainStaticTargetInterceptor之类的，入参是Advisor。

这里感觉还是比较清爽的，因为借助了CGLib的调用链，没有像JDK动态代理那样出现了大量的if-else，基本所有的功能，甚至暴露代理对象，都是用的XXXInterceptor。每个XXXInterceptor的思路也很清楚，判断增强器是否可用，可用就用，根据逻辑适当的往下一层调用即可。思路相当清晰。不再赘述了。

扩展

问题遗留

参考文献