Spring IOC和Spring AOP的实现原理(源码主线流程)

写在前面

      正本文参考了《spring技术内幕》和spring 4.0.5源码。本文只描述原理流程的主线部分，其余好比验证，缓存什么能够具体参考源码理解。

Spring IOC

1、容器初始化

      容器的初始化首先是在对应的构造器中进行，在applicationContext的实现类构造器中，首先对参数路径中的${}进行了处理，用系统变量替换(setConfigLocations方法)而后调用refresh方法(这个就是最核心的容器初始化方法)。

一、Resource定位：

      在refresh方法中调用obtainFreshBeanFactory方法告诉子类刷新beanfactory(其中是调用refreshBeanFactory刷新后getBeanFactory获取刷新后的factory返回)。在刷新过程refreshBeanFactory中若是factory已经有了要消除再新建factory，其中loadBeanDefinitions是加载bean定义的方法。

      在loadBeanDefinitions方法中建立了BeanDefinitionReader的实现类调用其loadBeanDefinitions方法(这个方法是重载方法，参数有为Resource的也有为String路径的，getConfigResources方法(默认返回null，子类重写，如ClassPathXmlApplicationContext类)和getConfigLocations方法得到Resource集合和资源路径集合(通常一个为空，通常是将容器的参数path设定为configLocations，ClassPathXmlApplicationContext有一种构造器是不设定configLocations而是直接用参数path生成ClassPathResource集合设定为configResources)分别进行load，实际上以路径为参数的重载方法在定位完Resource也会调用以resource为参数的loadBeanDefinitions来解析载入BeanDefinition，这个是第二步在下面介绍)。

      在BeanDefinitionReader的loadBeanDefinitions(path参数)方法中根据ResourceLoader类型以两种方式加载（若是是ant正则表达式方式的(如PathMatchingResourcePatternResolver)一个路径定位多个resource或者默认方式(applicationContext继承的是DefaultResourceLoader实现方式)定位一个resource），分别调用ResourceLoader的getResource(以/开头的构建ClassPathContextResource，以classpath开头的去掉classpath构建ClassPathResource，若是都不是的尝试构建UrlResource,若是构建失败就调用getResourceByPath这个具体applicationContext实现类里重写的方法构建特定Resource，如FileSystemXmlApplicationContext就是FileSystemResource)或getResources(PathMatchingResourcePatternResolver的正则方式这里不详细描述)完成Resource定位。

二、从Resource中解析和载入BeanDefinition：

      一样在BeanDefinitionReader的loadBeanDefinitions中调用完resourceLoader的getResource获取Resource后将resource做为参数调用本身(BeanDefinitionReader)的loadBeanDefinitions(是一个接口方法给子类实现，由于不一样的reader加载resource的方式不一样)载入BeanDefinition。

      例如XmlBeanDefinitionReader是对XML文件的IO操做,（将如今要处理的Resource加入当前线程正在处理(ThreadLocal)的Resource集合中）首先从resource中拿出InputStream封装成InputSource调用自身的doLoadBeanDefinitions方法。

      doLoadBeanDefinitions方法中调用doLoadDocument方法封装成Document-----是用validationMode(默认是自动校验方式，意思是若是没有显示定义校验的方式就用XSD方式)和DocumentLoader(XmlBeanDefinitionReader中默认的是DefaultDocumentLoader)等参数调用DocumentLoader的loadDocument方法将Resource封装成Document类(具体封装方式不作介绍，有兴趣的能够本身了解一下，用的是builder模式作的)调用registerBeanDefinitions方法解析载入bean。

      registerBeanDefinitions方法是用BeanDefinitionDocumentReader的registerBeanDefinitions具体解析Document(树形结构，从root(就是beans标签)开始往下解析)中每一个element各个标签的解析和载入。其中若是是bean标签BeabDefinitionParserDelegate的parseBeanDefinitionElement方法对XML元素的信息按照spring的bean的规则进行解析(property的解析，当中value和ref解析方式不一样，若是是value构建TypedStringValue, 若是ref的话构建RuntimeBeanReference，这个在以后依赖注入的时候用到，还有id，name，等属性的解析)获得的BeanDefinition的封装BeanDefinitionHolder(包括BeanDefinition,beanName(这里是标识符的意思，若是有id，id作标识符，没有id，name属性中第一个别名作标识符)和别名列表(name属性中的内容，若是没有id，name中第一个不做为别名而是标识符))来进行下一步bean的注册（BeanDefinitionReaderUtils.registerBeanDefinition）。

      其余如import，alias等标签自行看源码理解。

