编程学习笔记

Spring解析之IoC：bean的加载（三）

2018-03-09  本文已影响233人  宝之家

前言
计划赶不上变化，原本年前准备将这个主题告一段落，但各种工作之外的事接踵而至，且剩下的工作量依然超过我的预期，只能拖到现在，前段时间接了商业化广告的活，源码看得多了自己写时总不自觉的按更高的标准要求自己，一遍遍的修改重构，这可能就是所谓的潜移默化吧
bean加载三部曲中的第一部按照doGetBean(String, Class<T>, Object[], boolean)自上而下的代码结构将加载分为if-else两段，前段在getBean显式调用时返回单例对象以及自定义FactoryBean生成bean时调用，其中的重点为部分解决循环依赖的“三层缓存”和getObjectForBeanInstance(Object, String, String, RootBeanDefinition)，后段由初始化过程中隐式调用以及获得多例对象时调用，在第二部中介绍了隐式调用的整个流程，最后剩下createBean(String, RootBeanDefinition, Object[])核心创建bean尚未分析，本篇文章就与这部分内容相关

由于只剩下createBean这个核心方法了，那么我们还是像前面将核心方法分成几块讲解

图1. AbstractAutowireCapableBeanFactory的createBean(String, RootBeanDefinition, Object[])
标注1生成最终能实例化的Class类型，但并没有根据Class实例化出对象
图2. 解析出可实例化的Class
在分析解析XML并将解析后内容封装成GenericBeanDefinition过程中曾今说过<bean>中class属性与GenericBeanDefinition父类AbstractBeanDefinition中Object beanClass对应，这里mbd.hasBeanClass()就是判断beanClass是否instanceof Class，如果是直接返回，因为我们要的就是Class类型，不是的话最终调用doResolveBeanClass(RootBeanDefinition, Class<?>)，该方法依然是个中转方法，主要根据传入的typesToMatch生成特定的ClassLoader，之后还要调用RootBeanDefinition#resolveBeanClass，根据特定的加载器或者默认加载器加载出class属性对应的Class对象，其生成Class的动作又委派给工具类ClassUtils
图3. 使用ClassUtils创建出Class
我们将创建Class流程分成三部分：第一部分主要处理一些“原始”数据类型，举个简单的例子我在XML中配置如下 
<bean id="myInt" class="java.lang.Integer">

我定义的对象就是“原始”数据类型，这种类型的Class处理就由第一部分负责，具体是怎么做的呢，实际上是两个Map，一个是resolvePrimitiveClassName(String)中隐含的primitiveTypeNameMap，另一个就是commonClassCache，对应的代码给大家看一下

