接上篇：Spring 核心技术（6）
version 5.1.8.RELEASE
1.6 定制 Bean 的特性
Spring Framework 提供了许多可用于自定义 bean 特性的接口。本节将它们分组如下：
1.6.1 生命周期回调
要与容器的 bean 生命周期管理进行交互，可以实现 Spring InitializingBean 和 DisposableBean 接口。容器调用前者 afterPropertiesSet() 和后者的 destroy() 以便让 bean 在初始化和销毁 bean 时执行某些操作。
JSR-250
@PostConstruct和@PreDestroy注解通常被认为是在现代 Spring 应用程序中接收生命周期回调的最佳实践。使用这些注解意味着你的 bean 不会耦合到特定的 Spring 接口。有关详细信息，请参阅使用 @PostConstruct 和 @PreDestroy。
在内部，Spring Framework 使用 BeanPostProcessor 实现来处理它可以找到的任何回调接口并调用适当的方法。如果你需要自定义其他 Spring 默认不提供的功能或生命周期行为，可以自己实现 BeanPostProcessor。更多信息请参阅容器扩展点。
除了初始化和销毁回调之外，Spring 管理的对象还可以实现 Lifecycle 接口，以便这些对象可以参与容器自身的生命周期驱动的启动和关闭过程。
本节描述了生命周期回调接口。
初始化回调
org.springframework.beans.factory.InitializingBean 接口允许 bean 在容器完全设置其所有必要属性后进行初始化工作。InitializingBean 接口规定了一个方法：
void afterPropertiesSet() throws Exception;
我们建议不要使用 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 在包含它的容器被销毁时获得回调。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的类都可以进行匹配。）你还可以在<beans>元素的default-destroy-method属性上设置此特殊(推测)值，以将此行为应用于整组 bean（请参阅默认初始化和销毁方法）。请注意，这是使用 Java 配置时的默认行为。
默认初始化和销毁方法
当你不使用 Spring 特定的 InitializingBean 和 DisposableBean 回调接口编写初始化和销毁回调方法时，通常会使用 init()，initialize()，dispose() 等来命名方法。理想情况下，此类生命周期回调方法的名称在项目中是一致的的，以便所有开发人员使用相同的方法名称并确保一致性。
你可以将Spring容器配置为在每个 bean 上“查找”已经命名的初始化和销毁回调方法的名称。这意味着，作为应用程序开发人员，你可以编写应用程序类并使用 init() 作为初始化回调 ，而无需为每个 bean 定义配置 init-method="init" 属性。Spring IoC 容器在创建 bean 时调用该方法（根据前面描述的标准生命周期回调）。此功能还强制执行初始化和销毁方法回调的一致命名约定。
假设你的初始化回调方法已命名为 init() 并且您的销毁回调方法已命名为 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 类具有这样的方法，则会在适当的时候调用它。
你可以在XML中同样通过使用顶级 <beans/> 元素上的 default-destroy-method 属性来配置销毁方法回调。
如果现有的 bean 类已经具有与约定一致的回调方法，则可以在 XML 中通过使用自身 <bean/> 的 init-method 和 destroy-method 属性指定方法名称来覆盖默认值。
Spring 容器可以保证在为 bean 提供所有依赖项后立即调用已配置的初始化回调。因此，初始化回调实在原始 bean 引用上调用的，这意味着 AOP 拦截器等尚未应用于 bean。首先完全创建目标 bean，然后应用的 AOP 代理（例如带有拦截器链）。如果目标 bean 和代理是分开定义的，那么你的代码甚至可以绕过代理与原始目标 bean 交互。因此，将拦截器应用于 init 方法是不合适的，因为这样做会将目标 bean 的生命周期耦合到其代理或拦截器，并在代码直接与原始目标 bean 交互时表现出奇怪的语义。
合并生命周期机制
从 Spring 2.5 开始，你有三个控制 bean 生命周期行为的选项：
- 在 InitializingBean和 DisposableBean 回调接口
- 自定义
init()和destroy()方法 @PostConstruct和@PreDestroy注解。你可以组合这些机制来控制指定的 bean。
如果为 bean 配置了多个生命周期机制，并且每个机制都配置了不同的方法名称，则每个配置的方法都按照此注释后列出的顺序执行。但是，如果为多个这些生命周期机制配置了相同的方法名称（例如，给初始化方法命名为
init()），如上 一节中所述，该方法将执行一次。
为同一个 bean 配置的多个不同的初始化方法时，执行顺序如下：
@PostConstruct注解的方法InitializingBean定义的afterPropertiesSet()回调接口- 自定义配置的
init()方法
销毁方法以相同的顺序调用：
@PreDestroy注解的方法DisposableBean定义的destroy()回调接口- 自定义配置的
destroy()方法
启动和关闭回调
Lifecycle 接口为任何具有自己的生命周期要求的对象（例如启动和停止某些后台进程）定义了基本方法：
public interface Lifecycle {
void start();
void stop();
boolean isRunning();
}
任何 Spring 管理的对象都可以实现 Lifecycle 接口。然后，当 ApplicationContext 接收到启动和停止信号时（例如，对于运行时的停止/重启场景），它将级联调用上下文中定义的 Lifecycle 的所有实现。它通过委托给 LifecycleProcessor 来实现，如下面的清单所示：
public interface LifecycleProcessor extends Lifecycle {
void onRefresh();
void onClose();
}
请注意，LifecycleProcessor 它本身是 Lifecycle 接口的扩展。它还添加了另外两种方法来响应刷新和关闭上下文。
请注意，常规的
org.springframework.context.Lifecycle接口是显式启动和停止通知的简单协议，并不意味着在上下文刷新时自动启动。要对特定bean的自动启动（包括启动阶段）进行细粒度控制，请考虑实现org.springframework.context.SmartLifecycle。
此外，请注意，在销毁之前不保证能收到停止通知。在常规关闭时，所有Lifecyclebean 在一般销毁回调开始之前首先收到停止通知。但是，在上下文生命周期中的热刷新或中止刷新尝试时，仅调用销毁方法。
启动和关闭调用的顺序非常重要。如果任何两个对象之间存在“依赖”关系，则依赖方在其依赖之后开始，并且在其依赖之前停止。但是，有时，直接依赖性是未知的。你可能只知道某种类型的对象应该在另一种类型的对象之前开始。在这些情况下，SmartLifecycle 接口定义了另一个选项，即在其父级接口 Phased 上定义的方法 getPhase() 。以下内容展示了 Phased 接口的定义：
public interface Phased {
int getPhase();
}
以下内容展示了 SmartLifecycle 接口的定义：
public interface SmartLifecycle extends Lifecycle, Phased {
boolean isAutoStartup();
void stop(Runnable callback);
}
启动时，具有最低层的对象首先开始。停止时，遵循相反的顺序。因此，实现 SmartLifecycle 的对象和 getPhase() 返回的 Integer.MIN_VALUE 将是第一个开始和最后一个停止的对象。在另外一个领域内，相位值 Integer.MAX_VALUE 将指示对象应该最后启动并首先停止（可能因为它依赖于正在运行的其他进程）。当考虑相位值，同样重要的是要知道，对于任何“正常”的没有实现 SmartLifecycle 的 Lifecycle 对象，默认值为 0。因此，任何负相位值都表示对象应该在这些标准组件之前启动（并在它们之后停止）。任何正相值都是相反的。
SmartLifecycle 定义的停止方法接受回调。任何实现必须在该实现的关闭过程完成后调用该回调的 run() 方法。这样就可以在必要时启用异步关闭，因为LifecycleProcessor 接口的默认实现 DefaultLifecycleProcessor 等待每个周期内的对象组的超时值来调用该回调。默认的每阶段超时为30秒。可以通过定义在上下文中命名为 lifecycleProcessor 的 bean 来覆盖缺省生命周期处理器实例 。如果只想修改超时时间，则定义以下内容就足够了：
<bean id="lifecycleProcessor" class="org.springframework.context.support.DefaultLifecycleProcessor">
<!-- timeout value in milliseconds -->
<property name="timeoutPerShutdownPhase" value="10000"/>
</bean>
如之前所述，LifecycleProcessor 接口还定义了用于刷新和关闭上下文的回调方法。后者驱动关闭过程类似于显示调用 stop()，但它只在上下文关闭时发生。另一方面，'refresh' 回调启用了 SmartLifecycle bean的另一个功能 。刷新上下文时（在实例化并初始化所有对象之后），将调用该回调。此时，默认生命周期处理器检查每个 SmartLifecycle 对象的 isAutoStartup() 方法返回的布尔值 。如果是 true，那么对象是当时就开始的，而不是等待显式调用上下文或它自己的 start() 方法（与上下文刷新不同，上下文启动不会自动发生在标准上下文实现中）。phase 值与任何“依赖式”的关系确定了前面所述的启动顺序。
在非 Web 应用程序中优雅地关闭 Spring IoC 容器
本节仅适用于非 Web 应用程序。Spring 的基于 Web 的
ApplicationContext实现已经具有相关的代码，可以在相关 Web 应用程序关闭时正常关闭 Spring IoC 容器。
如果在非 Web 应用程序环境中使用 Spring 的 IoC 容器（例如，在客户机桌面环境中），请使用 JVM 注册关闭钩子。这样做可确保正常关闭并在单例 bean 上调用相关的销毁方法，以便释放所有资源。你必须正确配置和实现这些销毁回调。
要注册关闭钩子，请调用 ConfigurableApplicationContext 接口上声明的 registerShutdownHook() 方法，如以下示例所示：
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public final class Boot {
public static void main(final String[] args) throws Exception {
ConfigurableApplicationContext ctx = new ClassPathXmlApplicationContext("beans.xml");
// add a shutdown hook for the above context...
ctx.registerShutdownHook();
// app runs here...
// main method exits, hook is called prior to the app shutting down...
}
}
1.6.2 ApplicationContextAware 和 BeanNameAware
当 ApplicationContext 创建实现 org.springframework.context.ApplicationContextAware 接口的对象实例时，将为 ApplicationContext 提供对该实例的引用。以下清单显示了 ApplicationContextAware 接口的定义：
public interface ApplicationContextAware {
void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}
因此，bean 可以通过 ApplicationContext 接口或通过将引用转换为此接口的已知子类（例如公开其他功能的 ConfigurableApplicationContext，）以编程方式操纵创建它们的 ApplicationContext。一种用途是对其他 bean 进行编程检索。有时这种功能很有用。但是，一般情况下应该避免使用它，因为协作者作为属性提供给 bean 时会将代码耦合到 Spring 并且不遵循控制反转风格。ApplicationContext 的其他方法提供对文件资源的访问，发布应用程序事件以及访问 MessageSource。这些附加功能在ApplicationContext 的附加功能中描述 。
从 Spring 2.5 开始，自动装配是另一种获取 ApplicationContext 引用的方法。“传统” constructor 和 byType 自动装配模式（如自动装配协作者中所述）可以分别为构造函数参数或 setter 方法参数提供 ApplicationContext 类型的依赖。为了获得更大的灵活性，以及自动装配字段和多参数方法的能力，请使用基于注释的新自动装配功能。如果相关的字段，构造函数或方法带有 @Autowired 注解且需要 ApplicationContext 类型，ApplicationContext 会自动装入一个字段，构造函数参数或方法参数。有关更多信息，请参阅使用 @Autowired。
当 ApplicationContext 创建实现 org.springframework.beans.factory.BeanNameAware 接口的类时，将为该类提供其关联对象定义中对应名称的引用。以下清单显示了 BeanNameAware 接口的定义：
public interface BeanNameAware {
void setBeanName(String name) throws BeansException;
}
回调在普通 bean 属性设置之后，但在一个初始化回调之前，例如 InitializingBean，afterPropertiesSet 或自定义的初始化方法。
1.6.3 其他 Aware 接口
除了 ApplicationContextAware 和 BeanNameAware （在之前讨论过），Spring 提供了广泛的 Aware 回调让 bean 向容器指出他们需要一定的基础设依赖。作为一般规则，名称表示依赖关系类型。下表总结了最重要的 Aware 接口：
| 名称 | 注入依赖 | 描述 |
|---|---|---|
| ApplicationContextAware | 声明 ApplicationContext |
ApplicationContextAware 和 BeanNameAware |
| ApplicationEventPublisherAware | 包含 ApplicationContext 的时间发布者 | ApplicationContext 的其他功能 |
| BeanClassLoaderAware | 用于加载bean类的类加载器 | 实例化 Bean |
| BeanFactoryAware | 声明 BeanFactory | ApplicationContextAware 和 BeanNameAware |
| BeanNameAware | 声明 bean 的名称 | ApplicationContextAware 和 BeanNameAware |
| BootstrapContextAware | 容器运行的资源适配器 BootstrapContext。通常仅在支持 JCA 的 ApplicationContext 实例中可用 |
JCA CCI |
| LoadTimeWeaverAware | 定义在加载时用于处理类定义的 weaver | 在 Spring 框架中使用 AspectJ 进行加载时织入 |
| MessageSourceAware | 用于解析消息的已配置策略（支持参数化和国际化） | ApplicationContext 的其他功能 |
| NotificationPublisherAware | Spring JMX 通知发布者 | 通知 |
| ResourceLoaderAware | 用于对低层次资源进行访问的配置加载器 | 资源 |
| ServletConfigAware | 当前容器运行的 ServletConfig。仅在支持 Web 的 ApplicationContext 中有效 |
Spring MVC |
| ServletContextAware | 当前容器运行的 ServletContext。仅在支持 Web 的 ApplicationContext 中有效 |
Spring MVC |
请再次注意，使用这些接口会使你的代码与 Spring API 耦合，而且不会遵循 IOC 规范。因此，我们建议将它们用于需要以编程方式访问容器的基础架构 bean。