SpringBoot源码解析（十四）prepareContext

承接上文，本文继续SpringApplication的run方法往下分析，看prepareContext这行代码

先看下几个入参，context是刚新建好的容器，environment是我们真正要使用的环境对象，已经完成了配置文件等的装载，listeners中有一个事件发布器，内部含有springboot内置的监听器列表，applicationArguements是对命令行参数的一个封装，printerBanner是上面打印过的启动banner

进入方法实现

    private void prepareContext(ConfigurableApplicationContext context, ConfigurableEnvironment environment, SpringApplicationRunListeners listeners, ApplicationArguments applicationArguments, Banner printedBanner) {
        context.setEnvironment(environment);
        this.postProcessApplicationContext(context);
        this.applyInitializers(context);
        listeners.contextPrepared(context);
        if (this.logStartupInfo) {
            this.logStartupInfo(context.getParent() == null);
            this.logStartupProfileInfo(context);
        }

        ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
        beanFactory.registerSingleton("springApplicationArguments", applicationArguments);
        if (printedBanner != null) {
            beanFactory.registerSingleton("springBootBanner", printedBanner);
        }

        if (beanFactory instanceof DefaultListableBeanFactory) {
            ((DefaultListableBeanFactory)beanFactory).setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
        }

        Set<Object> sources = this.getAllSources();
        Assert.notEmpty(sources, "Sources must not be empty");
        this.load(context, sources.toArray(new Object[0]));
        listeners.contextLoaded(context);
    }

我们一行一行来解读，首先第一行setEnvironment方法

context.setEnvironment(environment);

它把我们传进来的environment设置到了容器中，替换掉了新建容器时创建的environment，关于这点我们上篇有提到过一个瑕疵，因为这里虽然替换了容器原生的environement，但之前初始化SpringBootExceptionReporter的时候，已经把原生的environment设置到了异常分析器中，这些分析器持有的environment没有得到同步的更新，并不是我们真正使用的环境对象

然后看下第二行postProcessApplicationContext方法

this.postProcessApplicationContext(context);

进入方法实现

    protected void postProcessApplicationContext(ConfigurableApplicationContext context) {
        if (this.beanNameGenerator != null) {
            context.getBeanFactory().registerSingleton("org.springframework.context.annotation.internalConfigurationBeanNameGenerator", this.beanNameGenerator);
        }

        if (this.resourceLoader != null) {
            if (context instanceof GenericApplicationContext) {
                ((GenericApplicationContext)context).setResourceLoader(this.resourceLoader);
            }

            if (context instanceof DefaultResourceLoader) {
                ((DefaultResourceLoader)context).setClassLoader(this.resourceLoader.getClassLoader());
            }
        }

        if (this.addConversionService) {
            context.getBeanFactory().setConversionService(ApplicationConversionService.getSharedInstance());
        }

    }

首先看SpringApplication对象中有没有自定义的BeanNameGenerator，有的话就注册到容器的单例池，这个对象是用来给容器中的Bean生成名字的，Spring容器new出来的时候会默认生成一个，默认的命名策略就是类名小写，不过SpringApplication中的该对象默认是null的

然后看SpringApplication对象有没有自定义ResourceLoader，有的话就赋值给容器，这个我们之前也分析过，默认也是null的

最后一个if分支，addConversionService在SpringApplication对象的构造函数里就默认设置为true，所以会走if，它为容器设置了一个ConversonService，这个类是用来做类型转换的，比如String转Integer等等，其实在之前的文章中已经见过几次了

然后第三行applyInitializers

this.applyInitializers(context);

它取出了SpringApplication对象创建时，到META-INF/spring.factories中加载到的ApplicationContextInitializer列表，并依次调用其initialize方法

    protected void applyInitializers(ConfigurableApplicationContext context) {
        Iterator var2 = this.getInitializers().iterator();

        while(var2.hasNext()) {
            ApplicationContextInitializer initializer = (ApplicationContextInitializer)var2.next();
            Class<?> requiredType = GenericTypeResolver.resolveTypeArgument(initializer.getClass(), ApplicationContextInitializer.class);
            Assert.isInstanceOf(requiredType, context, "Unable to call initializer.");
            initializer.initialize(context);
        }

    }

这个在第一篇文章介绍过，一共加载到了6个实现类，本文先梳理prepareContext方法的脉络，至于这些内置的ApplicationContextInitializer做了哪些初始化，我们下篇文章再拎出来单独分析

继续往下，listeners.contextPrepared(context)方法

listeners.contextPrepared(context);