图4. 原始Class元素的塞入
在ClassUtils加载时就会将基本数据类型，基本数据类型对应的包装类型，基本数据类型数组和包装类型数组等Class放入两个Map中，如果我们配置的类属于其中的一个直接返回对应的Class即可。图3红框2内代码处理的类型为java.lang.String[]、[Ljava.lang.String;和[[Ljava.lang.String;，第一个我可以尝试模拟出来，后两个实在没搞明白怎么模拟，有知道的读者麻烦告知。如果之前根据typesToMatch生成了特定的类加载器就用这个ClassLoader加载Class，否则使用默认加载器，默认类加载是首先使用当前线程类加载器，如果还是没有获取到使用当前类的类加载器。这一系列的操作后RootBeanDefinition中的beanClass属性除了异常情况就都是对应<bean>生成对象的Class了
回到图1标注2代码是对<lookup-method>和<replaced-method>两种method injection方式的预处理，在Spring解析之IoC：<bean>解析及Bean的注册中我们没有详细阐述两个标签的解析存储过程，在这里大致了解一下，两个标签解析后分别封装在LookupOverride和ReplaceOverride中，两个对象都继承自抽象父类MethodOverride，而多个该类对象又存放在AbstractBeanDefinition成员变量MethodOverrides methodOverrides中，下面我已<lookup-method>举个例子，说明下此类标签的用法已经解决的问题
<lookup-method>标签最重要的一个用途就是在单例对象内注入一个多例对象，我们知道构造器注入和setter注入是两种最常用的注入方式，但如果说到实现单例对象中注入多例对象需求，这两种注入方式都鞭长莫及，因为在Spring创建出单例对象时相关的依赖注入流程都已经完成，也就是说依赖的对象只能注入一次，为了解决这个问题，Spring提出了method injection方法注入，我们先来例子让大家有个直观的认识。首先定义一个单例对象SingletonService
图5. SingletonService
该类是一个抽象类，存在返回多例对象的抽象方法，再定义一个多例对象的抽象接口Prototype
图6. Prototype接口
有接口了必然有就有一个或多个实现，这里为了简便只提供了一个实现类
图7. Prototype接口的实现类MyPrototype
在XML中进行<bean>配置
图8. 相关XML配置
实现类scope = prototype否则就失去了动态注入的意义了，lookup-method中name获得多例对象的抽象方法名称，bean为返回bean的类型，比如这里就是任何实现了Prototype接口的实现类id/name，如果读者想跟深入了解的话，我给出一篇文章Method Injection。说了一堆做铺垫再来看图1标注2做了什么
图9. AbstractBeanDefinition的prepareMethodOverrides()
上面说过所有的方法注入标签都存放在methodOverrides，遍历所有的MethodOverride，根据<lookup-method>或<replaced-method>中抽象方法名(name属性的值)和抽象类中所有同名的抽象方法比较，算出符合name的抽象方法数量，为什么要这样呢？我试验了一下，结果是可能存在同名重载方法，最简单的例子就是同名抽象方法但参数不同，但<lookup-method>或<replaced-method>中有无法配置抽象方法的参数，所以需要全部计数。那为什么但只存在一个符合抽象方式时setOverloaded(false)呢？其实读者可以将这里的判断和下面的使用分为两部分考虑，如果存在多个重载方法，那么使用时必定要再次判断到底配置的是哪一个，如果只有一个符合要求这里加上一个标识，在下面使用的时候就省去了再次判断的开销
图1的标注3主要的目的在注释上写的还是比较清楚的，给用户一个机会可以返回目标对象的代理实例，如果返回不为null，即返回了代理对象就直接返回，在正式说这部分逻辑之前还得先补充一个知识，在前面说过Spring提供后处理器接口BeanPostProcessor，提供了在初始化对象后修改实例的能力，该接口有很多子接口，后面有机会会一一介绍，现在先说一种InstantiationAwareBeanPostProcessor，除了父类提供的两个待实现接口外又提供了另外三种，分别为Object postProcessBeforeInstantiation(Class<?>, String)、boolean postProcessAfterInstantiation(Object, String)和PropertyValues postProcessPropertyValues(PropertyValues, PropertyDescriptor[], Object, String)，为了更好的说明还是举个例子
图10. InstantiationAwareBeanPostProcessorImpl
InstantiationAwareBeanPostProcessorImpl实现了接口所有的方法，并做了一些打印以便观看现象，在XML中也加上简单的配置 
<bean id="student" class="com.xiaomi.bean.Student">
    <property name="name" value="zhangsan"></property>
</bean>
<bean id="instantiationAwareBeanPostProcessor" class="com.xiaomi.bean.InstantiationAwareBeanPostProcessorImpl"></bean>

运行并两次获得Student实例打印，结果如下

图11. InstantiationAwareBeanPostProcessor例子运行结果
很明显在生成Student实例前调用了postProcessBeforeInstantiation，那么我们可以在这个时候对目标对象进行一定的包装或者处理，达到类似AOP的目的，之后真正创建了Student实例，创建完成进行属性的注入，在注入之前会调用postProcessPropertyValues，在该方法中我们将原本注入的zhangsan替换成了lisi，“调包”后Spring调用了setter进行属性注入，最后才调用父接口BeanPostProcessor的两个方法，这个顺序之前已经说过，没什么意外的。我们获得了两次Student对象由打印语句发现实现InstantiationAwareBeanPostProcessor只会在创建对象前调用一次，当然，如果这里Student是多例，自然就会被第二次处理。讲到这里我们将postProcessBeforeInstantiation注释去除，在运行一遍看看结果有什么不同
图12. 去除postProcessBeforeInstantiation注释部分去除运行结果
我们发现只剩下postProcessBeforeInstantiation和postProcessAfterInitialization两个方法的调用(Student构造器也是在postProcessBeforeInstantiation中显式调用的，而不是Spring容器创建对象时默认调用)，为什么会出现这种情况，其实我们回到源码看一下处理逻辑就都清楚了
图13. AbstractAutowireCapableBeanFactory的resolveBeforeInstantiation(String, RootBeanDefinition)
上图代码对应图1的标注3，在初始化时Spring会检测是否存在自定义类实现了InstantiationAwareBeanPostProcessor接口，如果存在会将DefaultListableBeanFactory中成员变量hasInstantiationAwareBeanPostProcessors置为true，这里的boolean hasInstantiationAwareBeanPostProcessors()判断通过调用第一个下划线方法
图14. AbstractAutowireCapableBeanFactory的applyBeanPostProcessorsBeforeInstantiation(Class<?>, String)
逻辑很简单，首先获得所有后处理器，判断其中所有实现InstantiationAwareBeanPostProcessor的类，进而调用它的postProcessBeforeInstantiation，最后将我们自己实现方法的返回值返回。resolveBeforeInstantiation根据是否返回对象(代理)判断是否调用applyBeanPostProcessorsAfterInitialization(RootBeanDefinition, String)
图15. AbstractAutowireCapableBeanFactory的applyBeanPostProcessorsAfterInitialization(Object, String)
方法中调用了BeanPostProcessor的postProcessAfterInitialization(Object, String)，再看看图1的总流程，如果bean != null就直接返回，联想上面的例子bean != null实际上就是我们生成代理的情况，那就是说如果有代理直接返回代理对象，且只会调用InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation和BeanPostProcessor#postProcessAfterInitialization，所表现出来的结果正是例子图12的样子，既然调了包返回了代理那就没有必要再创建原始的目标类了，否则进入图1标注4创建目标类实例的代码，代码清单2 
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {
  // Instantiate the bean.
  BeanWrapper instanceWrapper = null;
  if (mbd.isSingleton()) {
    //    (1)
    instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
  }
  if (instanceWrapper == null) {
    //    （2）
    instanceWrapper = createBeanInstance(beanName, mbd, args);
  }
  final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
  Class<?> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);

  // Allow post-processors to modify the merged bean definition.
  synchronized (mbd.postProcessingLock) {
    if (!mbd.postProcessed) {
      //    (3)
      applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
      mbd.postProcessed = true;
    }
  }

  // Eagerly cache singletons to be able to resolve circular references
  // even when triggered by lifecycle interfaces like BeanFactoryAware.
  //    （4）
  boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
      isSingletonCurrentlyInCreation(beanName));
  if (earlySingletonExposure) {
    if (logger.isDebugEnabled()) {
      logger.debug("Eagerly caching bean '" + beanName +
          "' to allow for resolving potential circular references");
    }
    //    （5）
    addSingletonFactory(beanName, new ObjectFactory<Object>() {
      public Object getObject() throws BeansException {
        return getEarlyBeanReference(beanName, mbd, bean);
      }
    });
  }

  // Initialize the bean instance.
  Object exposedObject = bean;
  try {
    //    （6）
    populateBean(beanName, mbd, instanceWrapper);
    if (exposedObject != null) {
      //    （7）
      exposedObject = initializeBean(beanName, exposedObject, mbd);
    }
  }
  catch (Throwable ex) {
    if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
      throw (BeanCreationException) ex;
    }
    else {
      throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
    }
  }
  //    （8）
  if (earlySingletonExposure) {
    Object earlySingletonReference = getSingleton(beanName, false);
    if (earlySingletonReference != null) {
      if (exposedObject == bean) {
        exposedObject = earlySingletonReference;
      }
      else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
        String[] dependentBeans = getDependentBeans(beanName);
        Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
        for (String dependentBean : dependentBeans) {
          if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
            actualDependentBeans.add(dependentBean);
          }
        }
        if (!actualDependentBeans.isEmpty()) {
          throw new BeanCurrentlyInCreationException(beanName,
              "Bean with name '" + beanName + "' has been injected into other beans [" +
              StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
              "] in its raw version as part of a circular reference, but has eventually been " +
              "wrapped. This means that said other beans do not use the final version of the " +
              "bean. This is often the result of over-eager type matching - consider using " +
              "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
        }
      }
    }
  }

  // Register bean as disposable.
  try {
    //    （9）
    registerDisposableBeanIfNecessary(beanName, bean, mbd);
  }
  catch (BeanDefinitionValidationException ex) {
    throw new BeanCreationException(mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
  }

  return exposedObject;
}

