自定义 Bean 的特性

Spring Framework 提供了许多接口，您可以使用它们来自定义 Bean 的特性。本节将它们归类如下：

生命周期回调

要与容器对 Bean 生命周期的管理进行交互，您可以实现 Spring 的 InitializingBean 和 DisposableBean 接口。容器会为前者调用 afterPropertiesSet()，为后者调用 destroy()，以便 Bean 在初始化和销毁时执行某些操作。

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

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

在内部，Spring Framework 使用 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 配置时，可以使用 @Bean 的 initMethod 属性。请参阅 接收生命周期回调。考虑以下示例：

<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 耦合。

请注意，@PostConstruct 和一般的初始化方法是在容器的单例创建锁内执行的。只有在 @PostConstruct 方法返回后，Bean 实例才被认为是完全初始化并准备好发布给其他对象。这些单独的初始化方法仅用于验证配置状态，并可能根据给定配置准备一些数据结构，而不能进行任何涉及外部 Bean 访问的进一步活动。否则存在初始化死锁的风险。

对于需要触发昂贵的后初始化活动（例如，异步数据库准备步骤）的场景，您的 Bean 应该实现 SmartInitializingSingleton.afterSingletonsInstantiated() 或依赖上下文刷新事件：实现 ApplicationListener<ContextRefreshedEvent> 或声明其等效注解 @EventListener(ContextRefreshedEvent.class)。这些变体在所有常规单例初始化之后发生，因此不在任何单例创建锁之外。

或者，您可以实现 (Smart)Lifecycle 接口并与容器的整体生命周期管理集成，包括自动启动机制、预销毁停止步骤以及潜在的停止/重启回调（见下文）。

销毁回调

实现 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 中的销毁方法推断，您可以将 <bean> 元素的 destroy-method 属性指定为特殊的 (inferred) 值，这会指示 Spring 自动检测特定 bean 定义的 bean 类上的公共 close 或 shutdown 方法。您还可以将此特殊的 (inferred) 值设置到 <beans> 元素的 default-destroy-method 属性上，以将此行为应用于整个 bean 定义集（参见 默认初始化和销毁方法）。

对于扩展的关闭阶段，您可以实现 Lifecycle 接口并在调用任何单例 Bean 的销毁方法之前接收到一个早期停止信号。您还可以实现 SmartLifecycle 来实现一个有时限的停止步骤，容器将等待所有此类停止处理完成，然后再继续执行销毁方法。

默认初始化和销毁方法

当您编写不使用 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 类有这样的方法，它将在适当的时间被调用。

您可以通过在顶级 <beans/> 元素上使用 default-destroy-method 属性来类似地配置销毁方法回调（即在 XML 中）。

如果现有 Bean 类已经有与约定不符的命名回调方法，您可以通过指定（在 XML 中）方法名，使用 <bean/> 本身的 init-method 和 destroy-method 属性来覆盖默认值。

Spring 容器保证在 Bean 获得所有依赖项后立即调用配置的初始化回调。因此，初始化回调是在原始 Bean 引用上调用的，这意味着 AOP 拦截器等尚未应用于 Bean。目标 Bean 首先完全创建，然后应用 AOP 代理（例如）及其拦截器链。如果目标 Bean 和代理是分开定义的，您的代码甚至可以直接与原始目标 Bean 交互，绕过代理。因此，将拦截器应用于 init 方法将是不一致的，因为这样做会将目标 Bean 的生命周期与其代理或拦截器耦合，并在您的代码直接与原始目标 Bean 交互时留下奇怪的语义。

组合生命周期机制

从 Spring 2.5 开始，您有三种控制 Bean 生命周期行为的选项：

如果为 Bean 配置了多个生命周期机制，并且每个机制都配置了不同的方法名，则每个配置的方法将按照本注释后面列出的顺序运行。然而，如果为多个生命周期机制配置了相同的方法名——例如，初始化方法为 init() ——该方法将只运行一次，如前一节所述。

为同一个 Bean 配置的多个生命周期机制，具有不同的初始化方法，按以下顺序调用：

  1. 用 @PostConstruct 注解的方法

  2. 由 InitializingBean 回调接口定义的 afterPropertiesSet()

  3. 自定义配置的 init() 方法

销毁方法按相同顺序调用：

  1. 用 @PreDestroy 注解的方法

  2. 由 DisposableBean 回调接口定义的 destroy()

  3. 自定义配置的 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 接口。

此外，请注意，停止通知不保证在销毁之前发生。在正常关闭时，所有 Lifecycle Bean 首先收到停止通知，然后才传播通用的销毁回调。但是，在上下文生命周期内的热刷新或停止刷新尝试中，只调用销毁方法。