三、BeanDefinition在IOC容器的注册

      BeanDefinitionReaderUtils.registerBeanDefinition用BeanDefinitionRegistry(DefaultListableBeanFactory)的registerBeanDefinition方法注册beanName和BeanDefinition(就是把beanName加入到一个已经注册的bean的beanName的Set中，而后put到beanName对应BeanDefinition的map中，其中若是不容许覆盖而且有同名beanName要报错)。再用BeanDefinitionRegistry的registerAlias方法注册beanName和别名列表(put到一个beanName对应alias的map中，其中若是有alias跟beanName相同的要移除)。

2、IOC容器依赖注入

一、getBean第一次调用lazy-init的bean

      是以BeanFactory的getBean方法为入口触发的(实如今AbstractBeanFactory实现类中)。若是是单例会缓存起来只加载一次，若是是FactoryBean这种特殊的bean会把这个bean的实例传入getObjectForBeanInstance方法得到FactoryBean产生的bean(调用FactoryBean的getObject方法，这就是自定义的FactoryBean要重写的方法，AOP也是这个原理，详情见下方AOP分析)。在第一次载入时要先判断这个BeanDefinition在当前BeanFactory有没有，没有就从双亲BeanFactory中找，一直递归。

      找到后要验证是否存在递归依赖，有则报错无则设置当前bean依赖bean的依赖关系到两个map中（一个是被依赖map，一个是依赖map），其中：
      (1)若是是单例第一次载入就调用getSingleton方法(方法中回调了参数中ObjectFactory的getObject方法，这里重写了这个方法调用createBean)得到实例用getObjectForBeanInstance得到FactoryBean产生的bean(若是它是FactoryBean的话)。
      (2)若是是prototype加载调用createBean后调用getObjectForBeanInstance。
      (3)若是是其余scope类型:request、session和global session,这三种就用scope.get获取实例(和getSingleton相似回调重写的getObject也就是调用createBean)后调用getObjectForBeanInstance。

      最后若是getBean指定了requiredType要检验获取的bean能不能转化成指定的类型不能的话就报错。

      createBean方法就是生成bean的方法并对一些好比init-method属性、后置处理器等一些初始化进行了处理。方法中在实例化以前判断是否有post-processor，若是有这样的processor则短路指定bean的建立，直接返回一个proxy而不是指定的bean（这种processor能够指定生成一个其余类型的对象）没有的话用doCreateBean建立bean返回。

      doCreateBean是用createBeanInstance生成BeanWrapper(包装bean)以后用populateBean向其中的bean完成依赖bean的注入(autowire等)。

      createBeanInstance建立beanWrapper时分三类进行处理：
      (1)若是有工厂方法，调用instantiateUsingFactoryMethod建立。
      (2)若是是构造器注入的方式调用autowireConstructor。
      (3)简单方式调用instantiateBean。调用的是策略类(默认SimpleInstantiationStrategy)的instantiate而其中又是经过bean方法是否有跟IOC容器同名的(会被覆盖)来分两类处理(没同名方法的从BeanDefinition中拿出class直接用jdk的反射拿构造器来newinstance一个实例，若是有同名的则是用CGLIB的方式来new一个实例)。

      populateBean为生成的bean依赖注入，先对非简单类型属性有autowire的进行处理，判断这个属性在以前解析载入beanDefinition时property里有没有，有的话进行getBean初始化后放入PropertyValue集合中(这个就是propertyname和value的封装)，而后更新依赖map，再对非autowire的或通常属性进行注入，有要转化的要通过valueResolver的转化(若是是RuntimeBeanReference以前载入时XML中配置是ref的就getBean(若是在双亲BeanFactory中就从双亲中取)得到后也放到PropertyValue集合中，也要更新依赖map)。最后再注入到bean中，这里说的注入其实真实发生在最后的BeanWraper的setPropertyValue(propertyValue集合)方法，具体实现就是经过反射的方式得到setter方法赋值。

二、lazy-init==false初始化(只对singleton，也是默认方式)

      在refresh方法中的finishBeanFactoryInitialization方法中进行初始化(实际也是调用getBean方法)。