Spring首先创建了一个bean的包装类，按照官方文档上的说法提供该类的好处有：1.提供了设置单个和成块属性值的功能，可以获得属性的descriptors，查询属性是否可读可写；2.支持属性的无限嵌套；2.具有不改变目标类代码情况下，添加PropertyChangeListeners和VetoableChangeListeners功能等。还想深入了解该类的读者可以看Bean manipulation and the BeanWrapper。如果缓存中已经存在我们后续要操作的BeanWrapper，直接移除取出做后续处理如标注1，如果暂时不存在该对象标注2处代码进行创建，此处是getBean核心逻辑之一，Spring根据创建对象方式的不同又在该方法内部分为三部分：1.根据factory-method工厂方法进行创建；2.匹配一个或多个参数的有参构造器创建；3.默认无参进行实例化。后续会用专门的文章对这三种方式的创建流程进行分析。
到目前为止我们已经遇过两个后处理器相关的接口，一个是BeanPostProcessor，另一个是它的子接口InstantiationAwareBeanPostProcessor，标注3又会引出一个BeanPostProcessor的子接口MergedBeanDefinitionPostProcessor，除了父接口的两个方法外还需实现该接口的类给出postProcessMergedBeanDefinition(RootBeanDefinition, Class<?>, String)，前面我们说过如果<bean>存在父子关系，Spring在解析之后会将父子关系的<bean>映射成为RootBeanDefinition，那么该后处理器及待实现方法就是在做RootBeanDefinition的后处理工作
标注4根据：1.是否单例；2.是否允许循环引用标志；3.beanName对应的bean是否正在创建中三个条件决定是否允许“早期单例暴露”。同样的，我们说过Spring中部分解决循环依赖的第三级缓存正是标注5的代码，如果判断允许“早期单例暴露”就将创建该单例对象的ObjectFactory存入三级缓存singletonFactories。当要获得单例对象时Spring会调用自定义ObjectFactory的getObject()，其实就是这里的getEarlyBeanReference(String, RootBeanDefinition, Object)

