参考《Spring技术内幕》

1、重要概念:依赖反转

什么被反转了?依赖对象的获得被反转了。Martin Fowler为其起了个更好听的名字:依赖注入。如果合作对象地引用或依赖关系地管理由具体对象来完成,会导致代码地高耦合度和可测试性的降低。面向对象系统中,对象封装了数据和对数据的处理,对象的依赖关系常常体现在对数据和方法的依赖上。这些对象的依赖关系可以通过把对象的依赖注入交给框架或者IoC容器来完成,这种从具体对象手中交出控制的做法是非常有价值的,他可以在解耦代码的同时提高代码的可测试性。
Spring中,IoC是依赖反转模式的载体,他可以在对象生成或初始化时直接将数据注入到对象中,也可以通过将对象引用注入到对象数据域中的方式来注入对方法调用的依赖。这种依赖注入是可以递归的,对象会被逐层注入。就此而言,这种方法有一种完整而简洁的美感,他把对象的依赖关系有序的建立起来,简化了对象依赖的管理,在很大程度上简化了面向对象系统的复杂性。

注意:
应用控制反转后,当对象被创建时,由一个调控系统内的所有对象的外界实体将其所依赖的对象的引用传递给它,即依赖被注入到对象中。所以,控制反转是关于一个对象如何获取他所依赖的对象的引用,在这里,反转指的是责任的反转。
我们你可以认为上面提到的调控系统是应用平台,或者更具体地说是IoC容器。通过使用IoC容器,对象依赖关系的管理被反转了,转到IoC容器中来了,对象之间的相互依赖关系由IoC容器进行管理,并由IoC容器完成对象的注入。这样就在很大程度上简化了开发,把应用从复杂的对象依赖关系管理中解放出来。

2、Spring如何管理对象之间的依赖关系

不难想象,如果我们将对象的依赖关系交由IoC容器管理,那么就会思考IoC容器又是如何对对象依赖进行管理的呢?
在Spring中,通过定义BeanDefinition来管理基于Spring应用中的各种对象记忆他们之间的相互依赖关系。关于BeanDefinition可以参考https://blog.nowcoder.net/n/35ca4e62ba0a4c7d8c463faa3fbe951fBeanDefinition抽象了我们对Bean的定义,是让容器起作用的主要数据类型。我们都知道,在计算机世界里,所有的功能都是建立在通过数据对现实进行抽象的基础上的。IoC容器是用来管理对象关系的,对IoC容器来说,BeanDefinition就是对依赖反转模式中管理的对象依赖关系的数据抽象,也是容器实现依赖反转功能的核心数据结构,依赖反转功能都是围绕对这个BeanDefinition的处理来完成的。

3、关于BeanFactory和ApplicationContext

1、BeanFactory

1、应用场景

BeanFactory提供的是最基本的IoC容器功能,关于这些功能定义,我们可以在接口BeanFactory中看到。BeanFactory接口定义了IoC容器最基本的形式,并提供了IoC容器所应该遵守的最基本的服务契约,同时,这也是我们使用IoC容器所应遵守的最底层和最基本的编程规范,这些接口定义勾画出IoC的基本轮廓。
BeanFactory设计的getBean方法是使用IoC容器API的主要方法,通过这个方法可以获得容器中管理的Bean,Bean的取得是通过指定名字来索引的

BeanFactory提供了以下方法:
containsBean:容器中是否存在指定名字的Bean;
isSingleton:指定名字的Bean是不是单例的;
isPrototype:同上,多例;
isTypeMatch:指定名字Bean的Class类型是不是指定的Class;
getType:获得指定Bean的Class类型;
getAliases:查询Bean的全部别名,这些别名是用户在BeanDefinition中定义的。

