1.6 定制Bean的本质

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

生命周期回调
ApplicationContextAware 和 BeanNameAware
其他Aware接口

1.6.1 生命周期回调

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

JSR-250 @PostConstruct和@PreDestroy注释通常被认为是在现代Spring应用程序中接收生命周期回调的最佳实践。使用这些注释意味着您的bean不会耦合到特定于Spring的接口。有关详细信息，请参阅使用@PostConstruct和@PreDestroy。
如果您不想使用JSR-250注释但仍想删除耦合，请考虑使用init-method和destroy-method对象定义元数据。

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

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

destory回调

实现org.springframework.beans.factory.DisposableBean接口允许bean在包含它的容器被销毁时获得回调。的 DisposableBean接口规定了一个方法：

void destroy() throws Exception;

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

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

您可以destroy-method为元素的属性分配一个特殊 (inferred)值，该值指示Spring自动检测特定bean类的公共close或 shutdown方法。（任何实现 java.lang.AutoCloseable或java.io.Closeable将匹配的类。）您还可以(inferred)在元素的default-destroy-method属性上设置此特殊值，以将此行为应用于整组bean（请参阅默认初始化和销毁…方法）。请注意，这是Java配置的默认行为。

默认初始化和销毁方法

当你写的初始化和销毁不使用Spring的具体方法回调InitializingBean和DisposableBean回调接口，你通常写有名字，如方法init()，initialize()，dispose()，等等。理想情况下，此类生命周期回调方法的名称在项目中是标准化的，以便所有开发人员使用相同的方法名称并确保一致性。

您可以将Spring容器配置为“查找”命名初始化并销毁每个bean上的回调方法名称。这意味着，作为应用程序开发人员，您可以编写应用程序类并使用调用的初始化回调 init()，而无需为init-method="init"每个bean定义配置属性。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>

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

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

如果现有的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()方法
在@PostConstruct和@PreDestroy注解,您可以组合这些机制来控制给定的bean

如果为bean配置了多个生命周期机制，并且每个机制都配置了不同的方法名称，则每个配置的方法都按照此注释后列出的顺序执行。但是，如果init()为多个生命周期机制配置了相同的方法名称（例如，对于初始化方法），则该方法将执行一次，如上一节中所述。

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

用注解方法 @PostConstruct
afterPropertiesSet()由InitializingBean回调接口定义
自定义配置的init()方法

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

用注释方法注释 @PreDestroy
destroy()由DisposableBean回调接口定义
自定义配置的destroy()方法

startup启动和shutdown关闭回调
该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在传播一般销毁回调之前首先收到停止通知。但是，在上下文生命周期中的热刷新或中止刷新尝试时，仅调用destroy方法。

启动和关闭调用的顺序非常重要。如果任何两个对象之间存在“依赖”关系，则依赖方在其依赖之后开始，并且在其依赖之前停止。但是，有时，直接依赖性是未知的。您可能只知道某种类型的对象应该在另一种类型的对象之前开始。在这些情况下，SmartLifecycle接口定义了另一个选项，即getPhase()在其超级接口上定义的方法 Phased。以下清单显示了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将指示对象应该最后启动并首先停止（可能因为它依赖于正在运行的其他进程）。当考虑相位值，同样重要的是要知道，对于任何“正常”的默认阶段 Lifecycle目标没有实现SmartLifecycle的0。因此，任何负相位值都表示对象应该在这些标准组件之前启动（并在它们之后停止）。任何正相值都是相反的。

定义的stop方法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’回调启用了SmartLifecyclebean的另一个功能。刷新上下文时（在实例化并初始化所有对象之后），将调用该回调。此时，默认生命周期处理器检查每个SmartLifecycle对象的isAutoStartup()方法返回的布尔值。如果true，那个对象是在那个点开始的，而不是等待显式调用上下文或它自己的对象start()方法（与上下文刷新不同，上下文启动不会自动发生在标准上下文实现中）。该phase值与任何“依赖式”的关系确定为前面所述的启动顺序。

1.6.2 ApplicationContextAware和BeanNameAware

当ApplicationContext创建实现org.springframework.context.ApplicationContextAware接口的对象实例时，将为该实例提供对该实例的引用ApplicationContext。以下清单显示了ApplicationContextAware界面的定义：

public interface ApplicationContextAware {

    void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}

因此，bean可以ApplicationContext通过ApplicationContext接口以编程方式操作创建它们的方法，或者通过将引用转换为此接口的已知子类（例如ConfigurableApplicationContext，公开其他功能）。一种用途是对其他bean进行编程检索。有时这种能力很有用。但是，一般情况下，您应该避免使用它，因为它将代码耦合到Spring并且不遵循Inversion of Control样式，其中协作者作为属性提供给bean。其他方法 ApplicationContext提供对文件资源的访问，发布应用程序事件和访问MessageSource。这些附加功能在附加ApplicationContext功能中描述。

从Spring 2.5开始，autowiring是另一种获取引用的方法 ApplicationContext。“传统” constructor和byType自动装配模式（如自动装配协作者中所述）可以分别为ApplicationContext构造函数参数或setter方法参数提供类型的依赖性。要获得更大的灵活性，包括自动装配字段和多参数方法的能力，请使用基于注释的新自动装配功能。如果这样做，ApplicationContext则自动装入一个字段，构造函数参数或方法参数，ApplicationContext如果相关的字段，构造函数或方法带有@Autowired注释，则该参数需要该类型。有关更多信息，请参阅使用@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可以让豆子指示，他们需要一定的基础设施的依赖容器接口。作为一般规则，名称是依赖类型的良好指示。下表总结了最重要的Aware接口：
表4.感知接口

名称	注入依赖	解释在…
ApplicationContextAware	声明ApplicationContext	ApplicationContextAware and BeanNameAware
ApplicationEventPublisherAware	封闭的事件发布者ApplicationContext	Additional Capabilities of the ApplicationContext
BeanClassLoaderAware	用于加载bean类的类加载器	实例化的Bean
BeanFactoryAware	声明一个BeanFactory	ApplicationContextAware and BeanNameAware
BeanNameAware	声明Bean的名字	ApplicationContextAware 和BeanNameAware
BootstrapContextAware	BootstrapContext容器运行的资源适配器。通常仅在JCA感知ApplicationContext实例中可用。	JCA CCI
LoadTimeWeaverAware	定义的weaver用于在加载时处理类定义。	Load-time Weaving with AspectJ in the Spring Framework
MessageSourceAware	用于解析消息的已配置策略（支持参数化和国际化）	Additional Capabilities of the ApplicationContext
NotificationPublisherAware	Spring JMX通知发布者。	Notifications
ResourceLoaderAware	配置的加载程序，用于对资源进行低级访问。	Resources
ServletConfigAware	当前ServletConfig容器运行。仅在 web-aware Spring ApplicationContext中有效	Spring MVC
ServletContextAware	当前ServletContext容器运行。仅在 web-aware Spring ApplicationContext中有效	Spring MVC

请再次注意，使用这些接口会将您的代码绑定到Spring API，而不会遵循Inversion of Control样式。因此，我们建议将它们用于需要以编程方式访问容器的基础架构bean。

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

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

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

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

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

本文标题：2.6 Spring Framework 5.x 之自定义Bean的本质(Bean的生命周期回调)

本文链接：https://blog.quwenai.cn/post/2969.html

作者授权：除特别说明外，本文由 toobug 原创编译并授权 TOOBUG信息安全网刊载发布。

本文链接：https://blog.quwenai.cn/post/2969.html

分享到：

正文

2.6 Spring Framework 5.x 之自定义Bean的本质(Bean的生命周期回调)

1.6 定制Bean的本质

1.6.1 生命周期回调

初始化回调

destory回调

默认初始化和销毁方法

结合生命周期机制

1.6.2 ApplicationContextAware和BeanNameAware

1.6.3. 其他Aware接口

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

相关阅读

0x04 Spring Boot 2.x之Properties和yaml配置文件详解

0x08 Spring Boot 2.x 之Security

0x01 Spring Boot 2.x 之入门学习指南

0x02 Spring Boot 2.x之如何使用

发表评论取消回复

还没有评论，来说两句吧...

目录[+]