《Spring技术内幕——深入解析Spring架构与设计原理》连载4

《Spring技术内幕——深入解析Spring架构与设计原理》


 
书名：Spring技术内幕——深入解析Spring架构与设计原理
作者：计文柯
ISBN：9787111288060
丛书名：揭秘系列丛书
出版社：机械工业出版社
出版日期：2010 年1月
开本：16
页码：300
版次：1-1
定价：55元
豆瓣网讨论地址：http://www.douban.com/subject/4199483/
China-pub预订地址：http://www.china-pub.com/196261



图 书 内 容

    本书是Spring领域的问鼎之作，由业界拥有10余年开发经验的资深Java专家亲自执笔！Java开发者社区和Spring开发者社区一致强烈推荐。

    国内第一本基于Spring 3.0的著作，从源代码的角度对Spring的内核和各个主要功能模块的架构、设计和实现原理进行了深入剖析。你不仅能从本书中参透Spring框架的优秀架构和设计思想，而且还能从Spring优雅的实现源码中一窥Java语言的精髓。此外，本书还展示了阅读源代码的卓越方法，不仅授你以鱼，而且还授你以渔！

    如果你以一种淡定的心态翻开这本书，无论你是Java程序员、Spring开发者，还是平台开发人员、系统架构师，抑或是对开源软件源代码着迷的代码狂人，都能从本书中受益。

 

 

 

3.3.4  AOP拦截器链的调用

在了解了对目标对象的直接调用以后，我们开始进入AOP实现的核心部分了，对于AOP是怎样完成对目标对象的增强的，这些实现是封装在AOP拦截器链中，由一个个具体的拦截器来完成的。

尽管我们在上面看到，使用JDK和CGLIB会生成不同的AopProxy代理对象，从而构造了不同的回调方法来启动对拦截器链的调用，比如在JdkDynamicAopProxy中的invoke方法，以及Cglib2AopProxy中使用DynamicAdvisedInterceptor的intercept方法。它们都使用了不同的AopProxy代理对象，但最终对AOP拦截的处理可谓殊途同归：它们对拦截器链的调用都是在ReflectiveMethodInvocation中通过proceed方法实现的。在这个proceed方法里，会逐个运行拦截器的拦截方法。在运行拦截器的拦截方法之前，需要对代理方法完成一个匹配判断，通过这个匹配判断来决定拦截器是否满足切面增强的要求。大家一定还记得，我们前面提到的，在Pointcut切点中需要进行matches的匹配过程，就是这个matches调用对方法进行匹配判断，来决定是否需要实行通知增强；以下看到的调用就是进行matches的地方，具体的处理过程在ReflectiveMethodInvocation的proceed方法中，如代码清单3-21所示。在proceed方法中先进行判断，如果现在已经运行到拦截器链的末尾，那么就会直接调用目标对象的实现方法；否则，沿着拦截器链继续进行，得到下一个拦截器，通过这个拦截器进行matches判断，判断是否适用于横切增强的场合，如果是，从拦截器中得到通知器，并启动通知器的invoke方法进行切面增强。在这个过程结束以后，会迭代调用proceed方法，直到拦截器链中的拦截器都完成以上的拦截过程为止。

代码清单3-21  拦截器的运行

public Object proceed() throws Throwable {
 // We start with an index of -1 and increment early.
 /**
 *如果拦截器链中的拦截器迭代调用完毕，这里开始调用target的函数，
 *这个函数是通过反射机制完成的，具体实现在：AopUtils.invokeJoinpointUsingReflection方法里面。
 */
 if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethod
Matchers.size() - 1) {
  return invokeJoinpoint();
 }
 //这里沿着定义好的 interceptorOrInterceptionAdvice链进行处理。
 Object interceptorOrInterceptionAdvice =
 this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptor
Index);
 if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamic
MethodMatcher) {
  /**
  * Evaluate dynamic method matcher here: static part will already have
  * been evaluated and found to match.
  */
  /**
  *这里对拦截器进行动态匹配的判断，还记得我们前面分析的pointcut吗？
  *这里是触发进行匹配的地方，如果和定义的pointcut匹配，那么这个advice将会得到执行。
  */
  InterceptorAndDynamicMethodMatcher dm =
      (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
  if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
   return dm.interceptor.invoke(this);
  }
  else {
   // Dynamic matching failed.
   // Skip this interceptor and invoke the next in the chain.
   // 如果不匹配，那么proceed会被递归调用，直到所有的拦截器都被运行过为止。
   return proceed();
  }
 }
 else {
  /**
  * It's an interceptor, so we just invoke it: The pointcut will have
  * been evaluated statically before this object was constructed.
  */
  //如果是interceptor，直接调用这个interceptor对应的方法。
  return((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
 }
}

 

以上就是整个拦截器及target目标对象方法被调用的过程。小荷才露尖尖角，我们已经在这里看到对advice通知的调用入口了，虽然这个大名鼎鼎的advice到现在还没有完全现身，但我们已经看到了它的运行轨迹；我们先提出一个疑问来提提大家的兴趣：这些advisor是怎样从配置文件中获得并配置到proxy的拦截器链中去的？我们平常使用的advice通知是怎样起作用的？这些都是了解AOP实现原理的重要问题，下面我们就这些问题已经展示的线索继续展开分析，去寻求这些问题的答案吧。

3.3.5  配置通知器
在整个AopProxy代理对象的拦截回调过程中，让我们先回到ReflectiveMethod
Invocation类的proceed方法，在这个方法里，可以看到得到了配置的interceptor-
OrInterceptionAdvice，如下所示。

Object interceptorOrInterceptionAdvice =
this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);

 

这个interceptorOrInterceptionAdvice是获得的拦截器，它通过拦截器机制对目标对象的行为增强起作用。这个拦截器来自于interceptorsAndDynamicMethodMatchers，具体来说，它是interceptorsAndDynamicMethodMatchers持有的List中的一个元素。关于如何配置拦截器的问题，就被转化为这个List中的拦截器元素是从哪里来、在哪里配置的问题。我们接着对invoke调用进行回放，回到JdkDynamicAopProxy中的invoke方法中，可以看到这个List中的interceptors是在哪个调用中获取的。对于Cglib2AopProxy，也有类似的过程，只不过这个过程是在DynamicAdvisedInterceptor的intercept回调中实现的，如下所示。

List