2、设计原理

  • BeanFactory接口提供了使用IoC容器的规范。在这个基础上,Spring还提供了符合这个IoC容器接口的一系列容器的实现供开发人员使用。这里以XmlBeanFactory的实现为例来说明简单IoC容器的设计原理。
  • 在继承体系中,XmlBeanFactory继承自DefaultListableBeanFactory这个类,后者非常重要,是经常要用到的一个IoC容器的实现,比如在设计应用上下文ApplicationContext时就会用到它。DefaultListableBeanFactory实际上包含了基本IoC容器所具有的重要功能,通过查看源码可知许多我们正常使用的基本容器(如XmlBeanFactory)和ApplicationContext都是以这个容器为基础的。
  • 在Spring中,实际上是把DefaultListableBeanFactory作为一个默认的功能完整的IoC容器来使用的。XmlBeanFactory在继承了DefaultListableBeanFactory容器的功能的同时,增加了新的功能,这些功能很容易从XmlBeanFactory的名字上猜到。它是一个与XML相关的BeanFactory,也就是说它是一个可以读取以XML文件方式定义的BeanDefinition的IoC容器。构造XmlBeanFactory这个loC容器时,需要指定BeanDefinition的信息来源,而这个信息来源需要封装成Spring中的Resource类来给出。Resource是Spring用来封装I/O操作的类。比如,我们的BeanDefinition信息是以XML文件形式存在的,那么可以使用像ClassPathResourcere s=new ClassPathResource("beans.xml");这样具体的ClassPathResource来构造需要的Resource,然后将Resource作为构造参数传递给XmlBeanFactory构造函数。这样,IoC容器就可以方便地定位到需要的BeanDefinition信息来对Bean完成容器的初始化和依赖注入过程。
  • 参考了XmlBeanFactory的实现,我们可以了解到使用基本容器(这里指的是DefaultListableBeanFactory)的基本过程。需要几个关键的组件(Resource、BeanDefinitionReader和DefaultListableBeanFactory,其实也就是这三个组件来对应IoC初始化的三个过程:定位,载入和注册。定位就是找到相应的配置文件,转换为抽象资源(Resource),载入就是BeanDefinitionReader.loadBeanDefinitions(resource)所做的事,将抽象资源解析为BeanDefinition,BeanDefinition是Spring用来表示我们所定义的Bean的数据结构。注册就是将BeanDefinition“存储”在BeanFactory中。
下面是编程式使用IoC容器:
ClassPathResource res = new ClassPathResource("beans .xml");//定位
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(res);//开始载入的入口函数,载入完就注册
这样,我们就可以通过factory对象来使用DefaultListableBeanFactory这个IoC容器了。在使用IoC容器时,需要如下几个步骤:
1)创建IoC配置文件的抽象资源,这个抽象资源包含了BeanDefinition的定义信息;
2)创建一个BeanFactory,这里使用了DefaultListableBeanFactory;
3)创建一个载入BeanDefinition的读取器,这里使用XmlBeanDefinitionReader来载入XML文件形式的BeanDefinition,通过一个回调配置给BeanFactory;
4)从定义好的资源位置读入配置信息,具体解析过程由XmlBeanDefinitionReader来完成。完成整个载入和注册Bean定义后,需要的IoC容器就建立起来了。这个时候就可以直接使用容器了。

2、ApplicationContext应用程序上下文

1、应用场景

相比较基于BeanFactory拓展的那些容器,ApplicationContext是开发人员经常用到的,ApplicationContext除了能实现那些基本功能之外,还附加了BeanFactory不具备的高级特性,比如支持不同的信息源,能进行实现国际化(继承MessageResource),继承ResourceLoader来实现访问资源,继承ApplicationEventPublisher,支持应用事件,为管理Bean的生产周期提供了便利。
  • 支持不同的信息源。我们看到ApplicationContext扩展了MessageSource接口,这些信息源的扩展功能可以支持国际化的实现,为开发多语言版本的应用提供服务。
  • 访问资源。这一特性体现在对ResourceLoader和Resource的支持上,这样我们可以从不同地方得到Bean定义资源。这种抽象使用户程序可以灵活地定义Bean定义信息,尤其是从不同的I/O途径得到Bean定义信息。访问资源的功能在Spring中由ResourceLoader提供,实现与载入和注册的解耦。这在接口关系上看不出来,不过一般来说,具体ApplicationContext都是继承了DefaultResourceLoader的子类。因为DefaultResourceLoader是AbstractApplicationContext的基类。
  • 支持应用事件。继承了接口ApplicationEventPublisher,从而在上下文中引入了事件机制。这些事件和Bean的生命周期的结合为Bean的管理提供了便利。
  • 在ApplicationContext中提供的附加服务。这些服务使得基本IoC容器的功能更丰富。因为具备了这些丰富的附加功能,使得ApplicationContext与简单的BeanFactory相比,对它的使用是一种面向框架的使用风格,所以一般建议在开发应用时使用ApplicationContext作为IoC容器的基本形式。

在ApplicationContext容器中,以常用的FileSystemXmlApplicationContext的实现为例来说明ApplcationContext的设计原理。 在FileSystemXmlApplicationContext的设计中,ApplicationContext应用上下文的主要功能已经在FileSystemXmlApplicationContext前面的基类们中完成,主要功能是在AbstractXmlApplicationContext中实现的。在FileSystemXmlApplicationContext中,作为一个具体的应用上下文,只需要实现和它自身设计相关的两个功能。

  • 一个功能是,如果应用直接使用FileSystemXmlApplicationContext,对于实例化这个应用上下文的支持,同时启动IoC容器的refresh()过程。这在FileSystemApplicationContext的代码实现中可以看到,代码如下:
    /**
     * Create a new FileSystemXmlApplicationContext with the given parent,
     * loading the definitions from the given XML files.
     * @param configLocations array of file paths
     * @param refresh whether to automatically refresh the context,
     * loading all bean definitions and creating all singletons.
     * Alternatively, call refresh manually after further configuring the context.
     * @param parent the parent context
     * @throws BeansException if context creation failed
     * @see #refresh()
     */
    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException {

        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }

