Springboot启动流程分析（四）：完成启动流程
目录
一 添加BeanPostProcessors到IOC容器
二 国际化支持
三 初始化监听器的多路播放器
四 刷新容器
五 注册监听器到IOC容器的多播器
六 完成bean的大规模实例化
6.1 大规模实例化bean
6.1.1 连续三层do...while循环作用
6.1.2 FactoryBean是什么？为什么要执行2次getBean方法？
七 完成IOC刷新
八 完成IOC刷新
九 结束Springboot启动流程
十 总结
在Springboot的启动过程中，当执行到
AbstractApplicationContext
的refresh方法时，当执行完方法：
this.invokeBeanFactoryPostProcessors(beanFactory);
一 添加BeanPostProcessors到IOC容器
在执行完所有的BeanFactoryPostProcessors指定方法之后。下一步，会把BeanPostProcessors，也就是beanFacotry中已经注册过bean定义信息的，所有bean的后置处理器，都加入到beanFacotry的集合属性——beanPostProcessors中。
其具体执行方法为：
this.registerBeanPostProcessors(beanFactory);接着再调用 ：
ostProcessorRegistrationDelegate.registerBeanPostProcessors(beanFactory, this);开始执行真正的bean后置处理器加载步骤。
其核心步骤，就是通过beanFactory的getBeanNamesForType方法，去beanFacotry的属性——beanDefinitionNames集合中，筛选出实现了BeanPostProcessors接口的所有beanNames，返回一个String数组：
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanPostProcessor.class, true, false);至此，相当于大概获取了beanFacroty中的全部bean的后置处理器的beanName信息了。
为什么说是大概呢？因为接下来，还需要手动加入一个bean的后置处理器——BeanPostProcessorChecker：
int beanProcessorTargetCount = beanFactory.getBeanPostProcessorCount() + 1 + postProcessorNames.length;
beanFactory.addBeanPostProcessor(new PostProcessorRegistrationDelegate.BeanPostProcessorChecker(beanFactory, beanProcessorTargetCount));顾名思义，应该是对bean的后置处理器进行一些统计和检查。
接下来，就是把获取到的postProcessorNames根据属性进行分类，并根据分类的顺序，依次添加到beanFactory的集合属性——beanPostProcessors中。
其分类和添加到beanPostProcessors集合的顺序依次为：
priorityOrderedPostProcessors集合、 orderedPostProcessorNames集合、 nonOrderedPostProcessorNames集合、 internalPostProcessors集合
其主要是通过接口PriorityOrdered、Ordered、MergedBeanDefinitionPostProcessor来判断应该把后置处理器放入哪个集合中。
在最后，还需要添加一个指定后置处理器：
beanFactory.addBeanPostProcessor(new ApplicationListenerDetector(applicationContext));其实这个执行过程和上一篇文章，beanFacotry后置处理器的过程有很多相似之处，但是相对来说又简单了很多。
二 国际化支持
this.initMessageSource();国际化的源码其实更简单，就是看容器中是否有名为messageSource的bean实例，如果有则直接赋值给AbstractApplicationContext中messageSource的属性。
如果找不到，则通过DelegatingMessageSource实例化一个messageSource实例，放入容器中。
这意味着，我们可以通过配置类，自定义一个messageSource实例：
@Configuration
public class MessageConfig {@Bean(name = "messageSource")public MessageSource getMessageSource() {ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();messageSource.setDefaultEncoding("GBK");messageSource.addBasenames("message");return messageSource;}
}其具体用法为：
@Overridepublic void run(String... args) throws Exception {String message = messageSource.getMessage("user.name", null, null, Locale.ENGLISH);String messageCn = messageSource.getMessage("user.name", null, null, Locale.CHINA);System.out.println(message);System.out.println(messageCn);System.out.println("完成国际化测试");}其实就是对resource文件夹下面properties文件的一次封装：
三 初始化监听器的多路播放器
this.initApplicationEventMulticaster();单看代码这个其实也很简单，就是判断IOC容器中是否有applicationEventMulticaster这个实例，如果有，赋值给当前类AbstractApplicationContext的属性——applicationEventMulticaster。如果没有，就new一个多播器实例——SimpleApplicationEventMulticaster，赋值后，再注入到容器中。
protected void initApplicationEventMulticaster() {ConfigurableListableBeanFactory beanFactory = this.getBeanFactory();if (beanFactory.containsLocalBean("applicationEventMulticaster")) {this.applicationEventMulticaster = (ApplicationEventMulticaster)beanFactory.getBean("applicationEventMulticaster", ApplicationEventMulticaster.class);......} else {this.applicationEventMulticaster = new SimpleApplicationEventMulticaster(beanFactory);beanFactory.registerSingleton("applicationEventMulticaster", this.applicationEventMulticaster);......这里需要注意的是，这里的多播器其实就是前面Springboot启动类——SpringApplication的run方法中监听器所使用的多播器，只不过前面利用EventPublishingRunListener类包装了一层，同样也是把SimpleApplicationEventMulticaster作为属性放入到了EventPublishingRunListener中：
public class EventPublishingRunListener implements SpringApplicationRunListener, Ordered {private final SpringApplication application;private final String[] args;private final SimpleApplicationEventMulticaster initialMulticaster;public EventPublishingRunListener(SpringApplication application, String[] args) {this.application = application;this.args = args;this.initialMulticaster = new SimpleApplicationEventMulticaster();Iterator var3 = application.getListeners().iterator();while(var3.hasNext()) {ApplicationListener<?> listener = (ApplicationListener)var3.next();this.initialMulticaster.addApplicationListener(listener);}}唯一的不同就是EventPublishingRunListener在Springboot启动结束之后，如果不再被引用，会被垃圾回收器回收，但是容器中beanName为applicationEventMulticaster的实例会一直存在，可以在项目启动后，在任意时候从容器中获取。
四 刷新容器
this.onRefresh();第一部分是针对SpringMVC层面的主题控制，现在项目通常使用前后端分离，所以用处不大。
其提供的自定义功能，也主要是通过自定义beanName——themeSource来实现：
public static ThemeSource initThemeSource(ApplicationContext context) {if (context.containsLocalBean("themeSource")) {ThemeSource themeSource = (ThemeSource)context.getBean("themeSource", ThemeSource.class);......但是这一步，还有一个最重要的功能，会启动Spring内置的tomcat容器，并通过while(true)的形式，来接收所有的Servlet请求。
五 注册监听器到IOC容器的多播器
this.registerListeners();这里的监听器分为两块：
//启动过程中加入的监听器
Iterator var1 = this.getApplicationListeners().iterator();while(var1.hasNext()) {ApplicationListener<?> listener = (ApplicationListener)var1.next();//以监听器的方式加入多播器this.getApplicationEventMulticaster().addApplicationListener(listener);}//实现接口ApplicationListener的监听器，多用于自定义监听器String[] listenerBeanNames = this.getBeanNamesForType(ApplicationListener.class, true, false);String[] var7 = listenerBeanNames;int var3 = listenerBeanNames.length;for(int var4 = 0; var4 < var3; ++var4) {String listenerBeanName = var7[var4];//以beanName的方式加入多播器 this.getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);}一块是SpringApplication在执行run方法的过程中，不断加入IOC容器中的监听器，相当于系统自带监听器（也可以自定义），另一块是需要从IOC中获取实现了接口ApplicationListener的监听器，我们如果要实现自定义的监听器，可以直接实现这个接口，然后把监听器注入IOC容器，就可以被IOC的多播器来执行了：
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {void onApplicationEvent(E var1);
}注意只是加入了IOC容器，而监听器是要依靠IOC多播器去实现的，由于前面才刚把IOC自己的多播器实例化，所以此时也才能往多播器中添加监听器。
在加入两种类型的监听器以后，利用IOC的多播器执行一个指定集合——earlyApplicationEvents中的所有监听器方法：
Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;this.earlyApplicationEvents = null;if (earlyEventsToProcess != null) {Iterator var9 = earlyEventsToProcess.iterator();while(var9.hasNext()) {ApplicationEvent earlyEvent = (ApplicationEvent)var9.next();this.getApplicationEventMulticaster().multicastEvent(earlyEvent);}六 完成bean的大规模实例化
this.finishBeanFactoryInitialization(beanFactory);在开始bean的大规模实例化之前，还需要做几个准备工作。
首先设置IOC中的类型转换器——ConversionService：
if (beanFactory.containsBean("conversionService") && beanFactory.isTypeMatch("conversionService", ConversionService.class)) {beanFactory.setConversionService((ConversionService)beanFactory.getBean("conversionService", ConversionService.class));
}再判断容器中是否有配置文件解析器，如果没有，利用Environment的文件解析器：
if (!beanFactory.hasEmbeddedValueResolver()) {beanFactory.addEmbeddedValueResolver((strVal) -> {return this.getEnvironment().resolvePlaceholders(strVal);});
}实例化接口——LoadTimeWeaverAware的实现类：
String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
String[] var3 = weaverAwareNames;
int var4 = weaverAwareNames.length;for(int var5 = 0; var5 < var4; ++var5) {String weaverAwareName = var3[var5];this.getBean(weaverAwareName);
}释放类加载器——tempClassLoader：
beanFactory.setTempClassLoader((ClassLoader)null);冻结容器中的所有bean定义信息，不允许有新的bean定义信息注册进来，为大规模实例化bean做准备：
beanFactory.freezeConfiguration();6.1 大规模实例化bean
beanFactory.preInstantiateSingletons();由于preInstantiateSingletons这个方法写的实在是有点难以理解，所以这部分代码需要从整体层面来理解，这样就不至于过于纠结细节，以至于完全无法抓住重点。
首先，我们看下这个方法的大概结构：
可以看到，其主要功能就是获取所有的bean定义信息，构造成一个List，之后用while(true)的形式，无限循环，用以实例化完所有需要实例化的bean，这是这个方法的本质功能。
那么什么时候跳出循环呢？
让我们忽略掉那一层套一层的do...while循环，可以发现在bean定义信息的List迭代完成以后，就会以return的方式，直接结束此次方法的调用。
这样我们就大概理解了这个方法的作用，和退出方法的时机。
再看一下迭代器具体做了什么？
如果当前beanName对于的bean实例是SmartInitializingSingleton的实现类，则执行其指定的接口方法afterSingletonsInstantiated。
到这一步，又出现更让人迷惑的一个嵌套，第二个while(true)循环是干嘛的？什么时候退出？
依旧是需要忽略一些无关的细节，从整体来看：
可以看到，第二个while(true)循环，跳出的时机是当beanName是FactoryBean的时候，需要跳出当前的while循环，同时也可以看出，如果不是FactoryBean，会直接进行实例化，然后进入当前while(true)循环中的下一次do...while循环，也就是一直进行普通bean的实例化，直到出现FactoryBean，跳出当前while(true)循环。
跳出去之后呢？别急，外面还有一层while(true)循环等着，此时再结合最外层do...while循环中的条件：
} while(!(bean instanceof FactoryBean));这样do...while方法也跳出去了，FactoryBean类型的bean进入到了最外层while(true)方法的下半部分执行逻辑：
可以看到，主要是判断当前bean的实例是否是SmartFactoryBean，以及根据它的属性isEagerInit的值，判断是否需要马上实例化beanName。
至此，preInstantiateSingletons方法的大概逻辑就梳理完了，但是有产生了一些新的问题。
第一个问题，这个方法中，除了刚才介绍的最外层的do...while循环，在第二层的while(true)循环里面，那3层do...while又分别是做什么的？
第二个问题，为什么FactoryBean的实例，在前半部分代码中执行了getBean以后，下面如果其isEagerInit属性是true，还要getBean一次，这又是为什么？
6.1.1 连续三层do...while循环作用
先从最外层循环开始，首先会执行最外层do块，什么都不做，进入第二层do块，也什么都没做。
进入第三层do块，获取下一个beanName的bean定义信息，在最内层do块执行完以后，如果当前bean是一个抽象类，继续执行当前最内层do...while循环，获取下一个bean定义信息，如果当前bean不是一个抽象类，跳出最内层do...while。
执行第二层do...while，嗯，这一层什么都没做，接着判断，如果当前bean定义信息不是一个单例模式(是多态或者其他模式)，继续执行最内层do...while循环，获取下一个bean定义信息，此时如果当前bean不是一个抽象类，且是单例模式，才能跳出第二层do...while循环，否则就一直在二三层do...while循环之间，抽取下一个bean定义信息，直到beanName的list中所有的信息都被迭代完，才会结束此方法。
如果bean的定义信息既不是抽象类，又是一个单例，那么会跳到第一层do...while方法，再判断如果bean的定义信息不是懒加载的方式，会跳出当前的do...while方法，也就是跳出所有的三层do...while，进入下一步。
否则，就又重新进入第二层do...while，重复上面的方法，获取下一条bean定义信息，直到一个bean既不是抽象类，又是单例，且不是懒加载的定义，才能跳出所有三层do...while循环。
6.1.2 FactoryBean是什么？为什么要执行2次getBean方法？
什么是FactoryBean
FactoryBean又叫做工厂Bean，指用于生产bean的工厂。
这样说还是有点抽象，通过例子来说明，先看一下FactoryBean的接口信息：
public interface FactoryBean<T> {String OBJECT_TYPE_ATTRIBUTE = "factoryBeanObjectType";@NullableT getObject() throws Exception;@NullableClass<?> getObjectType();default boolean isSingleton() {return true;}
}
可以看到，默认是单例，FactoryBean和我们获取普通的bean的区别在于，需要通过getObject方法来获取真正的bean实例。
这也是为什么在方法preInstantiateSingletons中，需要通过两次getBean方法，才能真正获取到FactoryBean类型的实例的原因。
举个例子：
@Component
public class TestFactoryBean implements SmartFactoryBean {@Overridepublic Object getObject() throws Exception {return new Person();}@Overridepublic Class<?> getObjectType() {return null;}@Overridepublic boolean isEagerInit() {return true;}
}
在Spring容器中，会存在两个实例，一个是通过getBean("&testFactoryBean")，生成的TestFactoryBean实例，一个是通过getBean("testFactoryBean")，生成的Person实例，其实就是通过TestFactoryBean实例的getObject方法，生成的Person实例。
这也是为什么如果当前bean定义不是懒加载的化，FactoryBean需要通过两次getBean方法生成的原因。
七 完成IOC刷新
this.finishRefresh();protected void finishRefresh() {//清楚资源缓存this.clearResourceCaches();//初始化生命周期处理器this.initLifecycleProcessor();//执行生命周期处理器onRefresh方法this.getLifecycleProcessor().onRefresh();//发布容器已刷新监听事件this.publishEvent((ApplicationEvent)(new ContextRefreshedEvent(this)));//把当前ioc容器加入集合————applicationContextsLiveBeansView.registerApplicationContext(this);
}至此在AbstractApplicationContext类中，已经执行完了refresh方法中的所有步骤。
八 完成IOC刷新
在AbstractApplicationContext完成ioc容器刷新后，需要回到类SpringApplication中，继续执行其run方法，接着执行如下方法：
this.afterRefresh(context, applicationArguments);由于这是一个抽象方法，且没有继承类，略过。
九 结束Springboot启动流程
//stopWatch记录结束stopWatch.stop();if (this.logStartupInfo) {(new StartupInfoLogger(this.mainApplicationClass)).logStarted(this.getApplicationLog(), stopWatch);}//容器启动完成监听器方法执行listeners.started(context);//容器启动后，执行一系列指定Runnersthis.callRunners(context, applicationArguments);
} catch (Throwable var10) {this.handleRunFailure(context, var10, exceptionReporters, listeners);throw new IllegalStateException(var10);
}try {//容器正在运行监听器方法执行listeners.running(context);//返回IOC容器，结束方法return context;这里需要注意的是
this.callRunners(context, applicationArguments);
其实就是执行容器中所有的ApplicationRunner和CommandLineRunner类型的run方法，其效果和bean实例化过程中的initializeBean方法中执行接口InitializingBean的afterPropertiesSet，是一样的。
但是其底层的原理完全不一样，一个是bean的实例化过程中执行的，一个是IOC容器启动完成以后回调执行的：
private void callRunners(ApplicationContext context, ApplicationArguments args) {List<Object> runners = new ArrayList();runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());AnnotationAwareOrderComparator.sort(runners);Iterator var4 = (new LinkedHashSet(runners)).iterator();while(var4.hasNext()) {Object runner = var4.next();if (runner instanceof ApplicationRunner) {this.callRunner((ApplicationRunner)runner, args);}if (runner instanceof CommandLineRunner) {this.callRunner((CommandLineRunner)runner, args);}}}十 总结
至此，我们通过四篇文章，十万余字的代码和文字说明，大概完成了Springboot的全部启动流程，完整而全面的分析了Springboot的全流程。
但是在完成的过程中，深感对一些核心知识点的介绍还不够深入，后续会以单点的形式对Springboot启动过程中的一些知识点进行针对性梳理，以便能够更好的理解Spring框架。
Springboot启动流程分析（四）：完成启动流程相关推荐
- Framework 窗口添加流程分析2之 addWindow 流程
Framework 窗口添加流程分析2之 addWindow 流程 以下是 WindowManagerService.addWindow() 方法的一些大致流程: 添加窗口的权限检查 Display. ...
- Android 源码 Camera2 预览流程分析四
<Android 源码 Camera2 预览流程分析二>中进行了流启动,这是调用 QCamera3Channel start() 方法实现的,对应于 HAL_PIXEL_FORMAT_YC ...
- 内核启动流程分析(四)源码浅析
目录 kernel(四)源码浅析 建立工程 启动简析 head.s 入口点 查询处理器 查询机器ID 启动MMU 其他操作 start_kernel 处理命令行 分区 kernel(四)源码浅析 建立 ...
- 韦东山衔接班——3.4_linux内核启动流程分析之内核启动
作者:GWD 时间:2018.8.25 一.汇编部分到第一个C之前准备 1.问:内核的工作 答 2.问:为什么有两个head.S 答:其中一个是自解压代码,运行时先解压内核 3.uboot中将参数写入 ...
- Android 8.1 PowerManagerService分析(四)——亮屏流程分析
欢迎大家关注我的掘金帐号 我会在那里定期更新最新版本的Android Framework源码分析! 相关文章: [Android Framework] 8.1 PowerManagerService分 ...
- Android 蓝牙 搜索周围设备代码流程分析-framework到协议栈流程
本文详细的将Android 蓝牙扫描周围设备流程进行了梳理,从UI开始扫描到协议栈发送扫描命令到controller,进行了源码分析. 更多源码分析: android-蓝牙A2dp-avrcp-hfp ...
- 解析并符号 读取dll_Spring IOC容器之XmlBeanFactory启动流程分析和源码解析
一. 前言 Spring容器主要分为两类BeanFactory和ApplicationContext,后者是基于前者的功能扩展,也就是一个基础容器和一个高级容器的区别.本篇就以BeanFactory基 ...
- Android 5.1 Lollipop Phone工作流程浅析(十三)__InCallActivity启动Performance浅析
前置文章: < Android 4.4 Kitkat Phone工作流程浅析(一)__概要和学习计划> <Android 4.4 Kitkat Phone工作流程浅析(二)__UI结 ...
- 高通Android智能平台环境搭建_编译流程分析
高通Android智能平台环境搭建_编译流程分析 高通平台环境搭建,编译,系统引导流程分析 TOC \o \h \z \u 1. 高通平台android开发总结. 7 1.1 搭建高通平台环境开发环境 ...
- 高通平台环境搭建，编译，系统引导流程分析 .
1.高通平台android开发总结 1.1 搭建高通平台环境开发环境 在高通开发板上烧录文件系统 建立高通平台开发环境 高通平台,android和 modem 编译流程分析 高通平台 7620 启动流 ...
最新文章
- 形势说变就变！机器学习工程师恐在十年内消失？
- SimpleDateFormat使用详解 转
- 【Android】17.2 Activity与Local Service的绑定
- 数组元素前移后移 RUNOOB python练习题 68
- 计算机二级必备快捷键知识,计算机二级考试中的一些注意事项️
- 用计算机计算麦克斯韦方程,数学之美~（01）最伟大的数学公式！
- Java学习日报—注解、Hash、Lombok—2021/12/02
- 中兴网信“智慧旅游”亮相2016国际孔子文化节
- linux下rocksdb的编译安装
- 只十分钟，唾手可得的工作机会就被我搞砸了！
- macos 字体_巧用 iTerm2 zsh oh-my-zsh 打造炫酷的 MacOS 终端环境
- junit搭配hamcrest使用
- 新能源车企骗补终结：实力说话淘汰赛开启
- 开滦二中2021高考成绩查询,成人成才 无缝严管丨开滦二中西校区2018高考总结交流大会...
- 计算机网络实验四：路由器接口及静态路由配置
- linux下code-server离线远程web浏览器调试C++代码
- 使用Python编程出高级计算器，支持加减乘除、复合运算、三角函数、平方根、二进制转换、幂运算等高阶运算
- 快手市值万亿、炒股如同炒币，资本市场正在币圈化？
- 第11章 AOP应用案例
- Linux应用开发3 字符串处理，字符串与其他数字类型的转换，向应用程序传参