IOC 容器

1. IOC容器

这章重点说明IOC容器.

1.1. Spring IoC容器和bean的介绍

本章介绍Spring框架中控制反转 Inversion of Control 的实现. IOC与大家熟知的依赖注入同理，指的是对象仅通过构造函数参数、工厂方法的参数或在对象实例构造以后或从工厂方法返回以后，在对象实例上设置的属性来定义它们的依赖关系（即它们使用的其他对象). 然后容器在创建bean时注入这些需要的依赖。 这个过程基本上是bean本身的逆过程（因此称为IOC），通过使用类的直接构造或服务定位器模式等机制来控制其依赖项的实例化或位置。

org.springframework.beans 和 org.springframework.context 是实现Spring IOC容器框架的基础. BeanFactory 接口提供了一种更先进的配置机制来管理任意类型的对象. ApplicationContext 是BeanFactory的子接口. 他提供了:

• 更容易与Spring的AOP特性集成

• 消息资源处理(用于国际化)

• 事件发布

• 应用层特定的上下文，如用于web应用程序的WebApplicationContext.

简而言之，BeanFactory提供了配置框架的基本功能，ApplicationContext添加了更多特定于企业的功能。 ApplicationContext完全扩展了BeanFactory的功能，这些内容将在介绍Spring IoC容器的章节专门讲解。有关使用BeanFactory更多信息，请参见BeanFactory。

在Spring中，由Spring IOC容器管理的，构成程序的骨架的对象成为Bean。bean对象是指经过IoC容器实例化，组装和管理的对象。此外，bean就是应用程序中众多对象之一 。bean和bean的依赖由容器所使用的配置元数据反射而来。

1.2. 容器概述

org.springframework.context.ApplicationContext是Spring IoC容器实现的代表，它负责实例化，配置和组装Bean。容器通过读取配置元数据获取有关实例化、配置和组装哪些对象的说明 。配置元数据可以使用XML、Java注解或Java代码来呈现。它允许你处理应用程序的对象与其他对象之间的互相依赖关系。

Spring提供了ApplicationContext接口的几个实现。 在独立应用程序中，通常创建ClassPathXmlApplicationContext或FileSystemXmlApplicationContext的实例。虽然XML一直是定义配置元数据的传统格式， 但是您可以指定容器使用Java注解或编程的方式编写元数据格式，并通过提供少量的XML配置以声明对某些额外元数据的支持。

在大多数应用场景中，不需要用户显式的编写代码来实例化IOC容器的一个或者多个实例。例如，在Web应用场景中，只需要在web.xml中添加大概8行简单的web描述样板就行了。（ 便捷的ApplicationContext实例化Web应用程序） 如果你使用的是基于Eclipse的Spring Tool Suite开发环境，该样板配置只需点击几下鼠标或按几下键盘就能创建了。

下图展示了Spring工作方式的高级视图，应用程序的类与元数据配置相互配合，这样，在ApplicationContext创建和初始化后，你立即拥有一个可配置的，可执行的系统或应用程序。

图 1. IOC容器

1.2.1. 配置元数据

如上图所示，Spring IOC容器使用元数据配置这种形式，这个配置元数据表示了应用开发人员告诉Spring容器以何种方式实例化、配置和组装应用程序中的对象。

配置元数据通常以简单、直观的XML格式提供，本章的大部分内容都使用这种格式来说明Spring IoC容器的关键概念和特性。

XML并不是配置元数据的唯一方式，Spring IoC容器本身是完全与元数据配置的实际格式分离的。现在，许多开发人员选择基于Java的配置来开发应用程序。

更多其他格式的元数据见:

• 基于注解的配置: Spring 2.5 支持基于注解的元数据配置.

• 基于Java的配置: 从 Spring 3.0开始, 由Spring JavaConfig项目提供的功能已经成为Spring核心框架的一部分。因此，你可以使用Java配置来代替XML配置定义外部bean 。要使用这些新功能，请参阅 @Configuration, @Bean, @Import, 和 @DependsOn annotations.

Spring配置至少一个（通常不止一个）由容器来管理。基于XML的元数据配置将这些bean配置为<bean/>元素，并放置于<bean/>元素内部。 典型的Java配置是在使用@Configuration注解过的类中，在它的方法上使用@Bean注解。

这些bean定义会对应到构成应用程序的实际对象。通常你会定义服务层对象，数据访问对象（DAOs），表示对象(如Struts Action的实例)，基础对象（如Hibernate 的SessionFactories, JMS Queues）。通常不会在容器中配置细粒度的域对象，但是，因为它的创建和加载通常是DAO和业务逻辑的任务。 但是，你可以使用Spring与AspectJ 集成独立于 IoC 容器来创建的对象，请参阅AspectJ在Spring中进行依赖关系注入域对象

下面的示例显示了基于XML元数据配置的基本结构:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="..." class="...">  (1) (2)
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <bean id="..." class="...">
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <!-- more bean definitions go here -->

</beans>

1

id 属性是字符串 ，用来识别唯一的bean定义.

2

class 属性定义了bean的类型，使用全类名.

id属性的值是指引用协作对象（在这个例子没有显示用于引用协作对象的XML）。请参阅依赖获取更多信息

1.2.2. 实例化容器

提供给ApplicationContext构造函数的路径就是实际的资源字符串，使容器能从各种外部资源(如本地文件系统、Java类路径等)装载元数据配置。

ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

当你了解Spring IoC容器，你可能想知道更多关于Spring的抽象资源（详细描述资源）它提供了一种方便的，由URI语法定义的位置读取InputStream描述的方式 ，资源路径被用于构建应用程序上下文应用环境和资源路径

下面的例子显示了服务层对象(services.xml)配置文件::

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <!-- services -->

    <bean id="petStore" class="org.springframework.samples.jpetstore.services.PetStoreServiceImpl">
        <property name="accountDao" ref="accountDao"/>
        <property name="itemDao" ref="itemDao"/>
        <!-- additional collaborators and configuration for this bean go here -->
    </bean>

    <!-- more bean definitions for services go here -->

</beans>

下面的示例显示了数据访问对象（daos.xml）配置文件:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="accountDao"
        class="org.springframework.samples.jpetstore.dao.jpa.JpaAccountDao">
        <!-- additional collaborators and configuration for this bean go here -->
    </bean>

    <bean id="itemDao" class="org.springframework.samples.jpetstore.dao.jpa.JpaItemDao">
        <!-- additional collaborators and configuration for this bean go here -->
    </bean>

    <!-- more bean definitions for data access objects go here -->

</beans>

在上面的例子中，服务层由PetStoreServiceImpl类，两个数据访问对象JpaAccountDao类和JpaItemDao类（基于JPA对象/关系映射标准）组成 property name元素是指JavaBean属性的名称，而ref元素引用另一个bean定义的名称。id和ref元素之间的这种联系表达了组合对象之间的相互依赖关系。有关对象间的依赖关系，请参阅依赖 .

组合基于XML的元数据配置

使用XML配置，可以让bean定义分布在多个XML文件上，这种方法直观优雅清晰明显。通常，每个单独的XML配置文件代表架构中的一个逻辑层或模块。

你可以使用应用程序上下文构造函数从所有这些XML片段加载bean定义，这个构造函数可以输入多个资源位置，如上一节所示。 或者，使用<import/>元素也可以从另一个（或多个）文件加载bean定义。例如：

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>

上面的例子中，使用了3个文件：services.xml, messageSource.xml, 和 themeSource.xml来加载外部Bean的定义。 导入文件采用的都是相对路径，因此services.xml必须和导入文件位于同一目录或类路径中，而messageSource.xml 和 themeSource.xml 必须在导入文件的资源位置中。正如你所看到的，前面的斜线将会被忽略，但考虑到这些路径是相对的，最佳的使用是不用斜线的。 这个XML文件的内容都会被导入，包括顶级的 <beans/>元素，但必须遵循Spring Schema定义XML bean定义的规则 。

这种相对路径的配置是可行的，但不推荐这样做，引用在使用相对于”../“路径的父目录文件中，这样做会对当前应用程序之外的文件产生依赖关系。 特别是对于classpath:: URLs(例如classpath:../services.xml)，不建议使用此引用，因为在该引用中，运行时解析过程选择“最近的”classpath根目录，然后查看其父目录。 类路径的变化或者选择了不正确的目录都会导致此配置不可用。

您可以使用完全限定的资源位置而不是相对路径:例如，file:C:/config/services.xml或者classpath:/config/services.xml.。 但是，请注意，您正在将应用程序的配置与特定的绝对位置耦合。通常会选取间接的方式应对这种绝对路径，例如使用占位符“${…}”来解决对JVM系统属性的引用。

import 是由bean命名空间本身提供的功能。在Spring提供的XML命名空间中，如“context”和“util”命名空间，可以用于对普通bean定义进行更高级的功能配置。

DSL定义Groovy Bean

作为从外部配置元数据的另一个示例，bean定义也可以使用Spring的Groovy DSL来定义。Grails框架有此配置实例，通常， 可以在具有以下结构的”.groovy”文件中配置bean定义。例如：

beans {
    dataSource(BasicDataSource) {
        driverClassName = "org.hsqldb.jdbcDriver"
        url = "jdbc:hsqldb:mem:grailsDB"
        username = "sa"
        password = ""
        settings = [mynew:"setting"]
    }
    sessionFactory(SessionFactory) {
        dataSource = dataSource
    }
    myService(MyService) {
        nestedBean = { AnotherBean bean ->
            dataSource = dataSource
        }
    }
}

这种配置风格在很大程度上等价于XML bean定义，甚至支持Spring的XML配置名称空间。它还允许通过importBeans指令导入XML bean定义文件。

1.2.3. 使用容器

ApplicationContext是能够创建bean定义以及处理相互依赖关系的高级工厂接口，使用方法T getBean(String name, Class<T> requiredType)获取容器实例。

ApplicationContext可以读取bean定义并访问它们 如下 :

// create and configure beans
ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

// retrieve configured instance
PetStoreService service = context.getBean("petStore", PetStoreService.class);

// use configured instance
List<String> userList = service.getUsernameList();

使用Groovy配置引导看起来非常相似，只是用到不同的上下文实现类：它是Groovy感知的（但也需理解XML bean定义） 如下:

ApplicationContext context = new GenericGroovyApplicationContext("services.groovy", "daos.groovy");

最灵活的变体是GenericApplicationContext，例如读取XML文件的XmlBeanDefinitionReader。如下面的示例所示:

GenericApplicationContext context = new GenericApplicationContext();
new XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml");
context.refresh();

您还可以为Groovy文件使用GroovyBeanDefinitionReader，如下面的示例所示:

GenericApplicationContext context = new GenericApplicationContext();
new GroovyBeanDefinitionReader(context).loadBeanDefinitions("services.groovy", "daos.groovy");
context.refresh();