这个refresh()过程会牵涉IoC容器启动的一系列复杂操作,相当于一个入口,同时,对于不同的容器实现,这些操作都是类似的,因此在基类中将它们封装好(所以主要功能都是在基类中完成的)。所以,我们在FileSystemXml的设计中看到的只是一个简单的调用。

  • 另一个功能是与FileSystemXmlApplicationContext设计具体相关的功能,这部分与怎样从文件系统中加载XML的Bean定义资源有关。通过这个过程,可以为在文件系统中读取以XML形式存在的BeanDefinition做准备,因为不同的应用上T文实现对应着不同的读取BeanDefinition的方式,在FileSystemXmlApplicationContext中的实现代码如下:
    /**
     * Resolve resource paths as file system paths.
     * <p>Note: Even if a given path starts with a slash, it will get
     * interpreted as relative to the current VM working directory.
     * This is consistent with the semantics in a Servlet container.
     * @param path path to the resource
     * @return Resource handle
     * @see org.springframework.web.context.support.XmlWebApplicationContext#getResourceByPath
     */
    @Override
    protected Resource getResourceByPath(String path) {
        if (path != null && path.startsWith("/")) {
            path = path.substring(1);
        }
        return new FileSystemResource(path);
    }

4、IoC容器的初始化过程

前面说过IoC容器的初始化时refresh方法来启动的,这个方法标志着IoC容器的正式启动。具体来说,这个启动包含BeanDefinition的Resource定位、载入和注册三个基本过程。
三个过程:
  • 第一个过程是 Resource定位 过程。这个Resource定位指的是BeanDefinition的资源定位,它由ResourceLoader通过统一的Resource接口来完成,这个Resource对各种形式的BeanDefinition的使用都提供了统一接口。比如,在文件系统中的Bean定义信息可以使用FileSystemResource来进行抽象。在类路径中的Bean定义信息可以使用ClassPathResource来进行抽象等等。这个定位过程类似于容器寻找数据的过程,就像用水捅装水先要把水找到一样。
  • 第二个过程是 BeanDefinition的载入 。这个载入过程是把用户定义好的Bean表示成IoC容器内部的数据结构,而这个容器内部的数据结构就是BeanDefinition。下面介绍这个数据结构的详细定义。具体来说,这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象。通过这个BeanDefinition定义的数据结构,使IoC容器能够方便地对POJO对象也就是Bean进行管理。
  • 第三个过程是 向IoC容器注册这些Bean Definition 的过程。这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的。这个注册过程把载人过程中解析得到的BeanDeftnition向IoC容器进行注册。在IoC容器内部将BeanDefinition注人到一个HashMap中去,IoC容器就是通过这个HashMap来持有这些BeanDefinition数据的。
值得注意的是,这里谈的IoC容器初始化过程,一般不包含Bean依赖注入的实现。在Spring的IoC容器设计中,Bean定义的载入和依赖注入是两个独立的过程。依赖注入一般发生在应用第一次通过getBean方法向容器索取Bean的时候。但有一个例外,就是配置IoC容器的预实例化(Bean定义中的lazy_init属性)。如果对某个Bean设置了lazyinit属性,那么这个Bean的依赖注入在IoC容器初始化阶段就完成了。

1、BeanDefinition的Resoure定位

以编程的方式使用DefaultListableBeanFactory时,首先要定义一个Resources来定位容器使用的BeanDefinition。例如:ClassPathResource,FileSystemResource等,例如ClassPathResource,那么这意味着Spring将会在类路径中寻找以文件形式存在的BeanDefinition信息。
ClassPathResource res = new ClassPathResource("bean.xml");
但这里定义的Resources并不能由DefaultListableBeanFactory直接使用,Spring通过BeanDefinitionReader来对这些信息进行处理。通过这点,我们可以看到使用ApplicationContext相对于直接使用DefaultListableBeanFactory的好处。因为ApplicationContext中,Spring已经为我们提供了一系列加载不同Resource的读取器的实现,而DefaultListableBeanFactory只是一个单纯的IoC容器,需要为它配置特定的读取器才能完成这些功能。当然,有利就有弊,使用DefaultListableBeanFactory这种更为底层的容器,能提高定制IoC容器的灵活性。
我们使用的例子是ClassPathXmlApplicationContext, FileSystemXmlApplicationContext和他们的一些基类。AbstractXmlApplicationContext类是这两个类的基类,因为这两个类都是针对XML的操作,有很多相同的操作,所以这里用了模版模式把这两个类的共通部分给包装起来了。

