153行，this.prepareContext(context, environment, listeners, applicationArguments, printedBanner)
对context做一些准备操作
前面提到在默认创建ApplicationContext时也会加载一份Environment，通过202行可以看到直接替换掉了，替换成了前面分析过的148行创建ConfigurableEnvironment对象，因为在148行和后面的一些操作中已经得到了容器的运行环境下所有配置，所以直接把它放入context中就好
203行postProcessApplicationContext方法，该方法往context的beanFactory中放入beanNameGenerator、conversionService，一个是beanName生成器，比如通过类名生成beanName的方法，后面才能根据beanName找到被容器管理的对象，一个是转换器，在beanFactory中的作用暂时不清楚，先留个坑，另外还会往context中放入resourceLoader，资源加载器，这些东西的详细作用在后面的分析中应该会涉及到。在默认情况下，postProcessApplicationContext方法只给context的beanFactory放入了conversionService
204行applyInitializers方法，请求初始化操作，这个阶段默认有6个初始化器
第一个DelegatingApplicationContextInitializer会找配置的context.initializer.classes属性配置的初始化类，对context进行初始化，demo如下
启动后会进入CustomInitializer进行初始化
第二个SharedMetadataReaderFactoryContextInitializer，会给容器中加入一个BeanFactoryPostProcessor，它是生成beanFactory对象的后置操作，对这个类不熟悉的话可以类比一下BeanPostProcessor
默认加入的是CachingMetadataReaderFactoryPostProcessor对象
这里可以简单分析出它会对之后在applicationContext中生成的beanFactory做后置操作，也就是生成beanFactory对象后，进入BeanFactoryPostProcessor的postProcessBeanFactory方法，从上面截图看出没有做任何事情。这个类要做的事情是另外一个继承自BeanDefinitionRegistryPostProcessor接口的postProcessBeanDefinitionRegistry方法，要理解这里，需要先理解一下BeanDefinitionRegistry是干什么的，另外在这里默认配置的BeanDefinition又是什么，Q8？
第三个ContextIdApplicationContextInitializer，它会给容器设置id，通过读取spring.application.name配置获取然后生成contextId对象，如果没配置，设置默认id，另外把cotextId对象也放进容器
第四个ConfigurationWarningsApplicationContextInitializer，它跟第二个类似，也是BeanDefinitionRegistryPostProcessor的实现类，后面先把Q8的问题研究好就行，这个类看名字也能理解，应该是容器配置异常警告
第五个ServerPortInfoApplicationContextInitializer，给applicationContext加入了一个监听器，也就是它自己，它的作用是给environment里添加名为server.ports的source，然后在它里面放入默认名为local.server.port的参数，平常太少接触到了，如果后面有碰到再进行分析
第六个ConditionEvaluationReportLoggingListener，它也是为了加入监听器ConditionEvaluationReportListener，监听器最终会执行判断是否打印日志的一些操作，结合类名，状态评估报告，即它应该是评估容器启动状态的一个打印日志操作，默认是只打印当容器启动错误时的一个日志的，通过阅读源码，写一个配置来控制让它打印
首先可以看到默认是生成org.apache.logging.log4j.spi.ExtendedLogger的日志对象，之后发现通过logback.xml配置文件可以修改日志配置，目前不打印的原因是因为日志级别默认为INFO，需要设置成DEBUG级别打印
205行listeners.contextPrepared，还是发送监听事件，这个阶段没有默认做什么特别的事情
206-209行，打印启动信息和加载到的activeprofile
211行得到容器中当前的beanFactory对象
212行把由入参args封装的ApplicationArguments对象交给beanFactory管理
213-215行把打印banner的PrintBanner对象交给beanFactory管理
217-219行，如果beanFactory是DefaultListableBeanFactory对象，设置它的allowBeanDefinitionOverriding属性，该属性的作用碰到再分析
221行，得到所有的source，不知道用来干嘛的，但可以看到它把入口run方法里的第一个参数包装成的primarySources放进了sources集合，这还是Q1的问题
223行，创建BeanDefinitionLoader并加载，BeanDefinitionLoader用于从source加载Bean的定义信息，并封装成BeanDefinition对象，注册到ApplicationContext中，它有提供了多种加载方式，springboot启动到这里，默认加载了入参的第一个参数的类，即
它会把SpringbootDemoApplication.class构造成BeanDefination放入context容器，有一个前提条件是它要有@Component注解，而启动类上@SpringBootApplication就是包含@Component的组合注解，可以试着验证一下
首先直接去掉@SpringBootApplication注解，启动后报错如图
单独加@Component注解，报错一样，看不出区别，可以启动时在如下图处debug看到区别，也就是被Component注解时，启动类class已经被构造成BeanDefination放入容器，只不过还需要别的东西才导致了报错
如果想用@SpringBootApplication去注解其它的类，可以如下两种方式去做
首先创建一个被@SpringBootApplication注解的类SpringbootDemoApp
现在大致可以了解到一点BeanDefination的作用了，它是收集bean定义信息，不管直接是类.class，还是xml配置的，甚至是一串字符串，在正确的情况下都能被构造成BeanDefination，之后容器就可以根据这些来构造bean，具体怎样构造bean的还得往后看
224行，依然是发送监听事件，listeners.contextLoaded，默认listener列表中满足条件的是ParentContextCloserApplicationListener，这时做的操作也很简单，给listener对象中放入容器context，应该是为了之后的监听操作
接下来再回到run启动方法的主流程
154行，this.refreshContext(context)，调用的核心方法为AbstractApplicationContext提供的refresh方法
仔细分析一下这个方法
首先260行this.prepareRefresh方法，给容器的startupDate赋值，即启动时间。然后this.initPropertySources()初始化propertySources，可以看到在当前类中实现方法为空，即不做任何事情，断点调试下去会发现子类中有具体实现，最终想做的是填充Environment中相关propertySources。接下来this.getEnvironment().validateRequiredProperties()，这个方法是使用environment中propertyResolver去校验系统必须的属性，如果不存在，会报异常，默认情况下到当前是没有需校验的属性的，但是可以理解到它可以用来做什么，比如项目中有@Value("${name}")注解的属性，可是配置里没有name，启动后会报错的，至于最终实际会在哪里校验到，后面的流程中应该会体现
261行，给容器的refreshed赋值true，给beanFactory对象的serializationId赋值容器id（容器id前面分析过由ContextIdApplicationContextInitializer初始化），最后得到已经在context容器中的beanFactory对象
262行，应该是给beanFactory做一些准备操作，里面有挺多关键的东西，一个个分析吧
315行设置bean的类加载器
316行设置bean的表达式解析器，创建的是SpelExpressionParser解析器，使用过的话应该知道它是干什么的，这里再来一个demo方便理解它的一些作用
这只是SpelExpressionParser的其中一项功能，它的功能很强大，以后可以研究研究
317行添加属性编辑注册propertyEditorRegistrar，最终是调用它的方法进行属性编辑，太抽象了，还是结合demo
前面有介绍过spring会配置属性转换conversionService，大部分情况下的从配置转换成属性都是没问题的，下面尝试一下转换日期的操作
配置文件里肯定是配置字符串的，字符串要转换成日期，需要特定格式，conversionService支持yyyy/MM/dd的转换，如下图
如果日期配置成了如下形式，则会报错
这时属性编辑就能起作用了，spring提供了CustomEditorConfigurer来配置自定义的属性编辑器
CustomEditorConfigurer生效的原因是它是一个BeanFactoryPostProcessor，这在即将分析的流程里会体现，这样配置之后，beanFactory中就会存在两个propertyEditorRegistrar，两个都失败才可能报错，此时再启动项目会发现不会报错了，而且testDate属性被正确读取
318行，加了一个ApplicationContextAwareProcessor进beanPostProcessor链，BeanPostProcessor是生成bean对象的后置操作，打开源码可以看到一些很熟悉的东西
最熟悉的应该是ApplicationContextAware和EmbeddedValueResolverAware了，它们就是通过ApplicationContextAwareProcessor放入对象的
319-324行，忽略接口的所有实现类，作用就是使得它们的实现类不能自动调用接口中同样的方法去注入属性(在自动注入的时候，比如default-autowire为byType或byName)，比如这里忽略了ApplicationContextAware.class，目的应该是为了保证实现类中applicationContext属性，是由318行分析到的方式注入的，不会被自动注入影响。springboot不包含加载xml的bean配置时暂时没找到配置default-autowire入口，好像也没有，感兴趣的可以写一个基于spring xml配置的demo
325-328行，给beanFactory的resolvableDependencies放入键值对，放入了四个键BeanFactory.class、ResourceLoader.class、ApplicationEventPublisher.class、ApplicationContext.class，resolvableDependencies应该也是有什么作用的，后面分析
329行加入一个ApplicationListenerDetector的beanPostProcessor，它实现了postProcessAfterInitialization方法，也就是spring在生成bean后，会走这里，它处理ApplicationListener的实现类生成的bean，如果是单例bean，把它加入到applicationContext的applicationListener中
330-333行，如果存在名为loadTimeWeaver的bean，再加一个处理对应bean的beanPostProcessor，这个应该不常用
之后的逻辑就是给beanFactory中放入名为environment、systemProperties、systemEnvironment的bean
回到refresh方法
先明确一个事情，默认生成的ApplicationContext对象前面分析过是生成的AnnotationConfigServletWebServerApplicationContext对象
265行，this.postProcessBeanFactory(beanFactory)
首先加入WebApplicationContextServletContextAwareProcessor的beanPostProcessor，可以看到它想给ServletContextAware和ServletConfigAware的bean放入被容器管理的servletContext和servletConfig
接下来扫描basePackages里的类和指定的class类生成bean放入容器，默认都是空的
这里可以做个demo来理解，需要用到前面做过的一个demo，对容器初始化
在这里给容器放入basePackages和annotatedClasses
启动后，访问该接口，会正确打印
如果在CustomInitializer中不用scan和register加入对应需要注入的信息，启动会报错，可以知道AnnotatedBeanDefinitionReader就是读取class获取BeanDefinition，ClassPathBeanDefinitionScanner就是通过扫描包路径来获取BeanDefinition，最终通过它来生成bean