图16. 获得早期单例对象引用getEarlyBeanReference(String, RootBeanDefinition, Object)
这里又出现一个新的后处理器SmartInstantiationAwareBeanPostProcessor，它继承自InstantiationAwareBeanPostProcessor，新提供了三个待实现方法：1.Class<?> predictBeanType(Class, String)用于预测返回bean的Class类型，一般在隐式初始化时调用；2.Constructor<?>[] determineCandidateConstructors(Class<?>, String)存在多个构造器时用于决定使用哪个进行类的初始化，在上面说过的通过有参构造器创建对象时调用；3.Object getEarlyBeanReference(Object, String)用于获得早期暴露的单例对象引用，和MergedBeanDefinitionPostProcessor类似，一般不需要我们人为扩展，而是Spring内部自己使用。标注6主要是对BeanWrapper进行属性的填充，代码清单3 
protected void populateBean(String beanName, RootBeanDefinition mbd, BeanWrapper bw) {
        PropertyValues pvs = mbd.getPropertyValues();
                //    (1)
        if (bw == null) {
            if (!pvs.isEmpty()) {
                throw new BeanCreationException(
                        mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
            }
            else {
                // Skip property population phase for null instance.
                return;
            }
        }

        // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the
        // state of the bean before properties are set. This can be used, for example,
        // to support styles of field injection.
        boolean continueWithPropertyPopulation = true;
                //      (2)
        if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
            for (BeanPostProcessor bp : getBeanPostProcessors()) {
                if (bp instanceof InstantiationAwareBeanPostProcessor) {
                    InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
                    if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
                        continueWithPropertyPopulation = false;
                        break;
                    }
                }
            }
        }

        if (!continueWithPropertyPopulation) {
            return;
        }
                //      (3)
        if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
                mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
            MutablePropertyValues newPvs = new MutablePropertyValues(pvs);

            // Add property values based on autowire by name if applicable.
            if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
                autowireByName(beanName, mbd, bw, newPvs);
            }

            // Add property values based on autowire by type if applicable.
            if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
                autowireByType(beanName, mbd, bw, newPvs);
            }

            pvs = newPvs;
        }

        boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
        boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
                //      (4)
        if (hasInstAwareBpps || needsDepCheck) {
            PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
            if (hasInstAwareBpps) {
                for (BeanPostProcessor bp : getBeanPostProcessors()) {
                    if (bp instanceof InstantiationAwareBeanPostProcessor) {
                        InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
                        pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
                        if (pvs == null) {
                            return;
                        }
                    }
                }
            }
            if (needsDepCheck) {
                checkDependencies(beanName, mbd, filteredPds, pvs);
            }
        }
                //      (5)
        applyPropertyValues(beanName, mbd, bw, pvs);
    }