这一类的读取可以在同一个 ApplicationContext上混合使用，也可以自动匹配，如果需要可以从不同的配置源读取bean定义。

您可以使用 getBean来获取bean实例， ApplicationContext接口也可以使用其他的方法来获取bean。但是在理想情况下，应用程序代码永远不应该使用它们。 事实上，你的应用程序代码也不应该调用的getBean()方法，因此对Spring API没有依赖。例如，Spring与Web框架的集成为各种Web框架组件(如控制器和JSF管理bean） 提供了依赖项注入功能，从而允许开发者通过元数据声明对特定bean的依赖(例如，自动注解）。

1.3. Bean 的概述

Spring IoC容器管理一个或多个bean。这些bean是由您提供给容器的元数据配置创建的(例如，XML <bean/>定义的形式)。

在容器内部，这些bean定义表示为BeanDefinition对象，其中包含（其他信息）以下元数据

• 限定包类名称: 通常，定义的bean的实际实现类。

• bean行为配置元素, 定义Bean的行为约束(例如作用域，生命周期回调等等）

• bean需要引用其他bean来完成工作. 这些引用也称为协作或依赖关系.

• 其他配置用于新对象的创建，例如使用bean的数量来管理连接池，或者限制池的大小。

以下是每个bean定义的属性:

Table 1. Bean的定义

除了bean定义包含如何创建特定的bean的信息外，ApplicationContext实现还允许用户在容器中注册现有的、已创建的对象。 通过getBeanFactory()访问到返回值为DefaultListableBeanFactory的实现的ApplicationContext的BeanFactory DefaultListableBeanFactory支持通过registerSingleton(..)和registerBeanDefinition(..)方法来注册对象。 然而，典型的应用程序只能通过元数据配置来定义bean。

为了让容器正确推断它们在自动装配和其它内置步骤，需要尽早注册Bean的元数据和手动使用单例的实例。虽然覆盖现有的元数据和现有的单例实例在某种程度上是支持的， 但是新bean在运行时(同时访问动态工厂）注册官方并不支持，可能会导致并发访问异常、bean容器中的不一致状态，或者两者兼有。

1.3.1. 命名bean

每个bean都有一个或多个标识符，这些标识符在容器托管时必须是唯一的。bean通常只有一个标识符，但如果需要到的标识不止一个时，可以考虑使用别名。

在基于XML的配置中，开发者可以使用id属性，name属性或两者都指定bean的标识符。 id属性允许您指定一个id，通常这些名字使用字母和数字的组合(例如’myBean’, ‘someService’，等等），但也可以包含特殊字符。 如果你想使用bean别名，您可以在name属性上定义，使用逗号(,），分号(;)，或白色空格进行分隔。由于历史因素， 请注意，在Spring 3.1之前的版本中，id属性被定义为xsd:ID类型，它会限制某些字符。从3.1开始，它被定义为xsd:string类型。请注意，由于bean id的唯一性，他仍然由容器执行，不再由XML解析器执行。

您也无需提供bean的name或 id，如果没有显式地提供name或 id，容器会给bean生成唯一的名称。 然而，如果你想引用bean的名字，可以使用ref元素或使用Service Locator（服务定位器）来进行查找（此时必须提供名称）。 不使用名称的情况有： 内部bean和自动装配的协作者

Bean 的命名约定

bean的命名是按照标准的Java字段名称命名来进行的。也就是说，bean名称开始需要以小写字母开头，后面采用“驼峰式”的方法。 例如accountManager,accountService, userDao, loginController等。

一致的beans命名能够让配置更方便阅读和理解，如果你正在使用Spring AOP，当你通过bean名称应用到通知时，这种命名方式会有很大的帮助。

在类路径中进行组件扫描时， Spring 会根据上面的规则为未命名的组件生成 bean 名称，规则是：采用简单的类名，并将其初始字符转化为小写字母。 然而，在特殊情况下，当有一个以上的字符，同时第一个和第二个字符都是大写时，原来的规则仍然应该保留。这些规则与Java中定义实例的相同。 例如Spring使用的java.beans.Introspector.decapitalize 类。

为外部定义的bean起别名

在对bean定义时，除了使用id属性指定唯一的名称外，还可以提供多个别名，这需要通过name属性指定。 所有这个名称都会指向同一个bean，在某些情况下提供别名非常有用，例如为了让应用每一个组件都能更容易的对公共组件进行引用。

然而，在定义bean时就指定所有的别名并不是很恰当的。有时期望能够在当前位置为那些在别处定义的bean引入别名。在XML配置文件中， 可以通过<alias/>元素来定义bean别名，例如：

<alias name="fromName" alias="toName"/>

上面示例中，在同一个容器中名为fromName 的bean定义，在增加别名定义后，也可以使用toName来引用。

例如，在子系统A中通过名字subsystemA-dataSource配置的数据源。在子系统B中可能通过名字 subsystemB-dataSource来引用。 当两个子系统构成主应用的时候，主应用可能通过名字myApp-dataSource引用数据源，将全部三个名字引用同一个对象，你可以将下面的别名定义添加到应用配置中：

<alias name="subsystemA-dataSource" alias="subsystemB-dataSource"/>
<alias name="subsystemA-dataSource" alias="myApp-dataSource" />

现在，每个组件和主应用程序都可以通过一个唯一的名称引用dataSource，并保证不与任何其他定义冲突（有效地创建命名空间），但它们引用相同的bean。 .

Java配置

如果你是用java配置， @Bean可以用来提供别名，详情见使用@Bean 注解。

1.3.2. 实例化Bean

bean定义基本上就是用来创建一个或多个对象的配置，当需要bean的时候，容器会查找配置并且根据bean定义封装的元数据来创建（或获取）实际对象。

如果你使用基于XML的配置，那么可以在<bean/> 元素中通过 class属性来指定对象类型。 class属性实际上就是BeanDefinition实例中的class属性。他通常是必需的（一些例外情况，查看 使用实例工厂方法实例化 和 Bean 定义的继承)。有两种方式使用Class属性

• 通常情况下，会直接通过反射调用构造方法来创建bean，这种方式与Java代码的new创建相似。

• 通过静态工厂方法创建，类中包含静态方法。通过调用静态方法返回对象的类型可能和Class一样，也可能完全不一样。

内部类名

如果你想配置静态内部类，那么必须使用内部类的二进制名称。

例如，在com.example有个SomeThing类，这个类里面有个静态内部类OtherThing，这种情况下bean定义的class属性应该写作 com.example.SomeThing$OtherThing.

使用$字符来分隔外部类和内部类的名称

使用构造器实例化

当您通过构造方法创建bean时，所有普通类都可以使用并与Spring兼容。也就是说，正在开发的类不需要实现任何特定接口或以特定方式编码。 只要指定bean类就足够了。但是，根据您为该特定bean使用的IoC类型，您可能需要一个默认（空）构造函数。

Spring IoC容器几乎可以管理您希望它管理的任何类。它不仅限于管理真正的JavaBeans。大多数Spring用户更喜欢管理那些只有一个默认构造函数（无参数） 和有合适的setter和getter方法的真实的JavaBeans，还可以在容器中放置更多的外部非bean形式（non-bean-style)类，例如：如果需要使用一个绝对违反JavaBean规范的遗留连接池时 Spring也是可以管理它的。

使用基于XML的配置元数据，您可以按如下方式指定bean类：:

<bean id="exampleBean" class="examples.ExampleBean"/>

<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

给构造方法指定参数以及为bean实例化设置属性将在后面的依赖注入中说明。

使用静态工厂方法实例化

当采用静态工厂方法创建bean时，除了需要指定class属性外，还需要通过factory-method 属性来指定创建bean实例的工厂方法。 Spring将会调用此方法（其可选参数接下来会介绍）返回实例对象。从这样看来，它与通过普通构造器创建类实例没什么两样。

下面的bean定义展示了如何通过工厂方法来创建bean实例。注意，此定义并未指定对象的返回类型，只是指定了该类包含的工厂方法，在这个例中， createInstance()必须是一个静态（static）的方法。

<bean id="clientService"
    class="examples.ClientService"
    factory-method="createInstance"/>

以下示例显示了一个可以使用前面的bean定义的类:

public class ClientService {
    private static ClientService clientService = new ClientService();
    private ClientService() {}

    public static ClientService createInstance() {
        return clientService;
    }
}

给工厂方法指定参数以及为bean实例设置属性的详细内容请查阅依赖和配置详解 。

使用实例工厂方法实例化

通过调用工厂实例的非静态方法进行实例化与通过静态工厂方法实例化类似， 要使用此机制，请将class属性保留为空，并在factory-bean属性中指定当前（或父级或祖先）容器中bean的名称，该容器包含要调用以创建对象的实例方法。 使用factory-method属性设置工厂方法本身的名称。以下示例显示如何配置此类bean：

<!-- the factory bean, which contains a method called createInstance() -->
<bean id="serviceLocator" class="examples.DefaultServiceLocator">
    <!-- inject any dependencies required by this locator bean -->
</bean>

<!-- the bean to be created via the factory bean -->
<bean id="clientService"
    factory-bean="serviceLocator"
    factory-method="createClientServiceInstance"/>

以下示例显示了相应的Java类:

public class DefaultServiceLocator {

    private static ClientService clientService = new ClientServiceImpl();

    public ClientService createClientServiceInstance() {
        return clientService;
    }
}

一个工厂类也可以包含多个工厂方法，如以下示例所示:

<bean id="serviceLocator" class="examples.DefaultServiceLocator">
    <!-- inject any dependencies required by this locator bean -->
</bean>

<bean id="clientService"
    factory-bean="serviceLocator"
    factory-method="createClientServiceInstance"/>

<bean id="accountService"
    factory-bean="serviceLocator"
    factory-method="createAccountServiceInstance"/>

以下示例显示了相应的Java类:

public class DefaultServiceLocator {

    private static ClientService clientService = new ClientServiceImpl();

    private static AccountService accountService = new AccountServiceImpl();

    public ClientService createClientServiceInstance() {
        return clientService;
    }

    public AccountService createAccountServiceInstance() {
        return accountService;
    }
}

这种方法表明可以通过依赖注入（DI）来管理和配置工厂bean本身。请参阅详细信息中的依赖和配置详解。

在Spring文档中，“factory bean”是指在Spring容器中配置并通过实例 或 静态工厂方法 创建对象的bean。相比之下，FactoryBean（注意大小写）是指Spring特定的FactoryBean。

1.4. 依赖

一般情况下企业应用不会只有一个对象（Spring Bean），甚至最简单的应用都需要多个对象协同工作。下一节将解释如何从定义单个Bean到让多个Bean协同工作。

1.4.1. 依赖注入

依赖注入是让对象只通过构造参数、工厂方法的参数或者配置的属性来定义他们的依赖的过程。这些依赖也是其他对象所需要协同工作的对象， 容器会在创建Bean的时候注入这些依赖。整个过程完全反转了由Bean自己控制实例化或者依赖引用，所以这个过程也称之为“控制反转”

当使用了依赖注入的特性以后，会让开发者更容易管理和解耦对象之间的依赖，使代码变得更加简单。对象之间不再关注依赖，也不需要知道依赖类的位置。如此一来，开发的类更易于测试 尤其是当开发者的依赖是接口或者抽象类的情况时，开发者可以轻易地在单元测试中mock对象。

依赖注入主要使用两种方式，一种是基于构造函数的注入，另一种的基于Setter方法的依赖注入。

基于构造函数的依赖注入

基于构造函数的依赖注入是由IoC容器来调用类的构造函数，构造函数的参数代表这个Bean所依赖的对象。构造函数的依赖注入与调用带参数的静态工厂方法基本一样。 调用具有特定参数的静态工厂方法来构造bean几乎是等效的，本讨论同样处理构造函数和静态工厂方法的参数。下面的例子展示了一个通过构造函数来实现依赖注入的类。:

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on a MovieFinder
    private MovieFinder movieFinder;

    // a constructor so that the Spring container can inject a MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

请注意，这个类没有什么特别之处。 它是一个POJO，它不依赖于容器特定的接口，基类或注解。

解析构造器参数

构造函数的参数解析是通过参数的类型来匹配的。如果在Bean的构造函数参数不存在歧义，那么构造器参数的顺序也就是就是这些参数实例化以及装载的顺序。参考如下代码：

package x.y;

public class ThingOne {

    public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
        // ...
    }
}

假设ThingTwo和ThingThree类与继承无关，也没有什么歧义。下面的配置完全可以工作正常。开发者无需再到<constructor-arg/>元素中指定构造函数参数的index或type

<beans>
    <bean id="thingOne" class="x.y.ThingOne">
        <constructor-arg ref="thingTwo"/>
        <constructor-arg ref="thingThree"/>
    </bean>

    <bean id="thingTwo" class="x.y.ThingTwo"/>

    <bean id="thingThree" class="x.y.ThingThree"/>
</beans>

当引用另一个bean时，如果类型是已知的，匹配就会工作正常（与前面的示例一样）。当使用简单类型的时候（例如<value>true</value>）， Spring IoC容器无法判断值的类型，所以也是无法匹配的，考虑代码：

package examples;

public class ExampleBean {

    // Number of years to calculate the Ultimate Answer
    private int years;

    // The Answer to Life, the Universe, and Everything
    private String ultimateAnswer;

    public ExampleBean(int years, String ultimateAnswer) {
        this.years = years;
        this.ultimateAnswer = ultimateAnswer;
    }
}

构造函数参数类型匹配

在前面的场景中，如果使用 type 属性显式指定构造函数参数的类型，则容器可以使用与简单类型的类型匹配。如下例所示：

<bean id="exampleBean" class="examples.ExampleBean">
    <constructor-arg type="int" value="7500000"/>
    <constructor-arg type="java.lang.String" value="42"/>
</bean>

构造函数参数索引

您可以使用index属性显式指定构造函数参数的索引，如以下示例所示：

<bean id="exampleBean" class="examples.ExampleBean">
    <constructor-arg index="0" value="7500000"/>
    <constructor-arg index="1" value="42"/>
</bean>

除了解决多个简单值的歧义之外，指定索引还可以解决构造函数具有相同类型的两个参数的歧义。

index 从0开始。

构造函数参数名称

您还可以使用构造函数参数名称消除歧义，如以下示例所示：:

<bean id="exampleBean" class="examples.ExampleBean">
    <constructor-arg name="years" value="7500000"/>
    <constructor-arg name="ultimateAnswer" value="42"/>
</bean>

需要注意的是，解析这个配置的代码必须启用了调试标记来编译，这样Spring才可以从构造函数查找参数名称。开发者也可以使用@ConstructorProperties注解来显式声明构造函数的名称。 例如下面代码:

package examples;

public class ExampleBean {

    // Fields omitted

    @ConstructorProperties({"years", "ultimateAnswer"})
    public ExampleBean(int years, String ultimateAnswer) {
        this.years = years;
        this.ultimateAnswer = ultimateAnswer;
    }
}

基于setter方法的依赖注入

基于setter函数的依赖注入是让容器调用拥有Bean的无参构造函数，或者无参静态工厂方法，然后再来调用setter方法来实现依赖注入。

下面的例子展示了使用setter方法进行的依赖注入的过程。其中类对象只是简单的POJO，它不依赖于容器特定的接口，基类或注解。

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;

    // a setter method so that the Spring container can inject a MovieFinder
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

ApplicationContext所管理Bean同时支持基于构造函数和基于setter方法的依赖注入，同时也支持使用setter方法在通过构造函数注入依赖之后再次注入依赖。 开发者在BeanDefinition中可以使用PropertyEditor实例来自由选择注入方式。然而，大多数的开发者并不直接使用这些类，而是更喜欢使用XML配置来进行bean定义， 或者基于注解的组件（例如使用 @Component,@Controller等），或者在配置了@Configuration的类上面使用@Bean的方法。 然后，这些源在内部转换为 BeanDefinition的实例，并用于加载整个Spring IoC容器实例。

如何选择基于构造器和基于setter方法?

因为开发者可以混用两种依赖注入方式，两种方式用于处理不同的情况：必要的依赖通常通过构造函数注入，而可选的依赖则通过setter方法注入。其中，在setter方法上添加@Required 注解可用于构造必要的依赖。

Spring团队推荐使用基于构造函数的注入，因为这种方式会促使开发者将组件开发成不可变对象并且确保注入的依赖不为null。另外，基于构造函数的注入的组件被客户端调用的时候也已经是完全构造好的 。当然，从另一方面来说，过多的构造函数参数也是非常糟糕的代码方式，这种方式说明类附带了太多的功能，最好重构将不同职能分离。

基于setter的注入只用于可选的依赖，但是也最好配置一些合理的默认值。否则，只能对代码的依赖进行非null值检查了。基于setter方法的注入有一个便利之处是：对象可以重新配置和重新注入。 因此，使用setter注入管理 JMX MBeans 是很方便的

依赖注入的两种风格适合大多数的情况，但是在使用第三方库的时候，开发者可能并没有源码，那么就只能使用基于构造函数的依赖注入了。

决定依赖的过程

容器解析Bean的过程如下:

• 创建并根据描述的元数据来实例化ApplicationContext，元数据配置可以是XML文件、Java代码或者注解。

• 每一个Bean的依赖都通过构造函数参数或属性，或者静态工厂方法的参数等等来表示。这些依赖会在Bean创建的时候装载和注入

• 每一个属性或者构造函数的参数都是真实定义的值或者引用容器其他的Bean.

• 每一个属性或者构造参数可以根据指定的类型转换为所需的类型。Spring也可以将String转成默认的Java内置类型。例如int, long, String, boolean等 。

Spring容器会在容器创建的时候针对每一个Bean进行校验。但是Bean的属性在Bean没有真正创建之前是不会进行配置的，单例类型的Bean是容器创建的时候配置成预实例状态的。 Bean的作用域后面再说，其他的Bean都只有在请求的时候，才会创建，显然创建Bean对象会有一个依赖顺序图，这个图表示Bean之间的依赖关系。 容器根据此来决定创建和配置Bean的顺序。

循环依赖

如果开发者主要使用基于构造函数的依赖注入，那么很有可能出现循环依赖的情况。

例如：类A在构造函数中依赖于类B的实例，而类B的构造函数又依赖类A的实例。如果这样配置类A和类B相互注入的话，Spring IoC容器会发现这个运行时的循环依赖， 并且抛出BeanCurrentlyInCreationException。

开发者可以选择setter方法来配置依赖注入，这样就不会出现循环依赖的情况。或者根本就不使用基于构造函数的依赖注入，而仅仅使用基于setter方法的依赖注入。 换言之，但是开发者可以将循环依赖配置为基于Setter方法的依赖注入（尽管不推荐这样做）

不像典型的例子（没有循环依赖的情况），bean A和bean B之间的循环依赖关系在完全初始化之前就已经将其中一个bean注入到另一个中了（典型的鸡和鸡蛋的故事）

你可以信任Spring做正确的事。它在容器加载时检测配置问题，例如对不存在的bean和循环依赖的引用。 当实际创建bean时，Spring会尽可能晚地设置属性并解析依赖项。这也意味着Spring容器加载正确后会在bean注入依赖出错的时候抛出异常。例如，bean抛出缺少属性或者属性不合法的异常 ，这种延迟的解析也是ApplicationContext 的实现会令单例Bean处于预实例化状态的原因。这样，通过ApplicationContext创建bean，可以在真正使用bean之前消耗一些内存代价而发现配置的问题 。开发者也可以覆盖默认的行为让单例bean延迟加载，而不总是处于预实例化状态。

如果不存在循环依赖的话，bean所引用的依赖会预先全部构造。举例来说，如果bean A依赖于bean B，那么Spring IoC容器会先配置bean B，然后调用bean A的setter方法来构造bean A。 换言之，bean先会实例化，然后再注入依赖，最后才是相关生命周期方法的调用（就像配置文件的初始化方法 或者InitializingBean的回调函数那样）。

依赖注入的例子

下面的例子使用基于XML的元数据配置，然后使用setter方式进行依赖注入。下面是Spring中使用XML文件声明bean定义的片段：

<bean id="exampleBean" class="examples.ExampleBean">
    <!-- setter injection using the nested ref element -->
    <property name="beanOne">
        <ref bean="anotherExampleBean"/>
    </property>

    <!-- setter injection using the neater ref attribute -->
    <property name="beanTwo" ref="yetAnotherBean"/>
    <property name="integerProperty" value="1"/>
</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

以下示例显示了相应的 ExampleBean类：

public class ExampleBean {

    private AnotherBean beanOne;

    private YetAnotherBean beanTwo;

    private int i;

    public void setBeanOne(AnotherBean beanOne) {
        this.beanOne = beanOne;
    }

    public void setBeanTwo(YetAnotherBean beanTwo) {
        this.beanTwo = beanTwo;
    }

    public void setIntegerProperty(int i) {
        this.i = i;
    }
}

在前面的示例中，setter被声明为与XML文件中指定的属性匹配。以下示例使用基于构造函数的DI：

<bean id="exampleBean" class="examples.ExampleBean">
    <!-- constructor injection using the nested ref element -->
    <constructor-arg>
        <ref bean="anotherExampleBean"/>
    </constructor-arg>

    <!-- constructor injection using the neater ref attribute -->
    <constructor-arg ref="yetAnotherBean"/>

    <constructor-arg type="int" value="1"/>
</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

以下示例显示了相应的ExampleBean类：

public class ExampleBean {

    private AnotherBean beanOne;

    private YetAnotherBean beanTwo;

    private int i;

    public ExampleBean(
        AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
        this.beanOne = anotherBean;
        this.beanTwo = yetAnotherBean;
        this.i = i;
    }
}

bean定义中指定的构造函数参数用作 ExampleBean的构造函数的参数。

现在考虑这个示例的变体，其中，不使用构造函数，而是告诉Spring调用静态工厂方法来返回对象的实例：

<bean id="exampleBean" class="examples.ExampleBean" factory-method="createInstance">
    <constructor-arg ref="anotherExampleBean"/>
    <constructor-arg ref="yetAnotherBean"/>
    <constructor-arg value="1"/>
</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean"/>
<bean id="yetAnotherBean" class="examples.YetAnotherBean"/>

以下示例显示了相应的ExampleBean类：

public class ExampleBean {

    // a private constructor
    private ExampleBean(...) {
        ...
    }

    // a static factory method; the arguments to this method can be
    // considered the dependencies of the bean that is returned,
    // regardless of how those arguments are actually used.
    public static ExampleBean createInstance (
        AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {

        ExampleBean eb = new ExampleBean (...);
        // some other operations...
        return eb;
    }
}

静态工厂方法的参数由<constructor-arg/>元素提供，与实际使用的构造函数完全相同。工厂方法返回类的类型不必与包含静态工厂方法 的类完全相同， 尽管在本例中是这样。实例（非静态）工厂方法的使用方式也是相似的（除了使用factory-bean属性而不是class属性。因此此处不在展开讨论。

1.4.2. 依赖和配置的细节

如上一节所述，您可以将bean的属性和构造函数参数定义为对其他bean的引用，或者作为其内联定义的值。Spring可以允许您在基于XML的配置元数据（定义Bean）中使用子元素<property/> and <constructor-arg/> 来达到这种目的。

直接值（基本类型，String等等）

<property/> 元素的value 属性将属性或构造函数参数指定为人类可读的字符串表示形式， Spring的conversion service用于将这些值从String 转换为属性或参数的实际类型。 以下示例显示了要设置的各种值：

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <!-- results in a setDriverClassName(String) call -->
    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
    <property name="url" value="jdbc:mysql://localhost:3306/mydb"/>
    <property name="username" value="root"/>
    <property name="password" value="masterkaoli"/>
</bean>

以下示例使用p命名空间进行更简洁的XML配置：

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close"
        p:driverClassName="com.mysql.jdbc.Driver"
        p:url="jdbc:mysql://localhost:3306/mydb"
        p:username="root"
        p:password="masterkaoli"/>

</beans>

前面的XML更简洁。 但是因为属性的类型是在运行时确定的，而非设计时确定的。所有有可能在运行时发现拼写错误。，除非您在创建bean定义时使用支持自动属性完成的IDE（例如IntelliJ IDEA or the Spring Tool Suite）。 所以，强烈建议使用此类IDE帮助。

你也可以配置一个java.util.Properties 的实例，如下：

<bean id="mappings"
    class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

    <!-- typed as a java.util.Properties -->
    <property name="properties">
        <value>
            jdbc.driver.className=com.mysql.jdbc.Driver
            jdbc.url=jdbc:mysql://localhost:3306/mydb
        </value>
    </property>
</bean>

Spring的容器会将<value/>里面的文本通过JavaBean的PropertyEditor 机制转换成java.util.Properties 实例， 这种嵌套<value/>元素的快捷方式也是Spring团队推荐使用的。

idref 元素

idref 元素只是一种防错方法，可以将容器中另一个bean的id（字符串值 - 而不是引用）传递给<constructor-arg/>或<property/>元素：

<bean id="theTargetBean" class="..."/>

<bean id="theClientBean" class="...">
    <property name="targetName">
        <idref bean="theTargetBean"/>
    </property>
</bean>

前面的bean定义代码段运行时与以下代码段完全等效：

<bean id="theTargetBean" class="..." />

<bean id="client" class="...">
    <property name="targetName" value="theTargetBean"/>
</bean>

Spring团队更推荐第一种方式，因为使用了idref 标签，它会让容器在部署阶段就对bean进行校验，以确保bean一定存在。而使用第二种方式的话，是没有任何校验的。 只有实际上引用了client bean的targetName属性，不对其值进行校验。在实例化client的时候才会被发现。如果client是prototype类型的Bean的话，那么类似拼写之类的错误会在容器部署以后很久才能发现。

idref元素的local属性在Spring 4.0以后的xsd中已经不再支持了，而是使用了bean引用。如果更新了版本的话，只要将idref local引用都转换成idref bean 即可。

在ProxyFactoryBean定义中，元素所携带的值在AOP拦截器a>的配置中很常见（至少在Spring 2.0之前的版本是这样）。在指定拦截器名称时使用<idref/> 元素可防止拦截器漏掉id或拼写错误。

引用其他的Bean（装配）

ref 元素是<constructor-arg/> 或 or <property/>定义元素中的最后一个元素。 你可以通过这个标签配置一个bean来引用另一个bean。当需要引用一个bean的时候，被引用的bean会先实例化，然后配置属性，也就是引用的依赖。如果该bean是单例bean的话 ，那么该bean会早由容器初始化。最终会引用另一个对象的所有引用，bean的范围以及校验取决于你是否有通过bean, local, or parent 这些属性来指定对象的id或者name属性。

通过指定 bean属性中的<ref/>元素来指定依赖是最常见的一种方式，可以引用容器或者父容器中的bean，不在同一个XML文件定义也可以引用。 其中bean 属性中的值可以和其他引用bean 中的id属性一致，或者和其中的某个name 属性一致，以下示例显示如何使用ref元素：：

<ref bean="someBean"/>

通过指定bean的parent属性可以创建一个引用到当前容器的父容器之中。parent属性的值可以与目标bean的id属性一致，或者和目标bean的name属性中的某个一致，目标bean必须是当前引用目标bean容器的父容器 。开发者一般只有在存在层次化容器，并且希望通过代理来包裹父容器中一个存在的bean的时候才会用到这个属性。 以下一对列表显示了如何使用父属性:

<!-- in the parent context -->
<bean id="accountService" class="com.something.SimpleAccountService">
    <!-- insert dependencies as required as here -->
</bean>

<!-- in the child (descendant) context -->
<bean id="accountService" <!-- bean name is the same as the parent bean -->
    class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="target">
        <ref parent="accountService"/> <!-- notice how we refer to the parent bean -->
    </property>
    <!-- insert other configuration and dependencies as required here -->
</bean>

与idref标签一样，ref元素中的local 标签在xsd 4.0，以后已经不再支持了，开发者可以通过将已存在的ref local改为ref bean 来完成Spring版本升级。

内部bean

定义在<bean/>元素的<property/>或者<constructor-arg/> 元素之内的bean叫做内部bean，如下例所示：:

<bean id="outer" class="...">
    <!-- instead of using a reference to a target bean, simply define the target bean inline -->
    <property name="target">
        <bean class="com.example.Person"> <!-- this is the inner bean -->
            <property name="name" value="Fiona Apple"/>
            <property name="age" value="25"/>
        </bean>
    </property>
</bean>

内部bean定义不需要定义的ID或名称。如果指定，则容器不使用此类值作为标识符。容器还会在创建时忽略scope 标签，因为内部bean始终是匿名的，并且始终使用外部bean创建。 开发者是无法将内部bean注入到外部bean以外的其他bean中的。

作为一个极端情况，可以从自定义范围接收销毁回调 ， 例如：请求范围的内部bean包含了单例bean，那么内部bean实例会绑定到包含的bean，而包含的bean允许访问request的scope生命周期。 这种场景并不常见，内部bean通常只是供给它的外部bean使用。

集合

在<list/>, <set/>, <map/>, 和 <props/>元素中，您可以分别配置Java集合类型 List, Set, Map, and Properties的属性和参数。 以下示例显示了如何使用它们:

<bean id="moreComplexObject" class="example.ComplexObject">
    <!-- results in a setAdminEmails(java.util.Properties) call -->
    <property name="adminEmails">
        <props>
            <prop key="administrator">administrator@example.org</prop>
            <prop key="support">support@example.org</prop>
            <prop key="development">development@example.org</prop>
        </props>
    </property>
    <!-- results in a setSomeList(java.util.List) call -->
    <property name="someList">
        <list>
            <value>a list element followed by a reference</value>
            <ref bean="myDataSource" />
        </list>
    </property>
    <!-- results in a setSomeMap(java.util.Map) call -->
    <property name="someMap">
        <map>
            <entry key="an entry" value="just some string"/>
            <entry key ="a ref" value-ref="myDataSource"/>
        </map>
    </property>
    <!-- results in a setSomeSet(java.util.Set) call -->
    <property name="someSet">
        <set>
            <value>just some string</value>
            <ref bean="myDataSource" />
        </set>
    </property>
</bean>

当然，map的key或者value，或者集合的value都可以配置为下列元素之一:

bean | ref | idref | list | set | map | props | value | null

集合的合并

Spring的容器也支持集合合并，开发者可以定义父样式的<list/>, <map/>, <set/> 或 <props/>元素， 同时有子样式的<list/>, <map/>, <set/> 或 <props/>元素。也就是说，子集合的值是父元素和子元素集合的合并值。

有关合并的这一节讨论父子bean机制，不熟悉父和子bean定义的读者可能希望在继续之前阅读相关部分。

以下示例演示了集合合并：:

<beans>
    <bean id="parent" abstract="true" class="example.ComplexObject">
        <property name="adminEmails">
            <props>
                <prop key="administrator">administrator@example.com</prop>
                <prop key="support">support@example.com</prop>
            </props>
        </property>
    </bean>
    <bean id="child" parent="parent">
        <property name="adminEmails">
            <!-- the merge is specified on the child collection definition -->
            <props merge="true">
                <prop key="sales">sales@example.com</prop>
                <prop key="support">support@example.co.uk</prop>
            </props>
        </property>
    </bean>
<beans>

请注意，在child bean 定义的adminEmails中的<props/>使用merge=true 属性。 当容器解析并实例化child bean时，生成的实例有一个adminEmails属性集合， 其实例中包含的adminEmails集合就是child的adminEmails以及parent的adminEmails集合。以下清单显示了结果： :

administrator=administrator@example.com
sales=sales@example.com
support=support@example.co.uk

子属性集合的值集继承父<props/>的所有属性元素，子值的支持值覆盖父集合中的值。

这个合并的行为和<list/>, <map/>, 和 <set/>之类的集合类型的行为是类似的。List 在特定例子中，与List集合类型类似， 有着隐含的 ordered概念。所有的父元素里面的值，是在所有子元素的值之前配置的。但是像Map, Set, 和 Properties的集合类型，是不存在顺序的。

集合合并的限制

您不能合并不同类型的集合（例如要将Map 和List合并是不可能的）。如果开发者硬要这样做就会抛出异常， merge的属性是必须特指到更低级或者继承的子节点定义上， 特指merge属性到父集合的定义上是冗余的，而且在合并上也没有任何效果。

强类型的集合

在Java 5以后，开发者可以使用强类型的集合了。也就是，开发者可以声明Collection类型，然后这个集合只包含String元素（举例来说）。 如果开发者通过Spring来注入强类型的Collection到bean中，开发者就可以利用Spring的类型转换支持来做到 以下Java类和bean定义显示了如何执行此操作:

public class SomeClass {

    private Map<String, Float> accounts;

    public void setAccounts(Map<String, Float> accounts) {
        this.accounts = accounts;
    }
}

<beans>
    <bean id="something" class="x.y.SomeClass">
        <property name="accounts">
            <map>
                <entry key="one" value="9.99"/>
                <entry key="two" value="2.75"/>
                <entry key="six" value="3.99"/>
            </map>
        </property>
    </bean>
</beans>

当something的属性accounts准备注入的时候，accounts的泛型信息MapMap<String, Float> 就会通过反射拿到。 这样，Spring的类型转换系统能够识别不同的类型，如上面的例子Float然后会将字符串的值9.99, 2.75, 和3.99转换成对应的Float类型。

Null and 空字符串

Strings将属性的空参数视为空字符串。下面基于XML的元数据配置就会将email 属性配置为String的值。

<bean class="ExampleBean">
    <property name="email" value=""/>
</bean>

上面的示例等效于以下Java代码:

exampleBean.setEmail("");

<null/>将被处理为null值。以下清单显示了一个示例:

<bean class="ExampleBean">
    <property name="email">
        <null/>
    </property>
</bean>

上述配置等同于以下Java代码：

exampleBean.setEmail(null);

使用p命名空间简化XML配置

p命名空间让开发者可以使用bean的属性，而不必使用嵌套的<property/>元素。

Spring是支持基于XML的格式化命名空间扩展的。本节讨论的beans 配置都是基于XML的，p命名空间是定义在Spring Core中的（不是在XSD文件）。

以下示例显示了两个XML片段（第一个使用标准XML格式，第二个使用p命名空间），它们解析为相同的结果：

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean name="classic" class="com.example.ExampleBean">
        <property name="email" value="someone@somewhere.com"/>
    </bean>

    <bean name="p-namespace" class="com.example.ExampleBean"
        p:email="someone@somewhere.com"/>
</beans>

上面的例子在bean中定义了email的属性。这种定义告知Spring这是一个属性声明。如前面所描述的，p命名空间并没有标准的定义模式，所以开发者可以将属性的名称配置为依赖名称。

下一个示例包括另外两个bean定义，它们都引用了另一个bean:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean name="john-classic" class="com.example.Person">
        <property name="name" value="John Doe"/>
        <property name="spouse" ref="jane"/>
    </bean>

    <bean name="john-modern"
        class="com.example.Person"
        p:name="John Doe"
        p:spouse-ref="jane"/>

    <bean name="jane" class="com.example.Person">
        <property name="name" value="Jane Doe"/>
    </bean>
</beans>

此示例不仅包含使用p命名空间的属性值，还使用特殊格式来声明属性引用。第一个bean定义使用<property name="spouse" ref="jane"/>来创建从bean john到bean jane的引用， 而第二个bean定义使用p:spouse-ref="jane"来作为指向bean的引用。在这个例子中 spouse是属性的名字，而-ref部分表名这个依赖不是直接的类型，而是引用另一个bean。

p命名空间并不如标准XML格式灵活。例如，声明属性的引用可能和一些以Ref结尾的属性相冲突，而标准的XML格式就不会。Spring团队推荐开发者能够和团队商量一下，协商使用哪一种方式，而不要同时使用三种方法。

使用c命名空间简化XML

与 p命名空间类似，c命名空间是在Spring 3.1首次引入的，c命名空间允许使用内联的属性来配置构造参数而不必使用constructor-arg 。

以下示例使用c:命名空间的例子来执行与基于Constructor的依赖注入相同的操作：

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:c="http://www.springframework.org/schema/c"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="thingOne" class="x.y.ThingTwo"/>
    <bean id="thingTwo" class="x.y.ThingThree"/>

    <!-- traditional declaration -->
    <bean id="thingOne" class="x.y.ThingOne">
        <constructor-arg ref="thingTwo"/>
        <constructor-arg ref="thingThree"/>
        <constructor-arg value="something@somewhere.com"/>
    </bean>

    <!-- c-namespace declaration -->
    <bean id="thingOne" class="x.y.ThingOne" c:thingTwo-ref="thingTwo" c:thingThree-ref="thingThree" c:email="something@somewhere.com"/>

</beans>

c::命名空间使用了和p: :命名空间相类似的方式（使用了-ref 来配置引用).而且,同样的,c命名空间也是定义在Spring Core中的（不是XSD模式).

在少数的例子之中,构造函数的参数名字并不可用（通常,如果字节码没有debug信息的编译),你可以使用回调参数的索引，如下面的例子:

<!-- c-namespace index declaration -->
<bean id="thingOne" class="x.y.ThingOne" c:_0-ref="thingTwo" c:_1-ref="thingThree"/>

由于XML语法，索引表示法需要使用_作为属性名字的前缀，因为XML属性名称不能以数字开头（即使某些IDE允许它）。

实际上，构造函数解析机制在匹配参数方面非常有效，因此除非您确实需要，否则我们建议在整个配置中使用名称表示法。

组合属性名

开发者可以配置混合的属性，只需所有的组件路径（除了最后一个属性名字）不能为null即可。参考如下定义：

<bean id="something" class="things.ThingOne">
    <property name="fred.bob.sammy" value="123" />
</bean>

something有 fred的属性，而其中fred属性有bob属性，而bob属性之中有sammy属性，那么最后这个sammy属性会配置为123。 想要上述的配置能够生效，fred属性需要有bob属性而且在fred构造之后不为null即可。

1.4.3. 使用 depends-on属性

如果一个bean是另一个bean的依赖，通常这个bean也就是另一个bean的属性之一。多数情况下，开发者可以在配置XML元数据的时候使用<ref/>标签。 然而，有时bean之间的依赖不是直接关联的。例如：需要调用类的静态实例化器来触发依赖，类似数据库驱动注册。depends-on属性可以显式强制初始化一个或多个bean。 以下示例使用depends-on属性表示对单个bean的依赖关系:

<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
<bean id="manager" class="ManagerBean" />

如果想要依赖多个bean，可以提供多个名字作为depends-on的值。以逗号、空格或者分号分割:

<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
    <property name="manager" ref="manager" />
</bean>

<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />

depends-on属性既可以指定初始化时间依赖性，也可以指定单独的bean，相应的销毁时间的依赖。独立定义了depends-on属性的bean会优先销毁 （相对于depends-on的bean销毁，这样depends-on可以控制销毁的顺序。

1.4.4. 懒加载Bean

默认情况下， ApplicationContext 会在实例化的过程中创建和配置所有的单例singleton bean。总的来说， 这个预初始化是很不错的。因为这样能及时发现环境上的一些配置错误，而不是系统运行了很久之后才发现。如果这个行为不是迫切需要的，开发者可以通过将Bean标记为延迟加载就能阻止这个预初始化 懒加载bean会通知IoC不要让bean预初始化而是在被引用的时候才会实例化。

在XML中，此行为由<bean/>元素上的lazy-init 属性控制，如以下示例所示：

<bean id="lazy" class="com.something.ExpensiveToCreateBean" lazy-init="true"/>
<bean name="not.lazy" class="com.something.AnotherBean"/>

当将bean配置为上述XML的时候， ApplicationContext之中的lazy bean是不会随着 ApplicationContext的启动而进入到预初始化状态的。 只有那些非延迟加载的bean是处于预初始化的状态的。

然而，如果延迟加载的类是作为单例非延迟加载的bean的依赖而存在的话，ApplicationContext仍然会在ApplicationContext启动的时候加载。 因为作为单例bean的依赖，会随着单例bean的实例化而实例化。

您还可以使用<beans/>元素上的default-lazy-init属性在容器级别控制延迟初始化，以下示例显示：

<beans default-lazy-init="true">
    <!-- no beans will be pre-instantiated... -->
</beans>

1.4.5. 自动装配

Spring容器可以根据bean之间的依赖关系自动装配，开发者可以让Spring通过ApplicationContext来自动解析这些关联，自动装载有很多优点:

• 自动装载能够明显的减少指定的属性或者是构造参数。（在本章其他地方讨论的其他机制，如bean模板，在这方面也很有价值。）

• 自动装载可以扩展开发者的对象，比如说，如果开发者需要加一个依赖，只需关心如何更改配置即可自动满足依赖关联。这样，自动装载在开发过程中是极其高效的，无需明确选择装载的依赖会使系统更加稳定

使用基于XML的配置元数据（请参阅依赖注入）时，可以使用<bean/> 元素的autowire属性为bean定义指定autowire模式。 自动装配功能有四种方式。开发者可以指定每个bean的装配方式，这样bean就知道如何加载自己的依赖。下表描述了四种自动装配模式：

Table 2. 装配模式

通过byType或者constructor的自动装配方式，开发者可以装载数组和强类型集合。在这样的例子中，所有容器中的匹配了指定类型的bean都会自动装配到bean上来完成依赖注入。 开发者可以自动装配key为String.的强类型的 Map 。自动装配的Map值会包含所有的bean实例值来匹配指定的类型，Map的key会包含关联的bean的名字。

自动装配的局限和缺点

自动装配在项目中一致使用时效果最佳。如果一般不使用自动装配，那么开发人员使用它来装配一个或两个bean定义可能会让人感到困惑。

考虑自动装配的局限和缺点:

• property和constructor-arg设置中的显式依赖项始终覆盖自动装配。开发者不能自动装配一些简单属性，您不能自动装配简单属性，例如基本类型 ，字符串和类（以及此类简单属性的数组）。这种限制是按设计的。

• 自动装配比显式的配置更容易歧义，尽管上表表明了不同自动配置的特点，Spring也会尽可能避免不必要的装配错误。但是Spring管理的对象关系仍然不如显式配置那样明确。

• 从Spring容器生成文档的工具可能无法有效的提供装配信息。

• 容器中的多个bean定义可能与setter方法或构造函数参数所指定的类型相匹配， 这有利于自动装配。对于arrays, collections, or Map实例来说这不是问题。但是如果是对只有一个依赖项的值是有歧义的话，那么这个项是无法解析的。如果没有唯一的bean，则会抛出异常。

在后面的场景，你可有如下的选择：

• 放弃自动装配，改用显式的配置。
• 通过将autowire-candidate 属性设置为false，避免对bean定义进行自动装配，如下一节所述。
• 通过将其<bean/> 元素的primary属性设置为 true，将单个bean定义指定为主要候选项。
• 使用基于注解的配置实现更细粒度的控制，如基于注解的容器配置中所述。

将bean从自动装配中排除

在每个bean的基础上，您可以从自动装配中排除bean。 在Spring的XML格式中，将<bean/> 元素的autowire-candidate 属性设置为false。 容器使特定的bean定义对自动装配基础结构不可用（包括注解样式配置，如@Autowired）。

autowire-candidate 属性旨在仅影响基于类型的自动装配。 它不会影响名称的显式引用，即使指定的bean未标记为autowire候选，也会解析它。 因此，如果名称匹配，则按名称自动装配会注入bean。

开发者可以通过模式匹配而不是Bean的名字来限制自动装配的候选者。最上层的<beans/> 元素会在default-autowire-candidates 属性中来配置多种模式。 例如，限制自动装配候选者的名字以Repository结尾，可以配置成*Repository。如果需要配置多种模式，只需要用逗号分隔开即可。 bean定义的autowire-candidate属性的显式值true 或false始终优先。 对于此类bean，模式匹配规则不适用。

上面的这些技术在配置那些无需自动装配的bean是相当有效的，当然这并不是说这类bean本身无法自动装配其他的bean。而是说这些bean不再作为自动装配的依赖候选者。

1.4.6.方法注入

在大多数的应用场景下，多数的bean都是单例的。当这个单例的bean需要和另一个单例的或者非单例的bean协作使用的时候，开发者只需要配置依赖bean为这个bean的属性即可。 但是有时会因为bean具有不同的生命周期而产生问题。假设单例的bean A在每个方法调用中使用了非单例的bean B。容器只会创建bean A一次，而只有一个机会来配置属性。 那么容器就无法为每一次创建bean A时都提供新的bean B实例。

一种解决方案就是放弃IoC，开发者可以通过实现ApplicationContextAware接口让bean A对ApplicationContext可见。 从而通过调用getBean("B")来在bean A 需要新的实例的时候来获取到新的B实例。参考下面例子。

// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;

// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class CommandManager implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public Object process(Map commandState) {
        // grab a new instance of the appropriate Command
        Command command = createCommand();
        // set the state on the (hopefully brand new) Command instance
        command.setState(commandState);
        return command.execute();
    }

    protected Command createCommand() {
        // notice the Spring API dependency!
        return this.applicationContext.getBean("command", Command.class);
    }

    public void setApplicationContext(
            ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

上面的代码并不让人十分满意，因为业务的代码已经与Spring框架耦合在一起。方法注入是Spring IoC容器的一个高级功能，可以让您处理这种问题。 Spring提供了一个稍微高级的注入方式来处理这种问题

您可以在此博客条目中阅读有关方法注入的更多信息。

查找方法注入

查找方法注入是容器覆盖管理bean上的方法的能力，以便返回容器中另一个命名bean的查找结果。查找方法通常涉及原型bean，如前面描述的场景。 Spring框架通过使用CGLIB库生成的字节码来生成动态子类重写的方法实现此注入。

• 如果想让这个动态子类正常工作，那么Spring容器所继承的Bean不能是final的，而覆盖的方法也不能是final的。

• 对具有抽象方法的类进行单元测试时，需要开发者对类进行子类化，并提供抽象方法的具体实现。

• 组件扫描也需要具体的方法，因为它需要获取具体的类。

• 另一个关键限制是查找方法不适用于工厂方法，特别是在配置类中不使用@Bean的方法。因为在这种情况下，容器不负责创建实例，因此不能在运行时创建运行时生成的子类。

对于前面代码片段中的CommandManager类，Spring容器动态地覆盖createCommand()方法的实现。 CommandManager类不再拥有任何的Spring依赖，如下：

package fiona.apple;

// no more Spring imports!

public abstract class CommandManager {

    public Object process(Object commandState) {
        // grab a new instance of the appropriate Command interface
        Command command = createCommand();
        // set the state on the (hopefully brand new) Command instance
        command.setState(commandState);
        return command.execute();
    }

    // okay... but where is the implementation of this method?
    protected abstract Command createCommand();
}

在包含需要注入方法的客户端类中 (在本例中为CommandManager）注入方法的签名需要如下形式：

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

如果方法是abstract的， 那么动态生成的子类会实现该方法。否则，动态生成的子类将覆盖原始类定义的具体方法。例如：

<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
    <!-- inject dependencies here as required -->
</bean>

<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
    <lookup-method name="createCommand" bean="myCommand"/>
</bean>

当需要新的myCommand bean实例时，标识为commandManager的bean会调用自身的createCommand()方法.开发者必须小心部署myCommand bean为原型bean. 如果所需的bean是单例的,那么每次都会返回相同的myCommand bean实例.

另外,如果是基于注解的配置模式,你可以在查找方法上定义@Lookup注解,如下:

public abstract class CommandManager {

    public Object process(Object commandState) {
        Command command = createCommand();
        command.setState(commandState);
        return command.execute();
    }

    @Lookup("myCommand")
    protected abstract Command createCommand();
}

或者，更常见的是，开发者也可以根据查找方法的返回类型来查找匹配的bean，如下

public abstract class CommandManager {

    public Object process(Object commandState) {
        MyCommand command = createCommand();
        command.setState(commandState);
        return command.execute();
    }

    @Lookup
    protected abstract MyCommand createCommand();
}

注意开发者可以通过创建子类实现lookup方法，以便使它们与Spring的组件扫描规则兼容，同时抽象类会在默认情况下被忽略。这种限制不适用于显式注册bean或明确导入bean的情况。

另一种可以访问不同生命周期的方法是ObjectFactory/Provider注入，具体参看 作用域的bean依赖

您可能还会发现ServiceLocatorFactoryBean（在org.springframework.beans.factory.config包中）很有用。

替换任意方法

从前面的描述中，我们知道查找方法是有能力来覆盖任何由容器管理的bean方法的。开发者最好跳过这一部分，除非一定需要用到这个功能。

通过基于XML的元数据配置，开发者可以使用replaced-method元素来替换已存在方法的实现。考虑以下类，它有一个我们想要覆盖的名为computeValue 的方法：

public class MyValueCalculator {

    public String computeValue(String input) {
        // some real code...
    }

    // some other methods...
}

实现org.springframework.beans.factory.support.MethodReplacer接口的类提供了新的方法定义，如以下示例所示：

/**
 * meant to be used to override the existing computeValue(String)
 * implementation in MyValueCalculator
 */
public class ReplacementComputeValue implements MethodReplacer {

    public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
        // get the input value, work with it, and return a computed result
        String input = (String) args[0];
        ...
        return ...;
    }
}

如果需要覆盖bean方法的XML配置如下类似于以下示例：

<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
    <!-- arbitrary method replacement -->
    <replaced-method name="computeValue" replacer="replacementComputeValue">
        <arg-type>String</arg-type>
    </replaced-method>
</bean>

<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>

您可以在<replaced-method/>元素中使用一个或多个 <arg-type/>元素来指示被覆盖的方法的方法。当需要覆盖的方法存在重载方法时，必须指定所需参数。 为了方便起见，字符串的类型会匹配以下类型，它完全等同于java.lang.String

java.lang.String
String
Str

因为，通常来说参数的个数已经足够区别不同的方法，这种快捷的写法可以省去很多的代码。

1.5. bean的作用域

创建bean定义时，同时也会定义该如何创建Bean实例。 这些具体创建的过程是很重要的，因为只有通过对这些配置过程，您才能创建实例对象。

您不仅可以将不同的依赖注入到bean中，还可以配置bean的作用域。这种方法是非常强大而且也非常灵活，开发者可以通过配置来指定对象的作用域，无需在Java类的层次上配置。 bean可以配置多种作用域，Spring框架支持五种作用域，有三种作用域是当开发者使用基于Web的ApplicationContext的时候才有效的。您还可以创建自定义范围.。

下表描述了支持的范围:

Table 3. Bean 的作用域

从Spring 3.0开始，线程作用域默认是可用的，但默认情况下未注册。 有关更多信息，请参阅SimpleThreadScope的文档。 有关如何注册此范围或任何其他自定义范围的说明，请参阅使用自定义范围。

1.5.1. 单例作用域

单例bean在全局只有一个共享的实例，所有依赖单例bean的场景中，容器返回的都是同一个实例。

换句话说，当您定义一个bean并且它的范围是一个单例时，Spring IoC容器只会根据bean的定义来创建该bean的唯一实例。 这些唯一的实例会缓存到容器中，后续针对单例bean的请求和引用，都会从这个缓存中拿到这个唯一实例。 下图显示了单例范围的工作原理：

Spring的单例bean概念不同于设计模式（GoF）之中所定义的单例模式。设计模式中的单例模式是将一个对象的作用域硬编码的，一个ClassLoader只能有唯一的一个实例。 而Spring的单例作用域是以容器为前提的，每个容器每个bean只能有一个实例。 这意味着，如果在单个Spring容器中为特定类定义一个bean，则Spring容器会根据bean定义创建唯一的bean实例。 单例作用域是Spring的默认作用域。 下面的例子是在XML中配置单例模式Bean的例子：

<bean id="accountService" class="com.something.DefaultAccountService"/>

<!-- the following is equivalent, though redundant (singleton scope is the default) -->
<bean id="accountService" class="com.something.DefaultAccountService" scope="singleton"/>

1.5.2. 原型作用域

非单例的、原型bean指的是每次请求bean实例时,返回的都是新的对象实例。也就是说，每次注入到另外的bean或者通过调用 getBean()方法来获得的bean都是全新的实例。 基于线程安全性的考虑，当bean对象有状态时使用原型作用域，而无状态时则使用单例作用域。

下图说明了Spring原型作用域：:

（数据访问对象（DAO）通常不配置为原型，因为典型的DAO不具有任何会话状态。我们可以更容易重用单例图的核心。）

用下面的例子来说明Spring的原型作用域:

<bean id="accountService" class="com.something.DefaultAccountService" scope="prototype"/>

与其他作用域相比，Spring不会完整地管理原型bean的生命周期。 Spring容器只会初始化、配置和装载这些bean，然后传递给Client。但是之后就不会再有该原型实例的进一步记录。 也就是说，初始化生命周期回调方法在所有作用域的bean是都会调用的，但是销毁生命周期回调方法在原型bean是不会调用的。所以，客户端代码必须注意清理原型bean以及释放原型bean所持有的资源。 可以通过使用自定义的bean post-processor（Bean的后置处理器）来让Spring释放掉原型bean所持有的资源。

在某些方面，Spring容器关于原型作用域的bean就是取代了Java的new 操作符。 所有的生命周期的控制都由客户端来处理（有关Spring容器中bean的生命周期的详细信息，请参阅Bean的生命周期）。

1.5.3. 依赖原型bean的单例bean

当您使用具有依赖于原型bean的单例作用域bean时，请注意在实例化时解析依赖项。 因此，如果将原型bean注入到单例的bean中，则会实例化一个新的原型bean，然后将依赖注入到单例bean中。 这个依赖的原型bean仍然是同一个实例。

但是，假设您希望单例作用域的bean在运行时重复获取原型作用域的bean的新实例。 您不能将原型作用域的bean依赖注入到您的单例bean中， 因为当Spring容器实例化单例bean并解析注入其依赖项时，该注入只发生一次。 如果您需要在运行时多次使用原型bean的新实例，请参阅方法注入。

1.5.4. 请求，会话，应用程序和WebSocket作用域

request, session, application, 和 websocket作用域只有在Web中使用Spring的ApplicationContext（例如ClassPathXmlApplicationContext）的情况下才用得上。 如果在普通的Spring IoC容器，例如ClassPathXmlApplicationContext中使用这些作用域，将会抛出IllegalStateException异常来说明使用了未知的作用域。

初始化Web的配置

为了能够使用请求 request, session, application, 和websocket（Web范围的bean），需要在配置bean之前作一些基础配置。 而对于标准的作用域，例如单例和原型作用域，这种基础配置是不需要的。

如何完成此初始设置取决于您的特定Servlet环境.

例如，如果开发者使用了Spring Web MVC框架，那么每一个请求都会通过Spring的DispatcherServlet来处理，那么也无需特殊的设置了。DispatcherServlet和DispatcherPortlet已经包含了相应状态。

如果您使用Servlet 2.5 Web容器，并且在Spring的DispatcherServlet之外处理请求（例如，使用JSF或Struts时），则需要注册org.springframework.web.context.request.RequestContextListener或者ServletRequestListener。 对于Servlet 3.0+，可以使用WebApplicationInitializer接口以编程方式完成此操作。 如果需要兼容旧版本容器的话，将以下声明添加到Web应用程序的web.xml 文件中:

<web-app>
    ...
    <listener>
        <listener-class>
            org.springframework.web.context.request.RequestContextListener
        </listener-class>
    </listener>
    ...
</web-app>

或者，如果对Listener不是很熟悉，请考虑使用Spring的RequestContextFilter。 Filter映射取决于Web应用的配置，因此您必须根据需要进行更改。 以下清单显示了Web应用程序的过滤器部分:

<web-app>
    ...
    <filter>
        <filter-name>requestContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>requestContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    ...
</web-app>

DispatcherServlet, RequestContextListener, and RequestContextFilter所做的工作实际上是一样的，都是将request对象请求绑定到服务的 Thread上。 这才使bean在之后的调用链上对请求和会话作用域可见。

Request作用域

参考下面这个XML配置的bean定义:

<bean id="loginAction" class="com.something.LoginAction" scope="request"/>

Spring容器会在每次使用LoginAction来处理每个HTTP请求时都会创建新的LoginAction实例。也就是说，LoginAction bean的作用域是HTTP Request级别的。 开发者可以随意改变实例的状态，因为其他通过loginAction请求来创建的实例根本看不到开发者改变的实例状态，所有创建的Bean实例都是根据独立的请求创建的。当请求处理完毕，这个bean也将会销毁。

当使用注解配置或Java配置时，使用@RequestScope注解修饰的bean会被设置成request作用域。 以下示例显示了如何执行此操作：

@RequestScope
@Component
public class LoginAction {
    // ...
}

Session作用域

参考下面XML配置的bean的定义:

<bean id="userPreferences" class="com.something.UserPreferences" scope="session"/>

Spring容器通过在单个HTTP会话的生命周期中使用UserPreferences bean定义来创建UserPreferences bean的新实例。换言之，UserPreferences Bean的作用域是HTTP SSession级别的，在request-scoped作用域的bean上， 开发者可以随意的更改实例的状态，同样，其他HTTP Session的基本实例在每个Session中都会请求userPreferences来创建新的实例，所以，开发者更改bean的状态， 对于其他的Bean仍然是不可见的。当HTTP Session被销毁时，根据这个Session来创建的bean也将会被销毁。

使用注解配置和Java配置时，使用@SessionScope 注解修饰的 bean 会被设置成session作用域。

@SessionScope
@Component
public class UserPreferences {
    // ...
}

Application作用域

参考下面用XML配置的bean的定义:

<bean id="appPreferences" class="com.something.AppPreferences" scope="application"/>

Spring容器会在整个Web应用内使用到appPreferences的时候创建一个新的AppPreferences的实例。也就是说，appPreferences bean是在ServletContext 级别的， 就像普通的ServletContext 属性一样。这种作用域在一些程度上来说和Spring的单例作用域是极为相似，但是也有如下不同之处，应用作用域是每个ServletContext 中包含一个 而不是每个Spring ApplicationContext中只有一个（某些应用可能包含多个ApplicationContext）。应用作用域仅仅对ServletContext 可见，单例bean是对ApplicationContext可见。

当使用注解配置或Java配置时，使用@ApplicationScope 注解修饰的bean会被设置成application作用域 。以下示例显示了如何执行此操作:

@ApplicationScope
@Component
public class AppPreferences {
    // ...
}

有作用域bean的依赖

Spring IoC容器不仅仅管理对象（bean）的实例化，同时也负责装配依赖。如果开发者要将一个bean装配到比它作用域更广的bean时（例如HTTP请求返回的bean），那么开发者应当选择注入AOP代理而不是使用带作用域的bean。 也就是说，开发者需要注入代理对象，而这个代理对象既可以找到实际的bean，还能够创建全新的bean。

您还可以在作为单例的作用域的bean之间使用<aop:scoped-proxy/>，然后引用通过可序列化的中间代理，从而能够在反序列化时重新获取目标单例bean。

当针对原型作用域的bean声明<aop:scoped-proxy/>时，每个通过代理的调用都会产生新的目标实例。

此外，作用域代理并不是取得作用域bean的唯一安全方式。 开发者也可以通过简单的声明注入（即构造函数或setter参数或自动装配字段）ObjectFactory<MyTargetBean>， 然后允许通过类似getObject()的方法调用来获取一些指定的依赖，而不是直接储存依赖的实例。

作为扩展变体，您可以声明ObjectProvider<MyTargetBean>，它提供了几个额外的访问变体，包括getIfAvailable 和 getIfUnique。

JSR-330将这样的变种称为Provider，它使用Provider<MyTargetBean> 声明以及相关的 get() 方法来尝试获取每一个配置。 有关JSR-330整体的更多详细信息，请参看此处。

以下示例中的配置只有一行，但了解“为什么”以及它背后的“如何”非常重要：:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop.xsd">

    <!-- an HTTP Session-scoped bean exposed as a proxy -->
    <bean id="userPreferences" class="com.something.UserPreferences" scope="session">
        <!-- instructs the container to proxy the surrounding bean -->
        <aop:scoped-proxy/> (1)
    </bean>

    <!-- a singleton-scoped bean injected with a proxy to the above bean -->
    <bean id="userService" class="com.something.SimpleUserService">
        <!-- a reference to the proxied userPreferences bean -->
        <property name="userPreferences" ref="userPreferences"/>
    </bean>
</beans>

1、定义代理的行。

要创建这样的一个代理，只需要在带作用域的bean定义中添加子节点<aop:scoped-proxy/>即可（具体查看选择创建代理的类型和 基于XML Schema的配置）。为什么在request, session和自定义作用域级别范围内的bean定义需要<aop:scoped-proxy/>， 考虑以下单例bean定义，并将其与您需要为上述范围定义的内容进行对比（请注意，以下userPreferencesbean定义不完整）:

<bean id="userPreferences" class="com.something.UserPreferences" scope="session"/>

<bean id="userManager" class="com.something.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

在上面的例子中，单例bean（userManager）注入了注入了HTTP Session级别的userPreferences依赖。 显然， 问题就是userPreferences在Spring容器中只会实例化一次。它的依赖项（在这种情况下只有一个，userPreferences）也只注入一次。 这意味着userManager 每次使用的是完全相同的userPreferences对象（即最初注入它的对象）进行操作。

这不是将短周期作用域bean注入到长周期作用域bean时所需的行为，例如将HTTP Session级别的作用域bean作为依赖注入到单例bean中。相反，开发者需要一个 userManager对象， 而在HTTP Session的生命周期中，开发者需要一个特定于HTTP Session的 userPreferences 对象。因此，容器创建一个对象，该对象公开与UserPreferences类（理想情况下为UserPreferences实例的对象） 完全相同的公共接口，该对象可以从作用域机制（HTTP Request、Session等）中获取真实的UserPreferences对象。容器将这个代理对象注入到userManager中， 而不知道这个UserPreferences引用是一个代理。在这个例子中，当一个UserManager实例在依赖注入的UserPreferences对象上调用一个方法时， 它实际上是在调用代理的方法，再由代理从HTTP Session（本例）获取真实的UserPreferences对象，并将方法调用委托给检索到的实际UserPreferences对象。

因此，在将request- and session-scoped的bean来作为依赖时，您需要以下（正确和完整）配置，如以下示例所示： 所以当开发者希望能够正确的使用配置请求、会话或者全局会话级别的bean来作为依赖时，需要进行如下类似的配置。

<bean id="userPreferences" class="com.something.UserPreferences" scope="session">
    <aop:scoped-proxy/>
</bean>

<bean id="userManager" class="com.something.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

选择要创建的代理类型

默认情况下，当Spring容器为使用<aop:scoped-proxy/> 元素标记的bean创建代理时，将创建基于CGLIB的类代理。

CGLIB代理只拦截公共方法调用！ 不要在这样的代理上调用非公共方法。 它们不会委托给实际的作用域目标对象。

或者，您可以通过为<aop:scoped-proxy/>元素的proxy-target-class 属性的值指定false来配置Spring容器， 以便为此类作用域bean创建基于JDK接口的标准代理。 使用基于接口的JDK代理意味着开发者无需引入第三方库即可完成代理。 但是，这也意味着带作用域的bean需要额外实现一个接口，而依赖是从这些接口来获取的。 以下示例显示基于接口的代理：

<!-- DefaultUserPreferences implements the UserPreferences interface -->
<bean id="userPreferences" class="com.stuff.DefaultUserPreferences" scope="session">
    <aop:scoped-proxy proxy-target-class="false"/>
</bean>

<bean id="userManager" class="com.stuff.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

有关选择基于类或基于接口的代理的更多详细信息，请参阅代理机制。

1.5.5. 自定义作用域

bean的作用域机制是可扩展的，开发者可以自定义作用域，甚至重新定义已经存在的作用域，但是Spring团队不推荐这样做，而且开发者也不能重写singleton 和 prototype作用域。

创建自定义作用域

为了能够使Spring可以管理开发者定义的作用域，开发者需要实现org.springframework.beans.factory.config.Scope。如何实现自定义的作用域， 可以参考Spring框架的一些实现或者有关Scope 的javadoc

Scope接口有四个方法用于操作对象,例如获取、移除或销毁等操作。

例如，传入Session作用域该方法将会返回一个 session-scoped的bean（如果它不存在，那么将会返回绑定session作用域的新实例）。下面的方法返回相应作用域的对象：

Object get(String name, ObjectFactory objectFactory)

下面的方法将从相应的作用域中移除对象。同样，以会话为例，该函数会删除会话作用域的Bean。删除的对象会作为返回值返回，当无法找到对象时将返回null。 以下方法从相应作用域中删除对象：:

Object remove(String name)

以下方法注册范围在销毁时或在Scope中的指定对象被销毁时应该执行的回调:

void registerDestructionCallback(String name, Runnable destructionCallback)

有关销毁回调的更多信息，请参看javadoc或Spring的Scope实现部分。

下面的方法获取相应作用域的区分标识符:

String getConversationId()

这个标识符在不同的作用域中是不同的。例如对于会话作用域，这个标识符就是会话的标识符。.

使用自定义作用域

在实现了自定义作用域后，开发者还需要让Spring容器能够识别发现所创建的新作用域。下面的方法就是在Spring容器中用来注册新Scope的:

void registerScope(String scopeName, Scope scope);

这个方法是在ConfigurableBeanFactory的接口中声明的，可以用在多数的ApplicationContext实现，也可以通过 BeanFactory属性来调用。

registerScope(..)方法的第一个参数是相关作用域的唯一名称。举例来说，Spring容器中的单例和原型就以它本身来命名。 第二个参数就是开发者希望注册和使用的自定义Scope实现的具有对象 T

假定开发者实现了自定义Scope，然后可以按如下步骤来注册。

下一个示例使用SimpleThreadScope，这个例子在Spring中是有实现的，但没有默认注册。 您自定义的作用域也可以通过如下的方式来注册。

Scope threadScope = new SimpleThreadScope();
beanFactory.registerScope("thread", threadScope);

然后，您可以创建符合自定义Scope的作用域规则的bean定义，如下所示：

<bean id="..." class="..." scope="thread">

在自定义作用域中，开发者也不限于仅仅通过编程的方式来注册作用域，还可以通过配置CustomScopeConfigurer 类来实现。如以下示例所示：:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop.xsd">

    <bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
        <property name="scopes">
            <map>
                <entry key="thread">
                    <bean class="org.springframework.context.support.SimpleThreadScope"/>
                </entry>
            </map>
        </property>
    </bean>

    <bean id="thing2" class="x.y.Thing2" scope="thread">
        <property name="name" value="Rick"/>
        <aop:scoped-proxy/>
    </bean>

    <bean id="thing1" class="x.y.Thing1">
        <property name="thing2" ref="thing2"/>
    </bean>

</beans>

在FactoryBean实现中添加了<aop:scoped-proxy/>元素时，它是工厂bean本身的作用域，而不是从getObject()方法返回的对象。

1.6. 自定义Bean的特性

Spring Framework提供了许多可用于自定义bean特性的接口。 本节将它们分组如下：

• Lifecycle Callbacks(生命周期回调)

• ApplicationContextAware and BeanNameAware

• 其他 Aware 接口

1.6.1. 生命周期回调

你可以实现InitializingBean 和 DisposableBean接口，让容器里管理Bean的生命周期。容器会在调用afterPropertiesSet() 之后和destroy()之前会允许bean在初始化和销毁bean时执行某些操作。

JSR-250 @PostConstruct 和 @PreDestroy注解通常被认为是在现代Spring应用程序中接收生命周期回调的最佳实践。 使用这些注解意味着您的bean不会耦合到特定于Spring的接口。 有关详细信息，请参阅使用 @PostConstruct 和 @PreDestroy.

如果您不想使用JSR-250注解但仍想删除耦合，请考虑使用init-method 和 destroy-method定义对象元数据。

在内部，Spring 框架使用BeanPostProcessor 实现来处理任何回调接口并调用适当的方法。 如果您需要Spring默认提供的自定义功能或其他生命周期行为，您可以自己实现BeanPostProcessor。 有关更多信息，请参阅容器扩展点。

除了初始化和销毁方法的回调，Spring管理的对象也实现了Lifecycle接口来让管理的对象在容器的生命周期内启动和关闭。

本节描述了生命周期回调接口。.

初始化方法回调

org.springframework.beans.factory.InitializingBean接口允许bean在所有的必要的依赖配置完成后执行bean的初始化， InitializingBean 接口中指定使用如下方法:

void afterPropertiesSet() throws Exception;

Spring团队是不建议开发者使用InitializingBean接口，因为这样会将代码耦合到Spring的特殊接口上。他们建议使用@PostConstruct 注解或者指定一个POJO的实现方法， 这会比实现接口更好。在基于XML的元数据配置上，开发者可以使用init-method 属性来指定一个没有参数的方法，使用Java配置的开发者可以在@Bean上添加 initMethod 属性。 请参阅 接收生命周期回调接收生命周期回调：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>

public class ExampleBean {

    public void init() {
        // do some initialization work
    }
}

前面的示例与以下示例（由两个列表组成）具有几乎完全相同的效果：

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements InitializingBean {

    public void afterPropertiesSet() {
        // do some initialization work
    }
}

但是，前面两个示例中的第一个没有将代码耦合到Spring。

销毁方法的回调

实现org.springframework.beans.factory.DisposableBean 接口的Bean就能让容器通过回调来销毁bean所引用的资源。 DisposableBean 接口指定一个方法：

void destroy() throws Exception;

我们建议您不要使用 DisposableBean 回调接口，因为它会不必要地将代码耦合到Spring。或者，我们建议使用@PreDestroy注解 或指定bean定义支持的泛型方法。 在基于XML的元数据配置中，您可以在<bean/>上使用destroy-method属性。 使用Java配置，您可以使用@Bean的 destroyMethod 属性。 请参阅接收生命周期回调。 考虑以下定义：

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/>

public class ExampleBean {

    public void cleanup() {
        // do some destruction work (like releasing pooled connections)
    }
}

前面的定义与以下定义几乎完全相同：:

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>

public class AnotherExampleBean implements DisposableBean {

    public void destroy() {
        // do some destruction work (like releasing pooled connections)
    }
}

但是，前面两个定义中的第一个没有将代码耦合到Spring。.

您可以为<bean> 元素的destroy-method属性分配一个特殊的（推断的）值，该值指示Spring自动检测特定bean类的close或者shutdown方法。 （因此，任何实现java.lang.AutoCloseable或java.io.Closeable的类都将匹配。） 您还可以在<bean> 元素的default-destroy-method属性上设置此特殊（推断）值，用于让所有的bean都实现这个行为（参见默认初始化和销毁方法）。 请注意，这是Java配置的默认行为。

默认初始化和销毁方法

当您不使用Spring特有的InitializingBean和 DisposableBean回调接口来实现初始化和销毁方法时，您定义方法的名称最好类似于init(), initialize(), dispose()。 这样可以在项目中标准化类方法，并让所有开发者都使用一样的名字来确保一致性。

您可以配置Spring容器来针对每一个Bean都查找这种名字的初始化和销毁回调方法。也就是说， 任意的开发者都会在应用的类中使用一个叫 init()的初始化回调。而不需要在每个bean中都定义init-method="init" 这种属性， Spring IoC容器会在bean创建的时候调用那个回调方法（如前面描述的标准生命周期一样）。这个特性也将强制开发者为其他的初始化以及销毁回调方法使用同样的名字。

假设您的初始化回调方法名为init()，而您的destroy回调方法名为destroy()。 然后，您的类类似于以下示例中的类：

public class DefaultBlogService implements BlogService {

    private BlogDao blogDao;

    public void setBlogDao(BlogDao blogDao) {
        this.blogDao = blogDao;
    }

    // this is (unsurprisingly) the initialization callback method
    public void init() {
        if (this.blogDao == null) {
            throw new IllegalStateException("The [blogDao] property must be set.");
        }
    }
}

然后，您可以在类似于以下内容的bean中使用该类:

<beans default-init-method="init">

    <bean id="blogService" class="com.something.DefaultBlogService">
        <property name="blogDao" ref="blogDao" />
    </bean>

</beans>

顶级<beans/>元素属性上存在default-init-method属性会导致Spring IoC容器将bean类上的init方法识别为初始化方法回调。 当bean被创建和组装时，如果bean拥有同名方法的话，则在适当的时候调用它。

您可以使用 <beans/>元素上的default-destroy-method属性，以类似方式（在XML中）配置destroy方法回调。

当某些bean已有的回调方法与配置的默认回调方法不相同时，开发者可以通过特指的方式来覆盖掉默认的回调方法。以XML为例，可以通过使用元素的init-method 和destroy-method属性来覆盖掉<bean/>中的配置。

Spring容器会做出如下保证，bean会在装载了所有的依赖以后，立刻就开始执行初始化回调。这样的话，初始化回调只会在直接的bean引用装载好后调用， 而此时AOP拦截器还没有应用到bean上。首先目标的bean会先完全初始化，然后AOP代理和拦截链才能应用。如果目标bean和代理是分开定义的，那么开发者的代码甚至可以跳过AOP而直接和引用的bean交互。 因此，在初始化方法中应用拦截器会前后矛盾，因为这样做耦合了目标bean的生命周期和代理/拦截器，还会因为与bean产生了直接交互进而引发不可思议的现象。

组合生命周期策略

从Spring 2.5开始，您有三种选择用于控制bean生命周期行为:

• InitializingBean 和 DisposableBean 回调接口

• 自定义 init() 和 destroy() 方法

• @PostConstruct 和 @PreDestroy 注解. 你也可以在bean上同时使用这些机制.

如果bean配置了多个生命周期机制，而且每个机制都配置了不同的方法名字时，每个配置的方法会按照以下描述的顺序来执行。但是，如果配置了相同的名字， 例如初始化回调为init()，在不止一个生命周期机制配置为这个方法的情况下，这个方法只会执行一次。如上一节中所述。

为同一个bean配置的多个生命周期机制具有不同的初始化方法，如下所示:

1. 包含@PostConstruct注解的方法

2. 在InitializingBean 接口中的afterPropertiesSet() 方法

3. 自定义的init() 方法

Destroy方法以相同的顺序调用:

1. 包含@PreDestroy注解的方法

2. 在DisposableBean接口中的destroy() 方法

3. 自定义的destroy() 方法

开始和关闭回调

Lifecycle接口中为所有具有自定义生命周期需求的对象定义了一些基本方法（例如启动或停止一些后台进程）:

public interface Lifecycle {

    void start();

    void stop();

    boolean isRunning();
}

任何Spring管理的对象都可以实现Lifecycle 接口。然后，当ApplicationContext接收到启动和停止信号时（例如，对于运行时的停止/重启场景），ApplicationContext会通知到所有上下文中包含的生命周期对象。 它通过委托 LifecycleProcessor完成此操作，如下面的清单所示：

public interface LifecycleProcessor extends Lifecycle {

    void onRefresh();

    void onClose();
}