总之,通过Resource定位的完成,就可以通过返回的Resource对象来进行BeanDefinition的载入了。在定位完成后,为BeanDefinition的载入创造了IO操作的条件,但是具体的数据还没有开始读入。这些数据的读入将在BeanDefinition的载入和解析中完成。到此,就相当于找到了水源,接下来就要开始打水了。

2、 BeanDefinition的载入和解析

BeanDefinition的载入过程,对于IoC容器来说,相当于把定义的BeanDefinition在容器中转化为一个Spring内部表示的数据结构的过程。容器对Bean的管理和依赖注入功能的实现,是通过对其特有的BeanDefinition进行各种相关操作来完成的。这些BeanDefinition数据在IoC容器中通过一个HashMap来保持和维护。

下面,从DefauItListaleBeanFactory 的设计入手,看看IoC 容器是怎样完成BeanDefinition载入的。在开始分析之前,先回到IoC容器的初始化入口,也就是看一下refresh方法。这个方法的最初是在FileSystemXmlApplicationContext的构造函数中被调用的, 它的调用标志着容器初始化的开始,这些初始化对象就是BeanDefinition数据,初始化入口如代码如下:
    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException {

        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }
对容器的启动来说, refresh是一个很重要的方法,下面介绍一下它的实现。该方法在AbstractApplicationContext类(它FileSystemXmlApplicationContext的基类)中找到。它详细地描述了整个AppIicationContext 的初始化过程,比如BeanFactory 的更新,MessageSource和PostProcessor的注册,等等。这里看起来更像是对ApplicationContext进行初始化的模板或执行提纲,这个执行过程为Bean的生命周期管理提供了条件。IoC容器的refresh过程如代码所示。
    public void refresh() throws BeansException, IllegalStateException {
        synchronized (this.startupShutdownMonitor) {
            // 容器初始化的一些准备工作.
            prepareRefresh();

            // 告知子类要初始化BeanFactory,BeanDefinition信息的读取是在子类的
            // refreshBeanFactory()方法里完成的
            ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

            // 准备bean工厂以在此上下文中使用。
            prepareBeanFactory(beanFactory);

            try {
                // 设置beanFactory的后置处理
                postProcessBeanFactory(beanFactory);
                // 调用beanFactory的后置处理
                invokeBeanFactoryPostProcessors(beanFactory);
                // 注册beanFactory的后置处理
                registerBeanPostProcessors(beanFactory);
                // 初始化上下文的消息
                initMessageSource();
                // 初始化上下的事件
                initApplicationEventMulticaster();
                // 初始化一些特殊的bean
                onRefresh();
                // 检查一些监听的bean并注册到容器中
                registerListeners();
                // Instantiate all remaining (non-lazy-init) singletons.
                finishBeanFactoryInitialization(beanFactory);
                // 发布容器事件,结束Refresh过程
                finishRefresh();
            }
            catch (BeansException ex) {
                if (logger.isWarnEnabled()) {
                    logger.warn("Exception encountered during context initialization - " +
                            "cancelling refresh attempt: " + ex);
                }

                // 销毁已经生成的bean
                destroyBeans();
                // 重置激活状态.
                cancelRefresh(ex);
                throw ex;
            }

            finally {
            
                resetCommonCaches();
            }
        }
    }
进入到AbstractRefresbableApplicationContext的refreshBeanFactory()方注中,在这个方法中创建了BeanFactory。在创建loC容器前,如果已经有容器存在,那么需要把已有的容器销毁和关闭,保证在refresh以后使用的是新建立起来的IoC容器。这么看来,这个refresh非常像重启动容器,就像重启动计算机那样。在建立好当前的IoC容器以后,开始了对容器的初始化过程,比如BeanDefinition的载入,具体的交互过程如图所示。


在初始化FileSystmXmlApplicationContext的过程中是通过调用IoC容器的refresh来启动整个BeanDefinition的载入过程的,这个初始化是通过定义的XmlBeanDefinitionReader来完成的。同时,我们也知道实际使用的IoC容器是DefuItListabIeBeanfactory ,具体的Resource载入在XmlBeanDefinitionReader读入BeanDefinition时实现。因为Spring可以对应不同形式的BeanDefinition,由于这里使用的是XML 方式的定义,所以需要使用XmlBeanDefinitionReader 。如果使用了其他的BeanDefinition方式,就需要使用其他种类的BeanDefinitionReader来完成数据的载入工作。在XmlBeanDefinitionReader的实现中可以看到,是在reader.loadBeanDefinitions 中开始进行BeanDefinition的载入的,而这时XmlBeanDefinitionReader的父类AbstractBeanDefinitionReader已经为BeanDefinition的载入做好了准备。