Spring初始化解析XML配置文件时，所有的<property>会放入PropertyValue的集合中，集合又被封装入MutablePropertyValues对象中。标注1的判断逻辑是，如果不存在是<bean>对应实体BeanWrapper但还存在解析出的属性，肯定出现问题了，抛出异常；如果不存在实体也不存在属性，那也没有继续往下解析的必要了，直接返回。标注2又一次用到了上面讲过的InstantiationAwareBeanPostProcessor，如果存在实现该接口后处理器，则调用boolean postProcessAfterInstantiation(Object, String)，进行对象实例创建后的处理，这里依然存在一个短路操作，如果方法返回false，continueWithPropertyPopulation为假，如果该值非真，也无需进行后处理器对于属性处理等后续操作了。标注3很明显涉及按名称、按类型两种属性注入方式，后续会有专门文章分析注入原理，这里不做阐述。标注4根据是否有InstantiationAwareBeanPostProcessor或依赖检查标识判断是否进行属性的“调包”处理，处理的过程就是InstantiationAwareBeanPostProcessor自有方法的最后一个PropertyValues postProcessPropertyValues(PropertyValues, PropertyDescriptor[], Object, String)。到这里Spring得到了所有需要填充的属性（两种方式注入的、后处理器调包的），最后调用标注5处代码真正将属性设置进BeanWrapper对象中，代码清单4

    protected void applyPropertyValues(String beanName, BeanDefinition mbd, BeanWrapper bw, PropertyValues pvs) {
        if (pvs == null || pvs.isEmpty()) {
            return;
        }

        MutablePropertyValues mpvs = null;
        List<PropertyValue> original;

        if (System.getSecurityManager() != null) {
            if (bw instanceof BeanWrapperImpl) {
                ((BeanWrapperImpl) bw).setSecurityContext(getAccessControlContext());
            }
        }
                //    (1)
        if (pvs instanceof MutablePropertyValues) {
            mpvs = (MutablePropertyValues) pvs;
            if (mpvs.isConverted()) {
                // Shortcut: use the pre-converted values as-is.
                try {
                    bw.setPropertyValues(mpvs);
                    return;
                }
                catch (BeansException ex) {
                    throw new BeanCreationException(
                            mbd.getResourceDescription(), beanName, "Error setting property values", ex);
                }
            }
            original = mpvs.getPropertyValueList();
        }
        else {
            original = Arrays.asList(pvs.getPropertyValues());
        }
                //      (2)
        TypeConverter converter = getCustomTypeConverter();
        if (converter == null) {
            converter = bw;
        }
        BeanDefinitionValueResolver valueResolver = new BeanDefinitionValueResolver(this, beanName, mbd, converter);
                //      (3)
        // Create a deep copy, resolving any references for values.
        List<PropertyValue> deepCopy = new ArrayList<PropertyValue>(original.size());
        boolean resolveNecessary = false;
        for (PropertyValue pv : original) {
            if (pv.isConverted()) {
                deepCopy.add(pv);
            }
            else {
                String propertyName = pv.getName();
                Object originalValue = pv.getValue();
                                //    (4)
                Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue);
                Object convertedValue = resolvedValue;
                boolean convertible = bw.isWritableProperty(propertyName) &&
                        !PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);
                if (convertible) {
                                        //    (5)
                    convertedValue = convertForProperty(resolvedValue, propertyName, bw, converter);
                }
                //     (6)
                if (resolvedValue == originalValue) {
                    if (convertible) {
                        pv.setConvertedValue(convertedValue);
                    }
                    deepCopy.add(pv);
                }
                //    (7)
                else if (convertible && originalValue instanceof TypedStringValue &&
                        !((TypedStringValue) originalValue).isDynamic() &&
                        !(convertedValue instanceof Collection || ObjectUtils.isArray(convertedValue))) {
                    pv.setConvertedValue(convertedValue);
                    deepCopy.add(pv);
                }
                else {
                    resolveNecessary = true;
                    deepCopy.add(new PropertyValue(pv, convertedValue));
                }
            }
        }
        //    (8)
        if (mpvs != null && !resolveNecessary) {
            mpvs.setConverted();
        }

        // Set our (possibly massaged) deep copy.
        try {
            //    (9)
            bw.setPropertyValues(new MutablePropertyValues(deepCopy));
        }
        catch (BeansException ex) {
            throw new BeanCreationException(
                    mbd.getResourceDescription(), beanName, "Error setting property values", ex);
        }
    }