它通过事件发布器广播了一个事件ApplicationContextInitializedEvent，广播的流程跟之前的几个事件比如ApplicationStartingEvent是完全一致的，就不细看了，最后接收到该事件的监听者一共有两个，但是都没有做实际的处理，我们后续也可以再拉出来看一下，其实跟之前的事件分析流程完全一致的

	......
    public void contextPrepared(ConfigurableApplicationContext context) {
        this.initialMulticaster.multicastEvent(new ApplicationContextInitializedEvent(this.application, this.args, context));
    }
    ......

继续往下

    if (this.logStartupInfo) {
        this.logStartupInfo(context.getParent() == null);
        this.logStartupProfileInfo(context);
    }

这段代码判断当前容器是否有父容器，如果没有的话就认为是项目启动的根容器，会打印一行日志，包括启动类、当前的服务器名、项目路径、PID等

mainApplicationClass就是启动类，第一篇文章介绍过，在SpringApplication的构造方法中完成了启动类的推断

    protected void logStartupInfo(boolean isRoot) {
        if (isRoot) {
            (new StartupInfoLogger(this.mainApplicationClass)).logStarting(this.getApplicationLog());
        }
    }

然后根据日志级别输出日志

    public void logStarting(Log log) {
        Assert.notNull(log, "Log must not be null");
        if (log.isInfoEnabled()) {
            log.info(this.getStartupMessage());
        }

        if (log.isDebugEnabled()) {
            log.debug(this.getRunningMessage());
        }

    }

    private String getStartupMessage() {
        StringBuilder message = new StringBuilder();
        message.append("Starting ");
        message.append(this.getApplicationName());
        message.append(this.getVersion(this.sourceClass));
        message.append(this.getOn());
        message.append(this.getPid());
        message.append(this.getContext());
        return message.toString();
    }

实际输出的内容如下所示

[ INFO ] [2022-02-20 21:08:51] com.application.Application [50] - Starting Application on PC-20180310NEMF with PID 8644 (F:\git\emoticon-plus1\target\classes started by Administrator in F:\git\emoticon-plus1)

回到prepareContext方法，继续往下

ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
beanFactory.registerSingleton("springApplicationArguments", applicationArguments);
if (printedBanner != null) {
    beanFactory.registerSingleton("springBootBanner", printedBanner);
}

这几行代码将命令行参数和打印的banner对象作为一个单例Bean注册到容器中

继续往下走

if (beanFactory instanceof DefaultListableBeanFactory) {
    ((DefaultListableBeanFactory)beanFactory).setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
}

这行代码将SpringApplication对象中的allowBeanDefinitionOverriding属性设置到容器中，在第十篇文章中介绍过，SpringApplication通过Binder将该属性从environment中取出，设置到了自身的属性中

接下来看一个比较重要的load方法

Set<Object> sources = this.getAllSources();
Assert.notEmpty(sources, "Sources must not be empty");
this.load(context, sources.toArray(new Object[0]));

getAllSources获取的是SpringApplication对象的primarySources属性，而该属性在SpringApplication构造函数中赋了值，也就是我们的启动类
一般来说启动一个SpringBoot项目，会通过类似SpringApplication.run(xxx.class， args)的方式启动，比如

@SpringBootApplication
public class Application extends SpringBootServletInitializer {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

而run方法的参数Application.class，最终会封装到SpringApplication对象的primarySources属性中

进入load方法

    protected void load(ApplicationContext context, Object[] sources) {
        if (logger.isDebugEnabled()) {
            logger.debug("Loading source " + StringUtils.arrayToCommaDelimitedString(sources));
        }

        BeanDefinitionLoader loader = this.createBeanDefinitionLoader(this.getBeanDefinitionRegistry(context), sources);
        if (this.beanNameGenerator != null) {
            loader.setBeanNameGenerator(this.beanNameGenerator);
        }

        if (this.resourceLoader != null) {
            loader.setResourceLoader(this.resourceLoader);
        }

        if (this.environment != null) {
            loader.setEnvironment(this.environment);
        }

        loader.load();
    }

先通过createBeanDefinitionLoader方法创建一个BeanDefinitionLoader，它可以将一个类加载成BeanDefinition，第一个参数就是spring容器，第二个参数是我们的启动类

    protected BeanDefinitionLoader createBeanDefinitionLoader(BeanDefinitionRegistry registry, Object[] sources) {
        return new BeanDefinitionLoader(registry, sources);
    }

进入BeanDefinitionLoader构造方法的实现