总的来说,BeanDefinition的载入分成两部分,首先通过调用XML的解析器得到document对象,但这些document对象并没有按照Spring的Bean规则进行解析。在完成通用的XML解析以后,才是按照Spring的Bean规则进行解析的地方,这个按照Spring的Bean规则进行解析的过程是在documentReader中实现的。这里使用的documentReader是默认设置好的DefaultBeanDefinitionDocumentReader。这个DefaultBeanDefinitionDocumentReader的创建是在后面的方法中完成的,然后再完成BeanDefinition的处理,处理的结果由BeanDefinitionHolder对象来持有。这个BeanDefinitionHolder除了持有BeanDefinition对象外,还持有其他与BeanDefinition的使用相关的信息,比如Bean 的名字、别名集合等。这个BeanDefinition-Holder的生成是通过对Document文档树的内容进行解析来完成的,可以看到这个解析过程是由BeanDefinitionParserDelegate来实现(具体在processBeanDefinition方法中实现)的,同时这个解析是与Spring对BeanDefinition的配置规则紧密相关的。
具体的Spring BeanDefinition的解析是在BeanDefinitionParserDelegate中完成的.这个类里包含了对各种Spring Bean定义规则的处理。在这里会看到对那些熟悉的BeanDefinition定义的处理,比如id 、name 、aliases等属性元素。把这些元素的值从XML文件相应的元素的属性中读 取出来以后,设置到生成的BeanDefinitionHolder中去。这些属性的解析还是比较简单的。对于其他元素配置的解析,比如各种Bean的属性配置,通过一个较为复杂的解析过程,这个过程是由parseBeanDefinitionElement来完成的。解析完成以后,会把解析结果放到BeanDefinition对象中并设置到BeanDefinitionHolder中去。

上面介绍了对Bean元素进行解析的过程,也就是BeanDefinition依据XML的 bean标签定义被创建的过程。这个BeanDefinition可以看成是对 bean标签定义的抽象,如图所示。

这个数据对象中封装的数据大多都是与 bean标签定义相关的,也有很多就是我们在定义Bean时看到的那些Spring标记,比如常见的init-method 、destroy-method 、factory-method , 等等,这个BeanDefinition数据类型是非常重要的,它封装了很多基本数据,这些基本数据都是IoC容器需要的。有了这些基本数据, IoC容器才能对Bean配置进行处理, 才能实现相应的容器特性。
beanClass 、description 、lazylnit这些属性都是在配置bean时经常碰到的,都集中在这里。这个BeanDefinition是IoC容器体系中非常重要的核心数据结构。通过解析以后,这些数据已经做好在IoC容器里大显身手的准备了。对BeanDefinition元素的处理如代码所示。
    public AbstractBeanDefinition parseBeanDefinitionElement(
            Element ele, String beanName, BeanDefinition containingBean) {

        this.parseState.push(new BeanEntry(beanName));

        String className = null;
        if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
            className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
        }

        try {
            String parent = null;
            if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
                parent = ele.getAttribute(PARENT_ATTRIBUTE);
            }
            AbstractBeanDefinition bd = createBeanDefinition(className, parent);

            parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
            bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));

            parseMetaElements(ele, bd);
            parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
            parseReplacedMethodSubElements(ele, bd.getMethodOverrides());

            parseConstructorArgElements(ele, bd);
            parsePropertyElements(ele, bd);
            parseQualifierElements(ele, bd);

            bd.setResource(this.readerContext.getResource());
            bd.setSource(extractSource(ele));

            return bd;
        }
        catch (ClassNotFoundException ex) {
            error("Bean class [" + className + "] not found", ele, ex);
        }
        catch (NoClassDefFoundError err) {
            error("Class that bean class [" + className + "] depends on not found", ele, err);
        }
        catch (Throwable ex) {
            error("Unexpected failure during bean definition parsing", ele, ex);
        }
        finally {
            this.parseState.pop();
        }

        return null;
    }
总之,经过这样逐层地解析,我们在XML文件中定义的BeanDefinition就被整个载入到了IoC容器中,并在容器中建立了数据映射。在IoC容器中建立了对应的数据结构,或者说可以看成是POJO对象在loC容器中的抽象,这些数据结构可以以AbstractBeanDefinition为入口,让IoC容器执行索引、查询和操作。简单的POJO操作背后其实蕴含着一个复杂的抽象过程,经过以上的载入过程, IoC容器大致完成了管理Bean对象的数据准备工作(或者说是初始化过程)。但是,重要的依赖注入实际上在这个时候还没有发生,现在,在IoC 容器BeanDefinition 中存在的还只是一些静态的配置信息。严格地说,这时候的容器还没有完全起作用,要完全发挥容器的作用,还需完成数据向容器的注册。

3、 BeanDefinition在IoC容器中的注册

前面已经分析过BeanDefinition在IoC容器中载入和解析的过程。在这些动作完成以后,用户定义的BeanDefinition信息已经在IoC容器内建立起了自己的数据结构以及相应的数据表示,但此时这些数据还不能供IoC容器直接使用,需要在IoC容器中对这些BeanDefinition数据进行注册。这个注册为IoC容器提供了更友好的使用方式,在DefaultListableBeanFactory中,是通过一个HashMap 来持有载入的BeanDefinition 的,这个HashMap 的定义在DefaultListableBeanFactory中可以看到,如下所示。
    private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(64);