标注1首先判断所有属性整体是否都被转换，如果是就不需要下面的步骤，直接赋值返回；如果并不是所有属性已经转换过，就会首先按标注2获取用户自定义的类型转换器。标注3创建了新集合用于存放转换后的结果，之后遍历每一个属性并依次判断转换与否，没有转换则标注4根据上面创建的解析器valueResolver对该值进行解析，我们知道除了最普通的String外Spring支持多种形式的属性配置，该方法中就包含了几乎所有类型属性的解析流程，这里给出一张表格涉及所有解析的类型已经该类型在读取XML时对应的封装类型

真实类型 封装类型
Array ManagedArray
List ManagedList
Set ManagedSet
Map ManagedMap
Bean BeanDefinitionHolder
ref引用Bean RuntimeBeanReference
idref RuntimeBeanNameReference
Properties ManagedProperties
String TypedStringValue
SPEL表达式 TypedStringValue

如果判断该属性是可转换的convertible = true，就会开始标注5的自定义转换器的转换，如果原始值originalValue与经过Spring内置解析器解析后的值resolvedValue相同，且可转换标识convertible为真说明必定经过了自定义转换的步骤（不管是否真的转换过），此时用最新的convertedValue替换老值，如果标识6所示。实际上我觉得标注6和7具有相同的目的，只要convertible为真就说明最新的值必然为convertedValue，那也必然要更新属性封装对象对应字段了。标注8将属性对象设为整体已转化，与方法一开始根据此判断直接返回还是开始转换相呼应。标注9终于将解析后数组封装入MutablePropertyValues，再塞入BeanWrapper中，至此创建对象中的属性填充流程分析完毕
接着代码清单2分析看标注7，“初始化”Bean

