|
此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Framework 6.2.0！ |
自定义 Bean 的性质
Spring Framework 提供了许多接口，您可以使用这些接口来自定义 豆子。本节将它们分组如下：
生命周期回调
要与容器对 bean 生命周期的 Management 进行交互，您可以实现
SpringInitializingBean和DisposableBean接口。容器调用afterPropertiesSet()对于前者和destroy()对于后者，让 bean
在初始化和销毁 bean 时执行某些作。
|
The JSR-250 如果您不想使用 JSR-250 注解，但仍希望删除
耦合，请考虑 |
在内部，Spring 框架使用BeanPostProcessorimplementations 来处理任何
callback 接口，它可以找到并调用适当的方法。如果您需要自定义
功能或其他生命周期行为 Spring 默认不提供，您可以
实现BeanPostProcessor你自己。有关更多信息，请参阅容器扩展点。
除了初始化和销毁回调之外， Spring Management 的对象还可以
此外，实现Lifecycle接口，以便这些对象可以参与
启动和关闭过程，由容器自身的生命周期驱动。
生命周期回调接口将在 此部分 中介绍。
初始化回调
这org.springframework.beans.factory.InitializingBean接口允许 bean
在容器在
豆。这InitializingBeaninterface 指定单个方法：
void afterPropertiesSet() throws Exception;我们建议您不要使用InitializingBean接口，因为它
不必要地将代码耦合到 Spring。或者，我们建议使用
这@PostConstructannotation 或
指定 POJO 初始化方法。对于基于 XML 的配置元数据，
您可以使用init-method属性来指定具有 void 的方法的名称
no-argument 签名。通过 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 在包含它的容器被销毁时获取回调。这DisposableBeaninterface 指定单个方法：
void destroy() throws Exception;我们建议您不要使用DisposableBeancallback 接口，因为它
不必要地将代码耦合到 Spring。或者，我们建议使用
这@PreDestroyannotation 或
指定 Bean 定义支持的泛型方法。使用基于 XML 的
configuration 元数据，您可以使用destroy-method属性<bean/>.
通过 Java 配置，您可以使用destroyMethod属性@Bean.请参阅 接收生命周期回调。请考虑以下定义：
<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方法。这是 的默认行为@BeanJava 配置中的 methods
类并自动匹配java.lang.AutoCloseable或java.io.Closeable实现，也没有将销毁逻辑耦合到 Spring。
对于使用 XML 的销毁方法推理，您可以分配destroy-method属性
的<bean>元素为特殊(inferred)值，它指示 Spring 自动
检测公共close或shutdown方法。
您还可以将此(inferred)值default-destroy-method属性
的<beans>元素将此行为应用于整个 Bean 定义集（请参见默认初始化和销毁方法）。 |
|
对于延长的关闭阶段，您可以实施 |
默认 Initialization 和 Destroy 方法
当您编写不使用
特定于 SpringInitializingBean和DisposableBean回调接口，则
通常编写名称为init(),initialize(),dispose(),
等等。理想情况下，此类生命周期回调方法的名称在
一个项目，以便所有开发人员使用相同的方法名称并确保一致性。
你可以将 Spring 容器配置为“查找”命名初始化和销毁
回调方法名称。这意味着，作为应用程序开发人员，
可以编写您的应用程序类并使用名为init(),
而无需配置init-method="init"属性。
Spring IoC 容器在创建 bean 时调用该方法（并根据
使用前面描述的标准生命周期回调协定）。
此功能还对初始化和
destroy 方法回调。
假设您的初始化回调方法被命名为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>存在default-init-method属性<beans/>元素
属性使 Spring IoC 容器识别一个名为init在 Bean 上
class 作为初始化方法回调。在创建和组装 bean 时，如果
Bean 类具有这样一个方法，则会在适当的时间调用它。
您可以类似地（即在 XML 中）通过使用default-destroy-method属性<beans/>元素。
现有 Bean 类已经具有以 Variance 命名的回调方法
使用约定，您可以通过指定（在 XML 中，即）来覆盖默认值
方法名称init-method和destroy-method的属性<bean/>本身。
Spring 容器保证调用配置的初始化回调
紧接着为 bean 提供所有依赖项。因此，初始化
callback 在原始 bean 引用上调用，这意味着 AOP 拦截器等
forth 尚未应用于 Bean。首先完全创建目标 Bean，然后
然后应用 AOP 代理（例如）及其拦截器链。如果目标
bean 和 proxy 是单独定义的，你的代码甚至可以与原始的
target bean，绕过代理。因此，应用
拦截器添加到init方法，因为这样做会耦合
将 bean 绑定到其代理或拦截器，并在您的代码
直接与原始目标 Bean 交互。
组合生命周期机制
从 Spring 2.5 开始，您有三个选项来控制 bean 生命周期行为：
-
习惯
init()和destroy()方法 -
-
您可以组合这些机制来控制给定的 bean。
-
如果为 Bean 配置了多个生命周期机制，并且每个机制都是
配置了不同的方法名称，则每个配置的方法都会在
在此说明之后列出的顺序。但是，如果配置了相同的方法名称 — 例如，init()对于初始化方法 — 对于这些生命周期机制中的多个，
该方法运行一次，如上一节所述。 |
为同一 bean 配置了多个生命周期机制，具有不同的 初始化方法的调用方式如下：
-
注释有
@PostConstruct -
afterPropertiesSet()由InitializingBean回调接口 -
自定义配置
init()方法
Destroy 方法的调用顺序相同：
-
注释有
@PreDestroy -
destroy()由DisposableBean回调接口 -
自定义配置
destroy()方法
启动和关闭回调
这Lifecycleinterface 为任何具有自己的
生命周期要求（例如启动和停止某些后台进程）：
public interface Lifecycle {
void start();
void stop();
boolean isRunning();
}任何 Spring 管理的对象都可以实现Lifecycle接口。然后，当ApplicationContext本身接收开始和停止信号（例如，对于 STOP/RESTART
场景），它会将这些调用级联到所有Lifecycle实现
在该上下文中定义。它通过委托给LifecycleProcessor显示
在下面的清单中：
public interface LifecycleProcessor extends Lifecycle {
void onRefresh();
void onClose();
}请注意，LifecycleProcessor本身是Lifecycle接口。它还添加了另外两种方法来响应正在刷新的上下文
并关闭。
|
请注意，常规的 另外，请注意，不保证在销毁之前收到停止通知。
在常规关闭时，所有 |
启动和关闭调用的顺序可能很重要。如果 “depends-on”
关系存在于任意两个对象之间，则依赖端在其
依赖项，并且它在依赖项之前停止。然而，有时，直接的
依赖项是未知的。您可能只知道特定类型的对象应该启动
在其他类型的对象之前。在这些情况下，SmartLifecycleinterface 定义
另一个选项，即getPhase()方法，即Phased.下面的清单显示了Phased接口：
public interface Phased {
int getPhase();
}下面的清单显示了SmartLifecycle接口：
public interface SmartLifecycle extends Lifecycle, Phased {
boolean isAutoStartup();
void stop(Runnable callback);
}开始时，阶段最低的对象首先启动。停止时，
遵循 Reverse Order。因此，实现SmartLifecycle和
谁的getPhase()method 返回Integer.MIN_VALUE将是第一批开始的人
也是最后一个停下来的。在频谱的另一端，相位值为Integer.MAX_VALUE将指示对象应最后启动并停止
first （可能是因为它依赖于其他进程运行）。在考虑
phase 值，同样重要的是要知道任何 “normal” 的默认 phaseLifecycle未实现SmartLifecycle是0.因此，任何
负相位值表示对象应在这些标准之前开始
组件（并在它们之后停止）。对于任何正相位值，情况正好相反。
由SmartLifecycle接受回调。任何
实现必须调用该回调的run()方法，在该实现的
shutdown 过程完成。这将在必要时启用异步关闭，因为
默认实现的LifecycleProcessor接口DefaultLifecycleProcessor等待对象组的超时值
在每个阶段中调用该回调。默认的每阶段超时为 30 秒。
您可以通过定义一个名为lifecycleProcessor在上下文中。如果只想修改超时，
定义以下内容就足够了：
<bean id="lifecycleProcessor" class="org.springframework.context.support.DefaultLifecycleProcessor">
<!-- timeout value in milliseconds -->
<property name="timeoutPerShutdownPhase" value="10000"/>
</bean>如前所述，LifecycleProcessorinterface 定义
刷新和关闭上下文。后者驱动关闭
process as ifstop()被显式调用，但当上下文为
关闭。另一方面，'refresh' 回调启用了SmartLifecycle豆。刷新上下文时（在所有对象都已
instantiated 和 initialized），则会调用该回调。此时，
默认生命周期处理器会检查每个SmartLifecycle对象的isAutoStartup()方法。如果true，则该对象为
启动，而不是等待显式调用上下文的 OR
自己start()方法（与上下文刷新不同，上下文启动不会发生
automatically 用于标准上下文实现）。这phasevalue 和任何
“depends-on” 关系确定 Startup Sequence，如前所述。
在非 Web 应用程序中正常关闭 Spring IoC 容器
|
本节仅适用于非 Web 应用程序。Spring 的基于 Web 的 |
如果你在非 Web 应用程序环境中使用 Spring 的 IoC 容器（对于 例如，在富客户端桌面环境中），使用 JVM 的 JVM 中。这样做可以确保正常关闭，并在 singleton bean 的实例，以便释放所有资源。您仍必须配置 并正确实现这些 destroy 回调。
要注册 shutdown 钩子，请调用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...
}线程安全性和可见性
Spring 核心容器以线程安全的方式发布创建的单例实例， 通过单例锁保护访问并保证在其他线程中的可见性。
因此，应用程序提供的 Bean 类不必关心
其初始化状态的可见性。常规配置字段不必为
标记为volatile只要它们只在初始化阶段发生 mutation，
提供类似于final甚至适用于基于 setter 的配置
state 的 state 在初始阶段是可变的。如果此类字段在
bean 创建阶段及其随后的初始发布，它们需要声明为volatile或由公共锁保护。
请注意，在单例 bean 实例中对此类配置状态的并发访问，
例如，对于 Controller 实例或 Repository 实例，在
这样从容器端开始的 SAFE 初始发布。这包括常见的单例FactoryBean实例，这些实例也在 General Singleton Lock 中处理。
对于销毁回调，配置状态保持线程安全，但任何运行时
初始化和销毁之间累积的状态应保存在线程安全状态
结构（或在volatile字段）。
更深Lifecycle如上所示的集成涉及运行时可变状态，例如
一个runnablefield 中，必须声明为volatile.虽然常见的
生命周期回调遵循一定的顺序，例如，开始回调保证
仅在完全初始化后发生，并且仅在初始启动后停止回调，
销毁前公共停止安排有一个特殊情况：它是 strongly
建议任何此类 bean 中的内部状态也允许立即
destroy 回调，因为这可能发生在非常规
在取消引导后或由另一个 Bean 导致停止超时的情况下关闭。
ApplicationContextAware和BeanNameAware
当ApplicationContext创建一个实现org.springframework.context.ApplicationContextAwareinterface 中，实例会提供
并引用ApplicationContext.下面的清单显示了定义
的ApplicationContextAware接口：
public interface ApplicationContextAware {
void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}因此，bean 可以通过编程方式作ApplicationContext创造了他们，
通过ApplicationContext接口，或者将引用强制转换为已知的
子类（例如ConfigurableApplicationContext，它公开了
附加功能）。一种用途是以编程方式检索其他 bean。
有时此功能很有用。但是，一般来说，您应该避免使用它，因为
它将代码耦合到 Spring，并且不遵循 Inversion of Control 风格，
其中，协作者作为属性提供给 bean。其他方法ApplicationContext提供对文件资源的访问、发布应用程序事件、
并访问MessageSource.这些附加功能在的附加功能ApplicationContext.
自动装配是获取对ApplicationContext.传统的 constructor和byType自动装配模式
（如 Autowiring Collaborators 中所述）可以提供ApplicationContext对于 constructor 参数或 setter 方法参数，
分别。为了提高灵活性，包括自动装配字段和
多个参数方法，使用基于注释的自动装配功能。如果这样做，
这ApplicationContext自动连接到字段、构造函数参数或方法
参数，该参数需要ApplicationContext如果字段、构造函数或
有问题的方法带有@Autowired注解。有关更多信息，请参阅用@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让 bean 向容器指示的回调接口
它们需要一定的基础设施依赖性。作为一般规则，该名称表示
dependency 类型。下表总结了最重要的Aware接口：
| 名字 | 注入的依赖项 | 解释于... |
|---|---|---|
|
声明 |
|
|
封闭事件发布者 |
|
|
用于加载 bean 类的类加载器。 |
|
|
声明 |
|
|
声明 Bean 的名称。 |
|
|
定义了 weaver，用于在加载时处理类定义。 |
|
|
用于解析消息的配置策略（支持参数化和 国际化）。 |
|
|
Spring JMX 通知发布者。 |
|
|
配置了 loader ，用于对资源的低级访问。 |
|
|
当前 |
|
|
当前 |
再次注意，使用这些接口会将您的代码绑定到 Spring API，并且不会 遵循 Inversion of Control 样式。因此，我们建议将它们用于基础设施 需要以编程方式访问容器的 bean。