将解析得到的BeanDefinition 向IoC容器中的beanDefiniti o nMap注册的过程是在载入BeanDefinition完成后进行的,注册的调用过程如图所示。
这里写图片描述
在DefaultListableBeanFactory和实现了BeanDefinitionRegistry的接口,这个接口的实现完成BeanDefinition向容器的注册。这个注册过程不复杂,就是把解析得到的BeanDefinition设置到HashMap中去。需要注意的是,如果遇到同名的BeanDefinition , 进行处理的时候需要依据allowBeanDefinitionOverriding的配置来完成。具体的实现如代码所示。
    public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
            throws BeanDefinitionStoreException {

        Assert.hasText(beanName, "Bean name must not be empty");
        Assert.notNull(beanDefinition, "BeanDefinition must not be null");

        if (beanDefinition instanceof AbstractBeanDefinition) {
            try {
                ((AbstractBeanDefinition) beanDefinition).validate();
            }
            catch (BeanDefinitionValidationException ex) {
                throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
                        "Validation of bean definition failed", ex);
            }
        }

        BeanDefinition oldBeanDefinition;
        //保证数据一致性,加锁
        synchronized (this.beanDefinitionMap) {
            //检查是不是有重名Definition,如果有,且又不允许覆盖,抛出异常
            oldBeanDefinition = this.beanDefinitionMap.get(beanName);
            if (oldBeanDefinition != null) {
                if (!this.allowBeanDefinitionOverriding) {
                    throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
                            "Cannot register bean definition [" + beanDefinition + "] for bean '" + beanName +
                            "': There is already [" + oldBeanDefinition + "] bound.");
                }
                else {
                    if (this.logger.isInfoEnabled()) {
                        this.logger.info("Overriding bean definition for bean '" + beanName +
                                "': replacing [" + oldBeanDefinition + "] with [" + beanDefinition + "]");
                    }
                }
            }
            //正常的注册流程
            else {
                this.beanDefinitionNames.add(beanName);
                this.frozenBeanDefinitionNames = null;
            }
            this.beanDefinitionMap.put(beanName, beanDefinition);
        }

        if (oldBeanDefinition != null || containsSingleton(beanName)) {
            resetBeanDefinition(beanName);
        }
    }
完成了BeanDefinition的注册,就完成了IoC容器的初始化过程。此时,在使用的IoC容器DefaultListableBeanFactory中已经建立了整个Bean的配置信息,而且这些BeanDefinition 已经可以被容器使用了, 它们都在beanDefinitionMap里被检索和使用. 容器的作用就是对这些信息进行处理和维护。这些信息是容器建立依赖反转的基础,有了这些基础数据, 下面我们看一下在IoC容器中,依赖注入是怎样完成的。

5、IoC容器的依赖注入