图17. AbstractAutowireCapableBeanFactory的initializeBean(String, Object, RootBeanDefinition)
该方法严格意义上来说并不是做了Bean的初始化，因为此时参数的bean已经是实例化完成的对象了，只不过该对象还在Spring内部，并没有暴露给用户，方法内主要做了三件事：1.感知类对象相关属性的设置；2.后处理器方法的处理；3.init-method属性的处理。我们一个个来看，如果bean实现了BeanNameAware、BeanClassLoaderAware和BeanFactoryAware三种Aware接口中的一个或多个，则调用对应的实现方法，虽然大家可能对这三者不太熟悉，另一个Aware接口ApplicatonContextAware相信大家都用过，该接口的setApplicationContext(ApplicationContext)能让我们得到Spring的上下文对象，ApplicatonContextAware和这里的三个接口处理方式如出一辙，只是触发时机不同，前者是在bean后处理阶段触发，后者则是在这里的Spring容器生命周期初始阶段
红线2又碰到bean后处理器了，后处理器有多种变体，上面提到过InstantiationAwareBeanPostProcessor和SmartInstantiationAwareBeanPostProcessor，并且在Spring解析之IoC：bean的加载（一）中也用例子的形式详解了BeanPostProcessor的用法，有了前面的基础这里后处理器也就非常好理解了，标注2和4分别对应了BeanPostProcessor的Object postProcessBeforeInitialization(Object, String)和Object postProcessAfterInitialization(Object, String)，方法内会遍历所有实现BeanPostProcessor接口的类调用每个类的上述两个方法。同样的在Spring解析之IoC：bean的加载（一）的BeanPostProcessor例子中我们曾经说过后处理器的before/after是相对于实现了InitializingBean接口afterPropertiesSet()方法的执行时刻来说的，那么看图中标注3不是正处在前后方法中间吗？我们有理由猜测invokeInitMethods(String, Object, RootBeanDefinition)就是对于afterPropertiesSet()的处理
图18. AbstractAutowireCapableBeanFactory的invokeInitMethods(String, Object, RootBeanDefinition)
横线代码验证了我们的猜测，但是我们发现除了调用afterPropertiesSet()外还有一处红框内的逻辑没有想到。之前说过Spring提供了三对在bean初始化和销毁时进行自定义操作的手段：1.@PostConstruct/@PreDestory；2.<bean>的init-method/destroy-method属性；3.实现InitializingBean/DisposableBean接口，这段代码就是针对第二种情况进行的处理，方法invokeCustomInitMethod(String, Object, RootBeanDefinition)内部做了一些权限控制后得到配置init-method的Method对象，最终通过反射调用该方法
初始化bean方法分析完毕，我们回到图17从宏观看看各个流程的步骤，其实这就是Spring容器中bean生命周期那张图的执行流程
图19. Spring中Bean的生命周期
  1. Instantiate对应代码清单2标注2instanceWrapper = createBean(beanName, mbd, args);第一次创建bean
  2. Popluate properties对应代码清单3整个属性填充过程
  3. BeanNameAware's setBeanName()对应图17invokeAwareMethods(String, Object)处理第一个BeanNameAware流程
  4. BeanFactoryAware's setBeanFactory()对应图17invokeAwareMethods(String, Object)处理第三个BeanFactoryAware流程
  5. Pre-initializatioin beanPostProcessors对应图17标注2代码applyBeanPostProcessorsBeforeInitialization(Object, String)
  6. InitializingBean's afterPropertiesSet()对应图18红线处逻辑
  7. Call custom init-method对应图18红框内代码
  8. Post-initialization beanPostProcessors对应图17标注4代码applyBeanPostProcessorsAfterInitialization(Object, String)

生命周期中的最后两个状态虽然现在没有遇到，但大家看名字就很明显9与6InitializingBean接口对应，一个初始化一个销毁；10destroy-method属性和7init-method对应。记得刚学习Spring时，这个生命周期是永远记不住的知识点，但整个源码分析下来就清清爽爽了
回到主线代码清单2，标注8处代码看上去一大堆，实际这段被执行到的可能性很小，earlySingleton = true会调用我们曾今说的Object getSingleton(String, boolean)，我们将方法放在现在的“语境”中再分析一下

图20. 特定场景下的Object getSingleton(String, boolean)执行流程图
读者需要知道的是，这段代码在new ClassPathXmlApplicationContext()隐式调用和getBean多例对象时才有可能调用，对于多例来说earlySingletonExposure = false，意味着代码不会执行；对于隐式调用allowEarlyReference = false说明红框处内的代码不会执行，再结合代码清单2标注5addSingletonFactory(String, ObjectFactory)可以推得只存在singletonObjects中已有beanName对应对象这一种可能，整个逻辑代码才会往下执行，介于此该流程就不继续往下分析了。最后看下代码清单2标注9
图21. AbstractBeanFactory的registerDisposableBeanIfNecessary(String, Object, RootBeanDefinition)
该方法的主要作用是对实现Disposable接口的对象进行注册，注意，这里只是注册，因为销毁必定是在容器关闭时调用的，而这里所有的一切都是对象初始化流程，所以只能是注册，并且只有单例对象且实现Disposable接口的destroy()或者实现DestructionAwareBeanPostProcessor接口的postProcessBeforeDestruction(Object, String)才会真正注册。注册分为两大块，单例的和自定义scope的。单例对象销毁注册调用registerDisposableBean(String, DisposableBean)，将beanName-bean映射放入Map<String, Object> disposableBeans即结束；自定义scope由于需要实现Scope接口，其中就包含这里的registerDestructionCallback(String, Runnable)。至此Spring获取bean逻辑基本讲解完毕，阶段性胜利，哈哈
上一篇 下一篇

猜你喜欢

热点阅读