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

ゝ一世哀愁。 2022-05-31 01:17 196阅读 0赞

# 本文为转载！！！ #

# Spring IOC #

## 一、容器初始化 ##

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

### 1、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定位。

### 2、从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等标签自行看源码理解。

### 3、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相同的要移除)。

## 二、IOC容器依赖注入   ![依赖注入][1984b2558df11fc87e121a02156848c9a898d5cb] ##

### 1、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方法赋值。

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

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

# Spring AOP #

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

## 1、初始化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。

## 2、生成代理类 ##

以singleton为例，singleton代理的生成getSingletonInstance方法。是用AopProxyFactory(在构造器中设定了默认的DefaultAopProxyFactory)的createAopProxy方法 根据ProxyFacotryBean中配置的target判断是否是个接口 (实际上不是这么简单的区分，具体看源码了解)来创建不同AopProxy的子类( JdkDynamicAopProxy 或者 ObjenesisCglibAopProxy (CglibAopProxy的子类，增加了ObjenesisStd))调用他们各自的getProxy方法以不同的方式创建代理对象返回。  
  
      JdkDynamicAopProxy就是以动态代理的方式构建代理对象返回(具体动态代理原理自行了解哦)。  
  
      CglibAopProxy就是以Cglib的方式进行代理，Cglib采用了非常底层的字节码技术，其原理是通过字节码技术为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用，顺势织入横切逻辑。具体细节超出这文章的范围拉。  
  
      prototype代理的方式大致相同有些许的差别也不做介绍，可以参考源码。

## 3、调用时拦截 ##

在调用目标类的方法时因为代理调用的是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接口即可)都加入到拦截器链。

[ioc]: /images/20220531/6721d6e3b97c465abb64ab8d86167a90.png
[1984b2558df11fc87e121a02156848c9a898d5cb]: /images/20220531/7d208a027075446fa69648dd3e893094.png
[aop]: /images/20220531/9c9839a40fed4fc09666d6a41ea8aec5.png