上面对IoC容器的初始化过程进行了详细的分析,这个初始化过程完成的主要工作是在IoC容器中建立BeanDefinition数据映射。在此过程中并没有看到IoC容器对Bean依赖关系进行注入,接下来分析一下IoC容器是怎样对Bean的依赖关系进行注入的。
假设当前IoC容器已经载入了用户定义的Bean信息,开始分析依赖注入的原理。首先, 注意到依赖注入的过程是用户第一次向IoC容器索要Bean时才触发的,当然也有例外,也就是我们可以在BeanDefinition信息中通过控制lazy-init属性来让容器完成对Bean的预实例化。这个预实例化实际上也是一个完成依赖注入的过程,但它是在初始化的过程中完成的,稍后我们会详细分析这个预实例化的处理。当用户向IoC容器索要Bean时。基本的loC容器接口BeanFactory中,有一个getBean的接口定义,这个接口的实现就是触发依赖注入发生的地方。为了进一步了解这个依赖注入过程的实现, 下面从DefaultListableBeanFactory的基类AbstractBeanFactory入手去看看getBean()的实现,如代码所示。
    //这里是对BeanFactory接口的实现,比如getBean接口方法
    //这些getBean接口方法最终是通过调用doGetBean来实现的
    public Object getBean(String name) throws BeansException {
        return doGetBean(name, null, null, false);
    }

    public <T> T getBean(String name, Class<T> requiredType) throws BeansException {
        return doGetBean(name, requiredType, null, false);
    }

    public Object getBean(String name, Object... args) throws BeansException {
        return doGetBean(name, null, args, false);
    }

    public <T> T getBean(String name, Class<T> requiredType, Object... args) throws BeansException {
        return doGetBean(name, requiredType, args, false);
    }
    //这里是实际取得Bean的地方,也是出发依赖注入的地方
    protected <T> T doGetBean(
            final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)
            throws BeansException {

        final String beanName = transformedBeanName(name);
        Object bean;
        //先从缓存中取得Bean,处理那些已经被创建过的单例模式的Bean,
        //这种Bean的请求不需要重复创建
        Object sharedInstance = getSingleton(beanName);
        if (sharedInstance != null && args == null) {
            if (logger.isDebugEnabled()) {
                if (isSingletonCurrentlyInCreation(beanName)) {
                    logger.debug("Returning eagerly cached instance of singleton bean '" + beanName +
                            "' that is not fully initialized yet - a consequence of a circular reference");
                }
                else {
                    logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
                }
            }
            /*这里的getObjectForBeanInstance方法完成的是FactoryBean的相关处理,以取得FactoryBean
            的生产结果*/
            bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
        }

        else {
            // Fail if we're already creating this bean instance:
            // We're assumably within a circular reference.
            if (isPrototypeCurrentlyInCreation(beanName)) {
                throw new BeanCurrentlyInCreationException(beanName);
            }
            /*这里对IoC容器中的BeanDefinition是否存在进行检查,检查能否在当前的BeanFactory
            中取得需要的Bean。如果在当前工厂中取不到,则到双亲BeanFactory中去取;如果当前的双亲
            工厂取不到,那就顺着双亲BeanFactory链一直向上找*/
            BeanFactory parentBeanFactory = getParentBeanFactory();
            if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
                // Not found -> check parent.
                String nameToLookup = originalBeanName(name);
                if (args != null) {
                    // Delegation to parent with explicit args.
                    return (T) parentBeanFactory.getBean(nameToLookup, args);
                }
                else {
                    // No args -> delegate to standard getBean method.
                    return parentBeanFactory.getBean(nameToLookup, requiredType);
                }
            }

            if (!typeCheckOnly) {
                markBeanAsCreated(beanName);
            }

            try {
                //根据Bean名字取得BeanDefinition
                final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
                checkMergedBeanDefinition(mbd, beanName, args);
                //获取当前Bean的所有依赖Bean,这样会触发getBean的递归调用,直到取到一个没有
                //任何依赖的Bean为止
                String[] dependsOn = mbd.getDependsOn();
                if (dependsOn != null) {
                    for (String dependsOnBean : dependsOn) {
                        getBean(dependsOnBean);
                        registerDependentBean(dependsOnBean, beanName);
                    }
                }

                // Create bean instance.
                /*这里通过调用createBean方法创建Singleton bean实例,这里有一个回调函数
                getObject,会在getSingleton中调用ObjectFactory的createBean*/
                if (mbd.isSingleton()) {
                    sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
                        public Object getObject() throws BeansException {
                            try {
                                return createBean(beanName, mbd, args);
                            }
                            catch (BeansException ex) {
                                // Explicitly remove instance from singleton cache: It might have been put there
                                // eagerly by the creation process, to allow for circular reference resolution.
                                // Also remove any beans that received a temporary reference to the bean.
                                destroySingleton(beanName);
                                throw ex;
                            }
                        }
                    });
                    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
                }
                //创建多例bean
                else if (mbd.isPrototype()) {
                    // It's a prototype -> create a new instance.
                    Object prototypeInstance = null;
                    try {
                        beforePrototypeCreation(beanName);
                        prototypeInstance = createBean(beanName, mbd, args);
                    }
                    finally {
                        afterPrototypeCreation(beanName);
                    }
                    bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
                }

                else {
                    String scopeName = mbd.getScope();
                    final Scope scope = this.scopes.get(scopeName);
                    if (scope == null) {
                        throw new IllegalStateException("No Scope registered for scope '" + scopeName + "'");
                    }
                    try {
                        Object scopedInstance = scope.get(beanName, new ObjectFactory<Object>() {
                            public Object getObject() throws BeansException {
                                beforePrototypeCreation(beanName);
                                try {
                                    return createBean(beanName, mbd, args);
                                }
                                finally {
                                    afterPrototypeCreation(beanName);
                                }
                            }
                        });
                        bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
                    }
                    catch (IllegalStateException ex) {
                        throw new BeanCreationException(beanName,
                                "Scope '" + scopeName + "' is not active for the current thread; " +
                                "consider defining a scoped proxy for this bean if you intend to refer to it from a singleton",
                                ex);
                    }
                }
            }
            catch (BeansException ex) {
                cleanupAfterBeanCreationFailure(beanName);
                throw ex;
            }
        }

        // Check if required type matches the type of the actual bean instance.
        if (requiredType != null && bean != null && !requiredType.isAssignableFrom(bean.getClass())) {
            try {
                return getTypeConverter().convertIfNecessary(bean, requiredType);
            }
            catch (TypeMismatchException ex) {
                if (logger.isDebugEnabled()) {
                    logger.debug("Failed to convert bean '" + name + "' to required type [" +
                            ClassUtils.getQualifiedName(requiredType) + "]", ex);
                }
                throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
            }
        }
        return (T) bean;
    }