Spring AOP

      ProxyFacotryBean是FacotryBean的一种实现，FacotryBean要产生bean都要重写getObject方法,而ProxyFacotryBean这里的这个getObject正是为代理作了准备并返回代理对象。首先用initializeAdvisorChain(第一次去取代理对象时初始化一遍)初始化Advisor链后对于singleton和prototype进行区分生成对应的proxy。

一、初始化Advisor链

      initializeAdvisorChain初始化Advisor链是遍历ProxyFacotryBean中配置的interceptorNames，若是结尾有通配符只能是ListableBeanFacotory来加载不然报错，去掉结尾通配符*后调用addGlobalAdvosor（这个是获取ListableBeanFacotory的全部globalAdvisorNames和globalInterceptorNames，分别遍历用getBean(beanName)获取advice，把其中符合通配符格式的advice调用addAdvisorOnChainCreation封装成advicsor后添加到Advisor链，若是结尾没有通配符的状况下不管是singleton仍是prototype在得到advice后都要用addAdvisorOnChainCreation方法注册到advisor链上。

    addAdvisorOnChainCreation用namedBeanToAdvisor方法把advice包装成advisor，判断若是advice是单例singleton的话是用AdvisorAdapterRegistry(默认DefaultAdvisorAdapterRegistry单例)wrap方法判断若是这个advice是MethodInterceptor或者AdvisorAdapterRegistry三种固定的adapter(before,afterreturning,throws)若是任一adapter支持的话(支持不支持就是在具体的adapter中判断advice是否是这个adapter对应具体的advice类的子类)就封装成DefaultPointcutAdvisor返回。若是是prototype的话不获取getBean，而是直接用name包装成PrototypePlaceholderAdvisor。

二、生成代理类

      以singleton为例，singleton代理的生成getSingletonInstance方法。是用AopProxyFactory(在构造器中设定了默认的DefaultAopProxyFactory)的createAopProxy方法根据ProxyFacotryBean中配置的target判断是不是个接口(实际上不是这么简单的区分，具体看源码了解)来建立不一样AopProxy的子类(JdkDynamicAopProxy或者ObjenesisCglibAopProxy(CglibAopProxy的子类，增长了ObjenesisStd))调用他们各自的getProxy方法以不一样的方式建立代理对象返回。

      JdkDynamicAopProxy就是以动态代理的方式构建代理对象返回(具体动态代理原理自行了解哦)。

      CglibAopProxy就是以Cglib的方式进行代理，Cglib采用了很是底层的字节码技术，其原理是经过字节码技术为一个类建立子类，并在子类中采用方法拦截的技术拦截全部父类方法的调用，顺势织入横切逻辑。具体细节超出这文章的范围拉。

      prototype代理的方式大体相同有些许的差异也不作介绍，能够参考源码。

三、调用时拦截

      在调用目标类的方法时由于代理调用的是invoke(jdk动态代理)或者intercept(cglib)。在invoke(jdk动态代理)或者intercept(cglib)中根据目标类被调用方法分别处理。      若是是hashCode和equals方法直接调用代理类中重写了的hashCode和equals方法(具体参考源码)。      若是是Adviced接口中定义的方法(ProxyFactoryBean就是Adviced接口实现类)直接以反射的方式拿到method调用方法(AopUtils的invokeJoinpointUsingReflection方法)。      其余状况就是拿到拦截器链(只初始化一次，每次调用时有个currentInterceptorIndex记录处理到第几个拦截器)调用拦截器的proceed方法前进调用。      proceed前进调用不是递归，其中用matcher进行匹配，若是匹配上调用拦截器的invoke方法，匹配不上就直接继续前进调用，拦截器interceptor的invoke方法就是通知方法(本身实现的如afterReturning等)对目标方法(实际是拦截器链的proceed前进调用)的具体增强，就是顺序问题等等。      直到拦截器链前进到底调用target目标类的对应方法(jdk反射获取method调用)。      初始化拦截器链是经过遍历以前IOC容器getBean获取到advisor链中的Advisor，经过AdvisorAdapterRegistry当中设置的3种adapter(before,afterreturning,throws)的supportsAdvice判断是否支持该advisor，若是支持就将advisor中的advice注册成不一样的AdviceInterceptor列表(一个advisor能够被多个adapter支持，由于只要本身写的通知类实现多种advice接口便可)都加入到拦截器链。