SpringBoot各类扩展点解析

标签：enc   为什么   ram   code   embed   prepare   需要   定义   env   

上篇文章我们深入分析了SpringBoot的一站式启动流程。然后我们知道SpringBoot的主要功能都是依靠它内部很多的扩展点来完成的，那毋容置疑，这些扩展点是我们应该深入了解的，那么本次且听我一一道来SpringBoot的各类扩展点。

二、SpringBoot各类扩展点详解

1.SpringApplicationRunListener

从命名我们就可以知道它是一个监听者，那纵观整个启动流程我们会发现，它其实是用来在整个启动流程中接收不同执行点事件通知的监听者。源码如下：

public interface SpringApplicationRunListener {
    void starting();
    void environmentPrepared(ConfigurableEnvironment environment);
    void contextPrepared(ConfigurableApplicationContext context);
    void contextLoaded(ConfigurableApplicationContext context);
    void finished(ConfigurableApplicationContext context, Throwable exception);
}

对于开发者来说，基本没有什么常见的场景要求我们必须实现一个自定义的SpringApplicationRunListener，即使是SpringBoot中也只默认实现了一个org.springframework.boot.context.eventEventPublishingRunListener, 用来在SpringBoot的整个启动流程中的不同时间点发布不同类型的应用事件(SpringApplicationEvent)。那些对这些应用事件感兴趣的ApplicationListener可以接受并处理(这也解释了为什么在SpringApplication实例化的时候加载了一批ApplicationListener，但在run方法执行的过程中并没有被使用)。

如果我们真的在实际场景中自定义实现SpringApplicationRunListener,有一个点需要注意：任何一个SpringApplicationRunListener实现类的构造方法都需要有两个构造参数，一个参数的类型就是我们的org.springframework.boot.SpringApplication,另外一个参数就是args参数列表的String[]:

package com.hafiz.springbootdemo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringApplicationRunListener;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.core.env.ConfigurableEnvironment;

/**
 * @author hafiz.zhang
 * @description:
 * @date Created in 2018/6/7 20:07.
 */
public class DemoSpringApplicationRunListener implements SpringApplicationRunListener {
    private final SpringApplication application;
    private final String[] args;
    public DemoSpringApplicationRunListener(SpringApplication sa, String[] args) {
        this.application = sa;
        this.args = args;
    }

    @Override
    public void starting() {
        System.out.println("自定义starting");
    }

    @Override
    public void environmentPrepared(ConfigurableEnvironment environment) {
        System.out.println("自定义environmentPrepared");
    }

    @Override
    public void contextPrepared(ConfigurableApplicationContext context) {
        System.out.println("自定义contextPrepared");
    }

    @Override
    public void contextLoaded(ConfigurableApplicationContext context) {
        System.out.println("自定义contextLoaded");
    }

    @Override
    public void finished(ConfigurableApplicationContext context, Throwable exception) {
        System.out.println("自定义finished");
    }
}

接着，我们还要满足SpringFactoriesLoader的约定，在当前SpringBoot项目的classpath下新建META-INF目录，并在该目录下新建spring.fatories文件，文件内容如下:

org.springframework.boot.SpringApplicationRunListener=\
com.hafiz.springbootdemo.DemoSpringApplicationRunListener

2.ApplicationListener

ApplicationListener不是新东西，它属于Spring框架对Java中实现的监听者模式的一种框架实现，这里需要注意的是：对于刚接触SpringBoot，但是对于Spring框架本身又没有过多地接触的开发人员来说，可能会将这个名字与SpringApplicationRunListener弄混。

如果我们有需要为SpringBoot应用添加我们自定义的ApplicationListener,那么有两种方式：

1. 通过SpringApplication.addListeners(…)或者SpringApplication.setListener(…)方法添加一个或者多个自定义的ApplicationListener。

2. 借助SpringFactoriesLoader机制，在SpringBoot的项目自定义的META-INF/spring.factories文件中添加配置(以下是SpringBoot默认的ApplicationListener配置)：

org.springframework.context.ApplicationListener=org.springframework.boot.ClearCachesApplicationListener,org.springframework.boot.builder.ParentContextCloserApplicationListener,org.springframework.boot.context.FileEncodingApplicationListener,org.springframework.boot.context.config.AnsiOutputApplicationListener,org.springframework.boot.context.config.ConfigFileApplicationListener,org.springframework.boot.context.config.DelegatingApplicationListener,org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener,org.springframework.boot.logging.ClasspathLoggingApplicationListener,org.springframework.boot.logging.LoggingApplicationListener

3.ApplicationContextInitializer

这货也是Spring框架原有的东西，这个类的主要作用就是在ConfigurableApplicationContext类型(或者子类型)的ApplicationContext做refresh之前，允许我们对ConfiurableApplicationContext的实例做进一步的设置和处理。

我们要实现一个自定义的ApplicationContextInitializer也很简单，它只有一个方法需要我们的自定义类实现：

package com.hafiz.springbootdemo;

import org.springframework.context.ApplicationContextInitializer;
import org.springframework.context.ConfigurableApplicationContext;

/**
 * @author hafiz.zhang
 * @description:
 * @date Created in 2018/6/7 20:33.
 */
public class DemoApplicationContextInitializer implements ApplicationContextInitializer {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        System.out.println("自定义DemoApplicationContextInitializer的initialize方法");
    }
}

然后也需要在项目自定义的META-INF/spring.factories文件中注册：

org.springframework.context.ApplicationContextInitializer=  com.hafiz.springbootdemo.DemoApplicationContextInitializer