    BeanDefinitionLoader(BeanDefinitionRegistry registry, Object... sources) {
        Assert.notNull(registry, "Registry must not be null");
        Assert.notEmpty(sources, "Sources must not be empty");
        this.sources = sources;
        this.annotatedReader = new AnnotatedBeanDefinitionReader(registry);
        this.xmlReader = new XmlBeanDefinitionReader(registry);
        if (this.isGroovyPresent()) {
            this.groovyReader = new GroovyBeanDefinitionReader(registry);
        }

        this.scanner = new ClassPathBeanDefinitionScanner(registry);
        this.scanner.addExcludeFilter(new BeanDefinitionLoader.ClassExcludeFilter(sources));
    }

在这个Loader的构造方法中，会创建一个AnnotatedBeanDefinitionReader对象，这个类在spring容器的构造函数中已经创建过一次了，这里没有直接使用spring容器的，而是又新建了一个，会重复走一遍Reader的构造流程，但是其中往spring容器注册bean的方法执行前都做了判空的校验，所以不会重复注册，类似如下代码

    if (!registry.containsBeanDefinition("org.springframework.context.annotation.internalAutowiredAnnotationProcessor")) {
        def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class);
        def.setSource(source);
        beanDefs.add(registerPostProcessor(registry, def, "org.springframework.context.annotation.internalAutowiredAnnotationProcessor"));
    }

回到load方法，接下来几个if分支都不会进，默认情况下SpringApplication中的beanNameGenerator、resourceLoader、environment都是null，注意我们真正使用的environment是在SpringApplication对象的run方法中创建的，并没有赋值给它自己的environment变量，所以这里依然是null

进入最后一行load方法

    public int load() {
        int count = 0;
        Object[] var2 = this.sources;
        int var3 = var2.length;

        for(int var4 = 0; var4 < var3; ++var4) {
            Object source = var2[var4];
            count += this.load(source);
        }

        return count;
    }

正常情况下启动类只有一个，继续跟进load方法

    private int load(Object source) {
        Assert.notNull(source, "Source must not be null");
        if (source instanceof Class) {
            return this.load((Class)source);
        } else if (source instanceof Resource) {
            return this.load((Resource)source);
        } else if (source instanceof Package) {
            return this.load((Package)source);
        } else if (source instanceof CharSequence) {
            return this.load((CharSequence)source);
        } else {
            throw new IllegalArgumentException("Invalid source type " + source.getClass());
        }
    }

我们启动类是class类型，走第一个分支

    private int load(Class<?> source) {
        if (this.isGroovyPresent() && BeanDefinitionLoader.GroovyBeanDefinitionSource.class.isAssignableFrom(source)) {
            BeanDefinitionLoader.GroovyBeanDefinitionSource loader = (BeanDefinitionLoader.GroovyBeanDefinitionSource)BeanUtils.instantiateClass(source, BeanDefinitionLoader.GroovyBeanDefinitionSource.class);
            this.load(loader);
        }

        if (this.isComponent(source)) {
            this.annotatedReader.register(new Class[]{source});
            return 1;
        } else {
            return 0;
        }
    }

groovy相关的判断可以先不去看

isComponent方法判断启动类上是否有@Component注解，启动类加了@SpringBootApplication注解，它是一个复合注解，内部包含了@SpringBootConfiguration

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(
    excludeFilters = {@Filter(
    type = FilterType.CUSTOM,
    classes = {TypeExcludeFilter.class}
), @Filter(
    type = FilterType.CUSTOM,
    classes = {AutoConfigurationExcludeFilter.class}
)}
)
public @interface SpringBootApplication {

而@SpringBootConfiguration又包含了@Configuration

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Configuration
public @interface SpringBootConfiguration {
}

@Configuration最终组合了@Component

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
    @AliasFor(
        annotation = Component.class
    )
    String value() default "";
}

所以这个分支成立，进入register方法

    public void register(Class... annotatedClasses) {
        Class[] var2 = annotatedClasses;
        int var3 = annotatedClasses.length;

        for(int var4 = 0; var4 < var3; ++var4) {
            Class<?> annotatedClass = var2[var4];
            this.registerBean(annotatedClass);
        }

    }

registerBean调用doRegisterBean

    public void registerBean(Class<?> annotatedClass) {
        this.doRegisterBean(annotatedClass, (Supplier)null, (String)null, (Class[])null);
    }