这个就是依赖注入的入口,在这里触发了依赖注入,而依赖注入的发生是在容器中的BeanDefinition数据已经建立好的前提下进行的。“程序=数据+算法 ”很经典的一句话,前面的BeanDefinition就是数据,下面看看这些数据是怎样为依赖注入服务的。虽然依赖注入的过程不涉及复杂的算法问题,但这个过程也不简单,因为我们都知道,对于IoC容器的使用,Spring提供了许多的参数配置,每一个参数配置实际上代表了一个IoC容器的实现特性,这些特性的实现很多都需要在依赖注入的过程中或者对Bean进行生命周期管理的过程中完成。尽管可以用最简单的方式来描述loC容器,将它视为一个hashMap ,但只能说这个hashMap是容器的最基本的数据结构,而不是IoC容器的全部。Spring IoC容器作为一个产品,其价值体现在一系列相关的产品特性上,这些产品特性以依赖反转模式的实现为核心,为用户更好地使用依赖反转提供便利,从而实现了一个完整的loC容器产品。这些产品特性的实现并不是一个简单的过程,它提供了一个成熟的IoC容器产品供用户使用。
在下图中可以看到依赖注入的一个大致过程。

getBean是依赖注入的起点,之后会调用createBean ,下面通过createBean代码来了解这个实现过程。在这个过程中, Bean对象会依据BeanDefinition定义的要求生成。在AbstractAutowireCapableBeanFactory中实现了这个createBean, createBean不但生成了需要的Bean ,还对Bean初始化进行了处理,比如实现了在BeanDefinition中的init-method属性定义, Bean后置处理器等。
在这里我们看到,与依赖注入关系特别密切的方法有createBeanlnstance和populateBean(依赖注入核心方法),下面分别介绍这两个方法。在createBeanlnstance中生成了Bean所包含的Java对象,这个对象的生成有很多种不同的方式,可以通过工广方法生成,也可以通过容器的autowire特性生成, 这些生成方式都是自相关的BeanDefinition来指定的。
这里用CGLIB对Bean进行实例化. CGLIB是一个常用的字节码生成器的类库,它提供了一系列的API来提供生成和转换java的字节码的功能。在Spring AOP中也使用CGLIB对Java的字节码进行增强。在loC容器中,要了解怎样使用CGLIB来生成Bean对象,需要看一下SimplelnstantiationStrategy类。这个Strategy是Spring用来生成Bean对象的默认类,它提供了两种实例化Java对象的方法,一种是通过BeanUtils ,它使用了JVM的反射功能, 一种是通过前面提到的CGLIB来生成。
到这里已经分析了实例化Bean对象的整个过程。在实例化Bean对象生成的基础上,再介绍一下Spring是怎样对这些对象进行处理的,也就是Bean对象生成以后,怎样把这些Bean对象的依赖关系设置好,完成整个依赖注入过程。这个过程涉及对各种Bean对象的属性的处理过程(即依赖关系处理的过程),这些依赖关系处理的依据就是已经解析得到的BeanDefinition。要详细了解这个过程,需要回到前面的populateBean方法,这个方法在AbstractAutowireCapableBeanFactory中实现。
在完成这个解析过程后,已经为依赖注入准备好了条件,这是真正把Bean对象设置到它所依赖的另一个Bean的属性中去的地方,其中处理的属性是各种各样的。依赖注入的发生是在BeanWrapper的setPropertyValues 中实现的,具体的完成却是在BeanWrapper的子类Bean Wrapperlmpl中实现的。
这样就完成于对各种Bean属性的依赖注入过程。
在Bean的创建和对象依赖注入的过程中,需要依据BeanDefinition中的信息来递归地完成依赖注入。从上面的几个递归过程中可以看到,这些递归都是以getBean为入口的一个递归是在上下文体系中查找需要的Bean和创建Bean的递归调用,另一个递归是在依赖注入时,通过递归调用容器的getBean方法,得到当前Bean的依赖Bean ,同时也触发对依赖Bean的创建和注入。在对Bean的属性进行依赖注入时,解析的过程也是一个递归的过程。这样,根据依赖关系, 一层一层地完成Bean的创建和注入,直到最后完成当前Bean的创建。有了这个顶层Bean的创建和对它的属性依赖注入的完成,意味着和当前Bean相关的整个依赖链的注入也完成了。
在Bean创建和依赖注入完成以后,在IoC容器中建立起一系列依集依赖关系联系起来的Bean ,这个Bean 已经不是简单的Java对象了。该Bean系列以及Bean之间的依赖关系建立完成以后,通过IoC容器的相关接口方法,就可以非常方便地供上层应用使用了。
一图流对IoC容器初始化和单例Bean的实例化做一个总结: