|
对于最新的稳定版本，请使用 Spring Framework 7.0.6! |
自定义Bean的性质
Spring Framework 提供了许多接口，您可以使用它们来定制 bean 的性质。本节将其按如下方式分组：
生命周期回调
要与容器对bean生命周期的管理进行交互，可以实现Spring InitializingBean和DisposableBean接口。容器会调用afterPropertiesSet()用于前者，destroy()用于后者，以便在您的beans初始化和销毁时让bean执行某些操作。
|
JSR-250 如果您不希望使用 JSR-250 注释但仍希望解耦，请考虑 |
内部，Spring 框架使用 BeanPostProcessor 个实现来处理它能找到的任何回调接口并调用相应的方法。如果您需要 Spring 默认不提供的自定义功能或其他生命周期行为，您可以自己实现一个 BeanPostProcessor。有关更多信息，请参阅
容器扩展点。
除了初始化和销毁回调之外，Spring管理的对象还可以实现 Lifecycle 接口，以便这些对象可以参与由容器自身生命周期驱动的启动和关闭过程。
生命周期回调接口在此部分中进行描述。
初始化回调
org.springframework.beans.factory.InitializingBean 接口允许在容器对 bean 设置所有必要属性之后，让 bean 执行初始化工作。InitializingBean 接口指定了一个方法：
void afterPropertiesSet() throws Exception;我们建议不要使用 InitializingBean 接口，因为它不必要地将代码与 Spring 耦合。或者，我们建议使用 @PostConstruct 注解或指定一个 POJO 初始化方法。在基于 XML 的配置元数据情况下，可以使用 init-method 属性来指定一个具有 void 无参数签名的方法名称。对于 Java 配置，可以使用 initMethod 属性的 @Bean。参见 接收生命周期回调。考虑以下示例：
<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>-
Java
-
Kotlin
public class ExampleBean {
public void init() {
// do some initialization work
}
}class ExampleBean {
fun init() {
// do some initialization work
}
}前面的示例与以下示例（由两个清单组成）几乎具有相同的效果：
<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>-
Java
-
Kotlin
public class AnotherExampleBean implements InitializingBean {
@Override
public void afterPropertiesSet() {
// do some initialization work
}
}class AnotherExampleBean : InitializingBean {
override fun afterPropertiesSet() {
// do some initialization work
}
}然而，前面两个示例中的第一个并没有将代码与Spring耦合。
|
请注意， 在需要触发昂贵的后初始化操作的情况下，例如异步数据库准备步骤，您的Bean应实现
或者，您可以实现 |
销毁回调
实现 org.springframework.beans.factory.DisposableBean 接口可以让一个 bean 在包含它的容器被销毁时获得回调。 DisposableBean 接口指定一个方法：
void destroy() throws Exception;我们建议您不要使用 DisposableBean 回调接口，因为它不必要的将代码与 Spring 耦合。或者，我们建议使用 @PreDestroy 注解或指定一个由 bean 定义支持的通用方法。使用基于 XML 的配置元数据时，可以在 <bean/> 上使用 destroy-method 属性。使用 Java 配置时，可以使用 @Bean 的 destroyMethod 属性。参见 接收生命周期回调。考虑以下定义：
<bean id="exampleDestructionBean" class="examples.ExampleBean" destroy-method="cleanup"/>-
Java
-
Kotlin
public class ExampleBean {
public void cleanup() {
// do some destruction work (like releasing pooled connections)
}
}class ExampleBean {
fun cleanup() {
// do some destruction work (like releasing pooled connections)
}
}前面的定义几乎与以下定义具有相同的效果：
<bean id="exampleDestructionBean" class="examples.AnotherExampleBean"/>-
Java
-
Kotlin
public class AnotherExampleBean implements DisposableBean {
@Override
public void destroy() {
// do some destruction work (like releasing pooled connections)
}
}class AnotherExampleBean : DisposableBean {
override fun destroy() {
// do some destruction work (like releasing pooled connections)
}
}然而，前面两个定义中的第一个并没有将代码与Spring耦合。
请注意，Spring 还支持销毁方法的推断，会检测一个公共的 close 或 shutdown 方法。这是 Java 配置类中 @Bean 方法的默认行为，并会自动匹配 java.lang.AutoCloseable 或 java.io.Closeable 实现，从而不将销毁逻辑与 Spring 耦合。
对于使用XML的销毁方法推断，您可以将destroy-method元素的<bean>属性分配一个特殊的(inferred)值，这会指示Spring自动检测bean类上的公共close或shutdown方法，以用于特定的bean定义。您还可以将这个特殊的(inferred)值设置在default-destroy-method属性上，该属性属于<beans>元素，以将此行为应用于一组完整的bean定义（参见
默认的初始化和销毁方法）。 |
|
对于延长的关闭阶段，您可以实现 |
默认初始化和销毁方法
当你编写不使用Spring特定的InitializingBean和DisposableBean回调接口的初始化和销毁方法回调时，通常会编写诸如init()、initialize()、dispose()等名称的方法。理想情况下，这些生命周期回调方法的名称应在整个项目中标准化，以便所有开发人员使用相同的 方法名称并确保一致性。
您可以配置Spring容器以“查找”每个bean上的命名初始化和销毁回调方法名称。这意味着作为应用程序开发人员，您可以编写应用程序类并使用名为init()的初始化回调，而无需为每个bean定义配置init-method="init"属性。Spring IoC容器在创建bean时（并根据前面所述的标准生命周期回调约定描述）会调用该方法。此功能还对初始化和销毁方法回调强制执行一致的命名约定。
假设你的初始化回调方法命名为init()，而你的销毁回调方法命名为destroy()。那么你的类将类似于以下示例中的类：
-
Java
-
Kotlin
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.");
}
}
}class DefaultBlogService : BlogService {
private var blogDao: BlogDao? = null
// this is (unsurprisingly) the initialization callback method
fun init() {
if (blogDao == null) {
throw 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 类已经具有与约定不同的命名的回调方法，可以通过使用 init-method 和 destroy-method 属性在 XML 中指定方法名称来覆盖默认值。
Spring容器保证在bean获得所有依赖项之后立即调用配置的初始化回调。因此，初始化回调是在原始bean引用上调用的，这意味着AOP拦截器等尚未应用于该bean。首先完全创建目标bean，然后应用AOP代理（例如）及其拦截器链。如果目标bean和代理是单独定义的，您的代码甚至可以与原始目标bean交互，绕过代理。因此，对init方法应用拦截器将是不一致的，因为这样做会将目标bean的生命周期与其代理或拦截器耦合，并且当您的代码直接与原始目标bean交互时，会导致奇怪的语义。
结合生命周期机制
从 Spring 2.5 开始，您有三种选项可以控制 bean 的生命周期行为：
-
InitializingBean和DisposableBean回调接口 -
自定义
init()和destroy()方法 -
Java
@PostConstruct和@PreDestroy注解-
你可以将这些机制结合起来，以控制给定的bean。
-
如果为一个 bean 配置了多种生命周期机制，并且每种机制都配置了不同的方法名称，那么在本注释之后列出的顺序中运行每个配置的方法。但是，如果同一方法名称被配置为这些生命周期机制中的多个机制 — 例如，初始化方法配置为init() — 则该方法只运行一次，如前面的章节所述。 |
对于同一个 bean 配置了多种生命周期机制，使用不同的初始化方法时，调用方式如下：
-
使用
@PostConstruct注解的方法 -
afterPropertiesSet()由InitializingBean回调接口定义 -
一个自定义配置的
init()方法
销毁方法按相同的顺序被调用：
-
使用
@PreDestroy注解的方法 -
destroy()由DisposableBean回调接口定义 -
一个自定义配置的
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接口的扩展。它还添加了另外两个方法，用于响应上下文被刷新和关闭的情况。
|
请注意，常规的 同时，请注意停止通知不一定在销毁之前出现。
在正常关闭时，所有 |
启动和关闭调用的顺序可能很重要。如果任意两个对象之间存在“depends-on”关系，依赖的一方会在其依赖项之后启动，并在其依赖项之前停止。然而，有时直接依赖关系是未知的。您可能只知道某种类型的对象应在另一种类型的对象之前启动。在这种情况下，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定义的stop方法接受一个回调。任何实现都必须在其关闭过程完成后调用该回调的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 beans 的另一个功能。当上下文被刷新（在所有对象都被实例化和初始化之后）时，会调用该回调。此时，默认的生命周期处理器会检查每个 SmartLifecycle 对象的 isAutoStartup() 方法返回的布尔值。如果为 true，则会在该点启动该对象，而不是等待显式调用上下文或其自身的 start() 方法（与上下文刷新不同，标准上下文实现不会自动进行上下文启动）。phase 值和任何“depends-on”关系决定了如前所述的启动顺序。
在非Web应用程序中优雅地关闭Spring IoC容器
|
本节仅适用于非Web应用程序。Spring的基于Web的
|
如果你在非Web应用环境中使用Spring的IoC容器（例如，在富客户端桌面环境中），请向JVM注册一个关闭钩子。这样可以确保优雅地关闭，并在单例bean上调用相关销毁方法，以便释放所有资源。你仍然需要正确地配置和实现这些销毁回调。
要注册一个关闭钩子，请调用在 registerShutdownHook() 接口上声明的 ConfigurableApplicationContext 方法，如下例所示：
-
Java
-
Kotlin
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...
}
}import org.springframework.context.support.ClassPathXmlApplicationContext
fun main() {
val ctx = 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...
}ApplicationContextAware 和 BeanNameAware
当 ApplicationContext 创建一个实现 org.springframework.context.ApplicationContextAware 接口的对象实例时，该实例会获得对那个 ApplicationContext 的引用。下面的列表显示了 ApplicationContextAware 接口的定义：
public interface ApplicationContextAware {
void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}因此，bean可以通过ApplicationContext接口或通过将引用强制转换为该接口的已知子类（如ConfigurableApplicationContext，它公开了额外的功能）来编程地操作创建它们的ApplicationContext。一个用途是程序化地检索其他bean。有时这个功能很有用。然而，通常应避免这样做，因为它会使代码与Spring耦合，并且不符合控制反转风格，其中协作对象作为属性提供给bean。ApplicationContext的其他方法提供了对文件资源的访问、发布应用事件和访问MessageSource的功能。这些附加功能在 ApplicationContext的其他功能中进行了描述。
自动注入是获取对ApplicationContext的引用的另一种方法。传统的constructor和byType自动注入模式（如< a t="C8">自动注入协作对象中所述）可以分别为构造函数参数或setter方法参数提供类型为36注解时，ApplicationContext将被自动注入到期望ApplicationContext类型的字段、构造函数参数或方法参数中。有关更多信息，请参见< a t="C9">使用@Autowired。
当 ApplicationContext 创建一个实现 org.springframework.beans.factory.BeanNameAware 接口的类时，该类会获得对其相关对象定义中定义的名称的引用。下面的列表显示了 BeanNameAware 接口的定义：
public interface BeanNameAware {
void setBeanName(String name) throws BeansException;
}回调在正常 bean 属性填充之后被调用，但在初始化回调（如 InitializingBean.afterPropertiesSet() 或自定义的 init-method）之前。
其他 Aware 接口
除了 ApplicationContextAware 和 BeanNameAware（在前面讨论过），
Spring 提供了广泛的 Aware 回调接口，让 beans 可以向容器表明它们需要某种基础架构依赖。一般来说，名称表示依赖类型。下表总结了最重要的 Aware 接口：
| 名称 | 注入的依赖项 | 解释在…… |
|---|---|---|
|
声明 |
|
|
封闭的 |
|
|
用于加载 bean 类的类加载器。 |
|
|
声明 |
|
|
声明该 bean 的名称。 |
|
|
定义用于在加载时处理类定义的织入器。 |
|
|
用于解析消息的配置策略（支持参数化和国际化）。 |
|
|
Spring JMX 通知发布器。 |
|
|
用于低级别访问资源的配置加载器。 |
|
|
当前 |
|
|
当前 |
再次提醒，使用这些接口会将你的代码与 Spring API 绑定，并不遵循控制反转风格。因此，我们建议它们用于需要程序化访问容器的基础架构 Bean。