最终将我们的启动类转化为BeanDefinition注册到spring容器的BeanDefinitionMap中，后续会以此为起点，开始扫描项目中的Controller、Service等等注册到容器中

    <T> void doRegisterBean(Class<T> annotatedClass, @Nullable Supplier<T> instanceSupplier, @Nullable String name, @Nullable Class<? extends Annotation>[] qualifiers, BeanDefinitionCustomizer... definitionCustomizers) {
        AnnotatedGenericBeanDefinition abd = new AnnotatedGenericBeanDefinition(annotatedClass);
        if (!this.conditionEvaluator.shouldSkip(abd.getMetadata())) {
            abd.setInstanceSupplier(instanceSupplier);
            ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(abd);
            abd.setScope(scopeMetadata.getScopeName());
            String beanName = name != null ? name : this.beanNameGenerator.generateBeanName(abd, this.registry);
            AnnotationConfigUtils.processCommonDefinitionAnnotations(abd);
            int var10;
            int var11;
            if (qualifiers != null) {
                Class[] var9 = qualifiers;
                var10 = qualifiers.length;

                for(var11 = 0; var11 < var10; ++var11) {
                    Class<? extends Annotation> qualifier = var9[var11];
                    if (Primary.class == qualifier) {
                        abd.setPrimary(true);
                    } else if (Lazy.class == qualifier) {
                        abd.setLazyInit(true);
                    } else {
                        abd.addQualifier(new AutowireCandidateQualifier(qualifier));
                    }
                }
            }

            BeanDefinitionCustomizer[] var13 = definitionCustomizers;
            var10 = definitionCustomizers.length;

            for(var11 = 0; var11 < var10; ++var11) {
                BeanDefinitionCustomizer customizer = var13[var11];
                customizer.customize(abd);
            }

            BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(abd, beanName);
            definitionHolder = AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
            BeanDefinitionReaderUtils.registerBeanDefinition(definitionHolder, this.registry);
        }
    }

执行完毕后，可以看到Spring容器的BeanDefinitionMap中，已经添加了我们的启动类，而前面几个类都是在new容器的时候，内部AnnotatedBeanDefinitionReader初始化的过程中注册到容器里的

回到prepareContext方法，看最后一行代码listeners.contextLoaded(context)

    listeners.contextLoaded(context);

    public void contextLoaded(ConfigurableApplicationContext context) {
        Iterator var2 = this.listeners.iterator();

        while(var2.hasNext()) {
            SpringApplicationRunListener listener = (SpringApplicationRunListener)var2.next();
            listener.contextLoaded(context);
        }

    }

跟之前的事件发布机制一样，最终调用了EventPublishingRunListener的contextLoaded方法

    public void contextLoaded(ConfigurableApplicationContext context) {
        ApplicationListener listener;
        for(Iterator var2 = this.application.getListeners().iterator(); var2.hasNext(); context.addApplicationListener(listener)) {
            listener = (ApplicationListener)var2.next();
            if (listener instanceof ApplicationContextAware) {
                ((ApplicationContextAware)listener).setApplicationContext(context);
            }
        }

        this.initialMulticaster.multicastEvent(new ApplicationPreparedEvent(this.application, this.args, context));
    }

这个for循环，遍历了SpringApplication对象所有的监听器，也就是最开始创建SpringApplication的时候，从META-INF/spring.factories中加载到的ApplicationListener，在循环中，判断Listener是否实现了ApplicationContextAware接口，如果是的话就把Spring容器赋给他

这个Aware的回调本来也是在Spring容器refresh的过程执行的，但是由于这里的监听器可能仅仅是存储在容器的一个列表属性里，而并不会注册到容器中，也就不会作为Bean管理起来，后续就没办法真正在spring容器的refresh过程以正常的方式触发回调，所以就在这里手动赋值了

然后在for循环的最后一个条件里，将其添加到spring容器的监听器列表，我们之前有提到过，容器启动后，事件发布的职能会转交给容器进行，而这里正是重要的一步，将内置的监听器列表交给了容器，有了监听器列表， 自然可以向它们广播事件了

最后发布事件ApplicationPreparedEvent，发布流程跟之前一样，最终感兴趣的监听器有四个，可以后面的文章再补充分析

    public void contextLoaded(ConfigurableApplicationContext context) {
        ApplicationListener listener;
        for(Iterator var2 = this.application.getListeners().iterator(); var2.hasNext(); context.addApplicationListener(listener)) {
            listener = (ApplicationListener)var2.next();
            if (listener instanceof ApplicationContextAware) {
                ((ApplicationContextAware)listener).setApplicationContext(context);
            }
        }

        this.initialMulticaster.multicastEvent(new ApplicationPreparedEvent(this.application, this.args, context));
    }