Spring 核心技术

Posted aotian

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spring 核心技术相关的知识,希望对你有一定的参考价值。

接上篇:Spring 核心技术(6)

version 5.1.8.RELEASE

1.6 定制 Bean 的特性

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

1.6.1 生命周期回调

要与容器的 bean 生命周期管理进行交互,可以实现 Spring InitializingBeanDisposableBean 接口。容器调用前者 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 配置时,可以使用 @BeandestroyMethod 属性。请参阅接收生命周期回调。请看以下定义:

<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 类的公共 closeshutdown 方法。(任何实现 java.lang.AutoCloseable或java.io.Closeable 的类都可以进行匹配。)你还可以在 <beans> 元素的 default-destroy-method 属性上设置此特殊(推测)值,以将此行为应用于整组 bean(请参阅默认初始化和销毁??方法)。请注意,这是使用 Java 配置时的默认行为。

默认初始化和销毁??方法

当你不使用 Spring 特定的 InitializingBeanDisposableBean 回调接口编写初始化和销毁回调方法时,通常会使用 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-methoddestroy-method 属性指定方法名称来覆盖默认值。

Spring 容器可以保证在为 bean 提供所有依赖项后立即调用已配置的初始化回调。因此,初始化回调实在原始 bean 引用上调用的,这意味着 AOP 拦截器等尚未应用于 bean。首先完全创建目标 bean,然后应用的 AOP 代理(例如带有拦截器链)。如果目标 bean 和代理是分开定义的,那么你的代码甚至可以绕过代理与原始目标 bean 交互。因此,将拦截器应用于 init 方法是不合适的,因为这样做会将目标 bean 的生命周期耦合到其代理或拦截器,并在代码直接与原始目标 bean 交互时表现出奇怪的语义。

合并生命周期机制

从 Spring 2.5 开始,你有三个控制 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
此外,请注意,在销毁之前不保证能收到停止通知。在常规关闭时,所有 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 将指示对象应该最后启动并首先停止(可能因为它依赖于正在运行的其他进程)。当考虑相位值,同样重要的是要知道,对于任何“正常”的没有实现 SmartLifecycleLifecycle 对象,默认值为 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 ApplicationContextAwareBeanNameAware

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 引用的方法。“传统” constructorbyType 自动装配模式(如自动装配协作者中所述)可以分别为构造函数参数或 setter 方法参数提供 ApplicationContext 类型的依赖。为了获得更大的灵活性,以及自动装配字段和多参数方法的能力,请使用基于注释的新自动装配功能。如果相关的字段,构造函数或方法带有 @Autowired 注解且需要 ApplicationContext 类型,ApplicationContext 会自动装入一个字段,构造函数参数或方法参数。有关更多信息,请参阅使用 @Autowired

ApplicationContext 创建实现 org.springframework.beans.factory.BeanNameAware 接口的类时,将为该类提供其关联对象定义中对应名称的引用。以下清单显示了 BeanNameAware 接口的定义:

public interface BeanNameAware 

    void setBeanName(String name) throws BeansException;

回调在普通 bean 属性设置之后,但在一个初始化回调之前,例如 InitializingBeanafterPropertiesSet 或自定义的初始化方法。

1.6.3 其他 Aware 接口

除了 ApplicationContextAwareBeanNameAware (在之前讨论过),Spring 提供了广泛的 Aware 回调让 bean 向容器指出他们需要一定的基础设依赖。作为一般规则,名称表示依赖关系类型。下表总结了最重要的 Aware 接口:

名称 注入依赖 描述
ApplicationContextAware 声明 ApplicationContext ApplicationContextAwareBeanNameAware
ApplicationEventPublisherAware 包含 ApplicationContext 的时间发布者 ApplicationContext 的其他功能
BeanClassLoaderAware 用于加载bean类的类加载器 实例化 Bean
BeanFactoryAware 声明 BeanFactory ApplicationContextAwareBeanNameAware
BeanNameAware 声明 bean 的名称 ApplicationContextAwareBeanNameAware
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。

以上是关于Spring 核心技术的主要内容,如果未能解决你的问题,请参考以下文章

Spring核心技术——Spring中Bean的生命周期

Spring 核心技术

Spring 核心技术

Spring 核心技术

[转]Spring3核心技术之事务管理机制

Spring核心技术IoC容器