不过我们一般情况下是不需要自定义一个ApplicationContextInitializer,即使SpringBoot框架默认也只有以下四个实现而已：

org.springframework.context.ApplicationContextInitializer=org.springframework.boot.context.ConfigurationWarningsApplicationContextInitializer,org.springframework.boot.context.ContextIdApplicationContextInitializer,org.springframework.boot.context.config.DelegatingApplicationContextInitializer,org.springframework.boot.context.embedded.ServerPortInfoApplicationContextInitializer

4.CommandLineRunner

CommandLineRunner并不是Spring框架原有的概念，它属于SpringBoot应用特定的回调扩展接口：

public interface CommandLineRunner {
    /**
     * Callback used to run the bean.
     * @param args incoming main method arguments
     * @throws Exception on error
     */
    void run(String... args) throws Exception;

}

关于这货，我们需要关注的点有两个：

1. 所有CommandLineRunner的执行时间点是在SpringBoot应用的Application完全初始化工作之后(这里我们可以认为是SpringBoot应用启动类main方法执行完成之前的最后一步)。

2. 当前SpringBoot应用的ApplicationContext中的所有CommandLinerRunner都会被加载执行(无论是手动注册还是被自动扫描注册到IoC容器中)。

   跟其他几个扩展点接口类型相似，我们建议CommandLineRunner的实现类使用@org.springframework.core.annotation.Order进行标注或者实现org.springframework.core.Ordered接口，便于对他们的执行顺序进行排序调整，这是非常有必要的，因为我们不希望不合适的CommandLineRunner实现类阻塞了后面其他CommandLineRunner的执行。这个接口非常有用和重要，我们需要重点关注。

三、你不知道的自动配置奥秘

上篇文章我们知道了，@EnableAutoConfiguration借助SpringFactoriesLoader可以将标注了@Configuration这个注解的JavaConfig类一并汇总并加载到最终的ApplicationContext，这么说只是很简单的解释，其实基于@EnableAutoConfiguration的自动配置功能拥有非常强大的调控能力。比如我们可以通过配合基于条件的配置能力或定制化加载顺序，对自动化配置进行更加细粒度的调整和控制。

1.基于条件的自动配置

这个基于条件的自动配置来源于Spring框架中的"基于条件的配置"特性。在Spring框架中，我们可以使用@Conditional这个注解配合@Configuration或@Bean等注解来干预一个配置或bean定义是否能够生效，它最终实现的效果或者语义类如下伪代码：

if (复合@Conditional规定的条件) {
    加载当前配置（Enable Current Configuration）或者注册当前bean定义;
}

要实现基于条件的配置，我们需要通过@Conditional注解指定自己Condition实现类就可以了(可以应用于类型Type的注解或者方法Method的注解)

@Conditional({DemoCondition1.class, DemoCondition2.class})

最重要的是，@Conditional注解可以作为一个Meta Annotaion用来标注其他注解实现类，从而构建各种复合注解，比如SpringBoot的autoconfigre模块就基于这一优良的革命传统，实现了一批这样的注解(在org.springframework.boot.autoconfigure.condition包下):

• @ConditionOnClass
• @ConditionOnBean
• @CondtionOnMissingClass
• @CondtionOnMissingBean
• @CondtionOnProperty
• ……

有了这些复合Annotation的配合，我们就可以结合@EnableAutoConfiguration实现基于条件的自动配置了。其实说白了，SpringBoot能够如此的盛行，很重要的一部分就是它默认提供了一系列自动配置的依赖模块，而这些依赖模块都是基于以上的@Conditional复合注解实现的，这也就说明这些所有的依赖模块都是按需加载的，只有复合某些特定的条件，这些依赖模块才会生效，这也解释了为什么自动配置是“智能”的。

2.定制化自动配置的顺序

在实现自动配置的过程中，我们除了可以提供基于条件的配置之外，我们还能对当前要提供的配置或组件的加载顺序进行个性化调整，以便让这些配置或者组件之间的依赖分析和组装能够顺利完成。

最经典的是我们可以通过使用@org.springframework.boot.autoconfigure.AutoConfigureBefore或者@org.springframework.boot.autoconfigure.AutoConfigureAfter让当前配置或者组件在某个其他组件之前或者之后进行配置。例如，假如我们希望某些JMX操作相关的bean定义在MBeanServer配置完成以后在进行配置，那我们就可以提供如下配置：

@Configuration
@AutoConfigureAfter(JmxAutoConfiguration.class)
public class AfterMBeanServerReadyConfiguration {
    @Autowired
    MBeanServer mBeanServer;

    // 通过@Bean添加其他必要的bean定义
}

四、总结

截至目前，我们已经完成了对SpringBoot的核心组件一一解析，总结来说，SpringBoot中大部分东西都是Spring框架中已经存在原有概念和实践方式，SpringBoot只是在这基础上对特定的场景进行定制、固化以及升级。然后正式这些固化升级让我们感受到了SpringBoot开发的便捷以及高效。

然后，你会突然发现，SpringBoot原来是这么的简单，其中并无任何秘密。但是Spring团队通过对Spring应用的固化和升级，让SpringBoot可以完成开发只关注业务逻辑开发的神奇事件，整个开发过程更加高效以及简单，但是对于SpringBoot的设计者来说，他们并没有耗费巨大的精力。另一方面来说，开箱即用才是未来发展的趋势，"约定大于配置(Convention Over Configuration)"也必将统领江山！

阿豪说
学到了？请我喝杯咖啡吧~

SpringBoot各类扩展点解析

标签：enc   为什么   ram   code   embed   prepare   需要   定义   env   

原文地址：https://blog.51cto.com/15047484/2560245