启动和关闭调用的顺序可能很重要。如果任意两个对象之间存在“依赖于”关系，则依赖方在其依赖项之后启动，并在其依赖项之前停止。然而，有时直接依赖项是未知的。您可能只知道某种类型的对象应该在另一种类型的对象之前启动。在这些情况下，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() 一样，但它发生在上下文关闭时。另一方面，“刷新”回调启用了 SmartLifecycle Bean 的另一个功能。当上下文刷新时（所有对象都已实例化和初始化后），将调用该回调。此时，默认的生命周期处理器会检查每个 SmartLifecycle 对象的 isAutoStartup() 方法返回的布尔值。如果为 true，则该对象会在此时启动，而不是等待对上下文或其自身的 start() 方法的显式调用（与上下文刷新不同，上下文启动不会自动发生对于标准上下文实现）。phase 值和任何“depends-on”关系决定了启动顺序，如前所述。

在非 Web 应用程序中优雅地关闭 Spring IoC 容器

本节仅适用于非 Web 应用程序。Spring 基于 Web 的 ApplicationContext 实现已经有代码可以在相关 Web 应用程序关闭时优雅地关闭 Spring IoC 容器。

如果您在非 Web 应用程序环境（例如，富客户端桌面环境）中使用 Spring 的 IoC 容器，请向 JVM 注册一个关闭钩子。这样做可以确保优雅关闭并调用单例 Bean 上的相关销毁方法，从而释放所有资源。您仍然必须正确配置和实现这些销毁回调。

要注册关闭钩子，请调用 ConfigurableApplicationContext 接口上声明的 registerShutdownHook() 方法，如以下示例所示：

  • 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...
}

线程安全和可见性

Spring 核心容器以线程安全的方式发布创建的单例实例，通过单例锁保护访问并保证在其他线程中的可见性。

因此，应用程序提供的 Bean 类不必担心其初始化状态的可见性。常规配置字段不必标记为 volatile，只要它们仅在初始化阶段发生变化，即使对于在该初始阶段可变的基于 setter 的配置状态，也提供类似于 final 的可见性保证。如果这些字段在 Bean 创建阶段及其后续初始发布之后发生更改，则在访问时需要将其声明为 volatile 或由公共锁保护。

请注意，在容器侧进行安全初始发布后，对单例 Bean 实例（例如控制器实例或存储库实例）中此类配置状态的并发访问是完全线程安全的。这包括在通用单例锁内处理的常见单例 FactoryBean 实例。

对于销毁回调，配置状态保持线程安全，但初始化和销毁之间累积的任何运行时状态都应按照通用 Java 准则保存在线程安全结构中（或在简单情况下保存在 volatile 字段中）。

如上所示，更深层次的 Lifecycle 集成涉及运行时可变状态，例如必须声明为 volatile 的 runnable 字段。虽然常见的生命周期回调遵循一定的顺序，例如，启动回调保证仅在完全初始化后发生，停止回调仅在初始启动后发生，但存在一个特殊情况，即在销毁之前进行常见的停止安排：强烈建议任何此类 Bean 中的内部状态也允许在没有先行停止的情况下立即进行销毁回调，因为这可能发生在取消引导后的异常关闭期间或由于另一个 Bean 引起的停止超时。

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 自动装配模式（如 自动装配协作者 中所述）可以分别为构造函数参数或 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() 或自定义初始化方法等初始化回调之前调用。

其他 Aware 接口

除了 ApplicationContextAware 和 BeanNameAware（前面讨论过）之外，Spring 还提供了各种 Aware 回调接口，让 Bean 可以向容器指示它们需要某个基础设施依赖项。一般来说，名称表示依赖项类型。下表总结了最重要的 Aware 接口：

表1. Aware 接口
名称 注入依赖项 解释于…​

ApplicationContextAware

声明 ApplicationContext。

ApplicationContextAware 和 BeanNameAware

ApplicationEventPublisherAware

封闭 ApplicationContext 的事件发布器。

ApplicationContext 的附加功能

BeanClassLoaderAware

用于加载 Bean 类的类加载器。

实例化 Bean

BeanFactoryAware

声明 BeanFactory。

BeanFactory API

BeanNameAware

声明 Bean 的名称。

ApplicationContextAware 和 BeanNameAware

LoadTimeWeaverAware

在加载时处理类定义的已定义织入器。

Spring Framework 中使用 AspectJ 进行加载时织入

MessageSourceAware

配置用于解析消息的策略（支持参数化和国际化）。

ApplicationContext 的附加功能

NotificationPublisherAware

Spring JMX 通知发布器。

通知

ResourceLoaderAware

配置用于低级资源访问的加载器。

资源

ServletConfigAware

容器当前运行的 ServletConfig。仅在支持 Web 的 Spring ApplicationContext 中有效。

Spring MVC

ServletContextAware

容器当前运行的 ServletContext。仅在支持 Web 的 Spring ApplicationContext 中有效。

Spring MVC

再次注意，使用这些接口会将您的代码与 Spring API 绑定，并且不遵循控制反转的风格。因此，我们建议将它们用于需要以编程方式访问容器的基础设施 Bean。

© . This site is unofficial and not affiliated with VMware.