前言
上一节中简要说明了下springboot自动化配置的关键，那么本节看下springboot真正的初始化过程，如何创建上下文并解析配置，加载我们注册到容器管理中的类。上节已经成功的创建了SpringApplication，那我们就看下其run方法究竟做了些什么
正文
我们从SpringApplication的run方法开始入手，只看核心代码，其他省略
public ConfigurableApplicationContext run(String... args) { ...//省略代码 //声明spring上下文 ConfigurableApplicationContext context = null; try { ..//省略代码 //2.新建应用上下文 context = createApplicationContext(); ..//省略代码 //3.刷新上下文 refreshContext(context); //4.完成刷新上下文后调用(目前空白) afterRefresh(context, applicationArguments); ..//省略代码 } return context; }
通过上面我们可以发现，run方法核心步骤就是创建ApplicatonContext，这儿主要的步骤有两个 1.创建应用上下文 2.刷新上下文。我们从创建开始看
1.创建spring的核心 ApplicationContext
查看createApplicationContext方法
public static final String DEFAULT_WEB_CONTEXT_CLASS = "org.springframework.boot." + "web.servlet.context.AnnotationConfigServletWebServerApplicationContext"; protected ConfigurableApplicationContext createApplicationContext() { Class<?> contextClass = this.applicationContextClass; if (contextClass == null) { try { switch (this.webApplicationType) { case SERVLET: //我们使用这个 contextClass = Class.forName(DEFAULT_WEB_CONTEXT_CLASS); break; case REACTIVE: contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS); break; default: contextClass = Class.forName(DEFAULT_CONTEXT_CLASS); } } ..//省略 } //反射生成实例 return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass); }
这儿其实看着是很简单的逻辑，就是根据类型，选择与一个合适的创建，这儿我们就用常见的servlet来说明。servlet对应的上下文为AnnotationConfigServletWebServerApplicationContext。然后最后会根据反射来生成一个实例并返回。我们可以看下这个上下文的类图
相信这个类继承结构大家都看着比较头痛，毕竟作为核心类。这儿就挑两个个重要的说下。
第一。 其最终实现了BeanFactory接口，并继承了GenericApplicationContext。并且我们查看其构造函数会传入一个BeanFactory
public AnnotationConfigServletWebServerApplicationContext(DefaultListableBeanFactory beanFactory) { super(beanFactory); this.reader = new AnnotatedBeanDefinitionReader(this); this.scanner = new ClassPathBeanDefinitionScanner(this); }
最终在GenericApplicationContext中有如下代码
private final DefaultListableBeanFactory beanFactory; public GenericApplicationContext() { this.beanFactory = new DefaultListableBeanFactory(); } public GenericApplicationContext(DefaultListableBeanFactory beanFactory) { Assert.notNull(beanFactory, "BeanFactory must not be null"); this.beanFactory = beanFactory; }
会发现上下文不论如何都会持有一个beanFactory，很多人被问到过ApplicationContext和beanFactory的区别与联系。其实这儿就能看出来是一个很典型的静态代理的案例。既然是代理，就说明了肯定ApplicationContext在保持Beanfactory的原有功能时又扩展了很多功能。这样就可以做到既兼容旧版本，又增强很多功能。当然了，具体的区别有兴趣的可以去看下二者的源代码。
第二。我们在AnnotationConfigServletWebServerApplicationContext的构造函数中发现了有如下步骤
this.reader = new AnnotatedBeanDefinitionReader(this);
这儿新建了一个注解bean的解析器。我们一路跟着源码看下
public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) { Assert.notNull(registry, "BeanDefinitionRegistry must not be null"); Assert.notNull(environment, "Environment must not be null"); this.registry = registry; this.conditionEvaluator = new ConditionEvaluator(registry, environment, null); AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); }
这儿我们会发现该方法最后会为registry注册一些解析器，我们看下AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);该方法会为Beanfactory设置一系列的BeanDefinition，以及其他的一些东西，
public static Set<BeanDefinitionHolder> registerAnnotationConfigProcessors( BeanDefinitionRegistry registry, @Nullable Object source) { DefaultListableBeanFactory beanFactory = unwrapDefaultListableBeanFactory(registry); if (beanFactory != null) { if (!(beanFactory.getDependencyComparator() instanceof AnnotationAwareOrderComparator)) { beanFactory.setDependencyComparator(AnnotationAwareOrderComparator.INSTANCE); } if (!(beanFactory.getAutowireCandidateResolver() instanceof ContextAnnotationAutowireCandidateResolver)) { beanFactory.setAutowireCandidateResolver(new ContextAnnotationAutowireCandidateResolver()); } } Set<BeanDefinitionHolder> beanDefs = new LinkedHashSet<>(4); // 处理@Configuration @ComponentScans @Component @Bean等注解 @PropertySources @ImportResource 等 if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)); } // 处理 @Autowired @Value 等 if (!registry.containsBeanDefinition(AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(AutowiredAnnotationBeanPostProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, AUTOWIRED_ANNOTATION_PROCESSOR_BEAN_NAME)); } // 处理@Required @ if (!registry.containsBeanDefinition(REQUIRED_ANNOTATION_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(RequiredAnnotationBeanPostProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, REQUIRED_ANNOTATION_PROCESSOR_BEAN_NAME)); } // 处理类似@PostConstruct 和@PreDestroy if (jsr250Present && !registry.containsBeanDefinition(COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(CommonAnnotationBeanPostProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, COMMON_ANNOTATION_PROCESSOR_BEAN_NAME)); } // 如果有jpa的话这里有处理的 例如@Selevt if (jpaPresent && !registry.containsBeanDefinition(PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(); try { def.setBeanClass(ClassUtils.forName(PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME, AnnotationConfigUtils.class.getClassLoader())); } catch (ClassNotFoundException ex) { throw new IllegalStateException( "Cannot load optional framework class: " + PERSISTENCE_ANNOTATION_PROCESSOR_CLASS_NAME, ex); } def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, PERSISTENCE_ANNOTATION_PROCESSOR_BEAN_NAME)); } // 处理类似@EventListener的注解 if (!registry.containsBeanDefinition(EVENT_LISTENER_PROCESSOR_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(EventListenerMethodProcessor.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_PROCESSOR_BEAN_NAME)); } if (!registry.containsBeanDefinition(EVENT_LISTENER_FACTORY_BEAN_NAME)) { RootBeanDefinition def = new RootBeanDefinition(DefaultEventListenerFactory.class); def.setSource(source); beanDefs.add(registerPostProcessor(registry, def, EVENT_LISTENER_FACTORY_BEAN_NAME)); } return beanDefs; }
可以发现这儿设置了很多BeanDefinition,尤其是是ConfigurationClassPostProcessor，AutowiredAnnotationBeanPostProcessor这两可以说是相当核心的两个后置处理器，在后面spring进行配置解析的时候会相当的有用。
到此，创建ApplicationContext就完成了，我们看系统刷新上下文的时候做了些什么
2. refreshContext spring的核心加载方法
该方法可以说占据了springboot启动的绝大部分时间，也是springboot启动中最为核心的方法。
private void refreshContext(ConfigurableApplicationContext context) { refresh(context); if (this.registerShutdownHook) { try { context.registerShutdownHook(); } catch (AccessControlException ex) { // Not allowed in some environments. } } }
protected void refresh(ApplicationContext applicationContext) { Assert.isInstanceOf(AbstractApplicationContext.class, applicationContext); ((AbstractApplicationContext) applicationContext).refresh(); }
跟着代码一路走，发现其最终调用的是上下文的refresh方法。由于其被强转为AbstractApplicationContext，所以我们直接看其refresh方法，到此就进入ApplicationContext类中了。
3.ApplicationContext中refresh方法
该方法里面有很多初始化方法，我们也选择核心的说明
@Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { //初始化之前的一些准备，例如设置开始标记等 prepareRefresh(); // 获取到上面提到的beanFactory ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // 初始注册一些要用到的类 prepareBeanFactory(beanFactory); try { // 添加一些BeanFactory的postProcess postProcessBeanFactory(beanFactory); // 执行BeanFactory的PostProcessors invokeBeanFactoryPostProcessors(beanFactory); // 注册一些BeanPostProcessors registerBeanPostProcessors(beanFactory); ../略过 // 一些特殊的操作，例如 //本案例中是AnnotationConfigServletWebServerApplicationContext 那么这儿会开始创建servlet容器 onRefresh(); ../略过 // 实例化容器中未设置懒加载的类 finishBeanFactoryInitialization(beanFactory); ../略过 } } }
这儿我们我们主要看两个方法 一是invokeBeanFactoryPostProcessors，该方法会找出所有需要加载的bean。然后是finishBeanFactoryInitialization方法，该方法会将需要加载的bean进行实例化并装载属性。
4.invokeBeanFactoryPostProcessors方法
该方法我们跟着源代码走，最终会走到PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors方法，由于该方法过长。所以我们分段说明
4.1 无所不在的PostProcesser
不得不说spring将切面应用到了极致啊。。基本每初始化某个东西都会有其对应的PostProcessor，虽然看着略显繁琐，但是却极大的增加了我们的扩展点
public static void invokeBeanFactoryPostProcessors( ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) { // Invoke BeanDefinitionRegistryPostProcessors first, if any. Set<String> processedBeans = new HashSet<>(); if (beanFactory instanceof BeanDefinitionRegistry) { //将我们的BeanFactory强转为BeanDefinitionRegistry BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory; List<BeanFactoryPostProcessor> regularPostProcessors = new LinkedList<>(); List<BeanDefinitionRegistryPostProcessor> registryProcessors = new LinkedList<>(); //循环我们传入的BeanFactoryPostProcessor 如果其是BeanDefinitionRegistryPostProcessor //那么这儿执行其postProcessBeanDefinitionRegistry方法 for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) { if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) { BeanDefinitionRegistryPostProcessor registryProcessor = (BeanDefinitionRegistryPostProcessor) postProcessor; registryProcessor.postProcessBeanDefinitionRegistry(registry); registryProcessors.add(registryProcessor); } else { regularPostProcessors.add(postProcessor); } }
上述代码也是执行了传入的Proccessor类型为BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry方法。
4.2 第一级BeanDefinitionRegistryPostProcessor执行(即实现了PriorityOrdered接口)
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>(); // 找到系统所有实现了PriorityOrdered接口的BeanDefinitionRegistryPostProcessor接口实现类
// 这儿会找到我们刚刚的 ConfigurationClassPostProcessor
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) { if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); } } //排序 sortPostProcessors(currentRegistryProcessors, beanFactory); //将刚找到的BeanDefinitionRegistryPostProcessor加入registryProcessors registryProcessors.addAll(currentRegistryProcessors); //执行刚找到的BeanDefinitionRegistryPostProcessor invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); //清空 currentRegistryProcessors.clear();
这儿即找实现了BeanDefinitionRegistryPostProcessor，PriorityOrdered的类。而我们在第一节中最后提到的ConfigurationClassPostProcessor刚好是满足的，我们可以在回顾一下
这儿我们进入invokeBeanDefinitionRegistryPostProcessors方法看下
private static void invokeBeanDefinitionRegistryPostProcessors( Collection<? extends BeanDefinitionRegistryPostProcessor> postProcessors, BeanDefinitionRegistry registry) { for (BeanDefinitionRegistryPostProcessor postProcessor : postProcessors) { postProcessor.postProcessBeanDefinitionRegistry(registry); } }
可以看到是迭代所有BeanDefinitionRegistryPostProcessor并执行其postProcessBeanDefinitionRegistry方法。而上面说到我们会拿到ConfigurationClassPostProcessor，所以这儿我们直接看ConfigurationClassPostProcessor的方法，由于该方法是spring进行配置解析的重中之重，所以篇幅较长
4.2.1 校验并为本次解析设置id，防止重复加载
第一步则是设置了本次解析的id，防止重复解析
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) { //得到registry的hash码作为id int registryId = System.identityHashCode(registry); //校验id if (this.registriesPostProcessed.contains(registryId)) { throw new IllegalStateException( "postProcessBeanDefinitionRegistry already called on this post-processor against " + registry); } if (this.factoriesPostProcessed.contains(registryId)) { throw new IllegalStateException( "postProcessBeanFactory already called on this post-processor against " + registry); } this.registriesPostProcessed.add(registryId); //正式解析 processConfigBeanDefinitions(registry); }
4.2.2 正式解析
这儿我们依旧一段一段的看
List<BeanDefinitionHolder> configCandidates = new ArrayList<>(); //找到该registry所有的candidateNames 也就是我们第一步结尾添加的那些 String[] candidateNames = registry.getBeanDefinitionNames(); for (String beanName : candidateNames) { BeanDefinition beanDef = registry.getBeanDefinition(beanName); //isFullConfigurationClass 判断是否是带有@Configuration //isLiteConfigurationClass 判断是否带有@Component，@ComponentScan，@Import，@ImportResource，@Bean 5个注解中的任一个 // 具体可以查看 https://blog.csdn.net/u011624903/article/details/102564491 if (ConfigurationClassUtils.isFullConfigurationClass(beanDef) || ConfigurationClassUtils.isLiteConfigurationClass(beanDef)) { if (logger.isDebugEnabled()) { logger.debug("Bean definition has already been processed as a configuration class: " + beanDef); } } // 这儿由于我们的主启动类中@SpringbootApplication带@Configuration注解 所以主类满足 else if (ConfigurationClassUtils.checkConfigurationClassCandidate(beanDef, this.metadataReaderFactory)) { configCandidates.add(new BeanDefinitionHolder(beanDef, beanName)); } } // Return immediately if no @Configuration classes were found if (configCandidates.isEmpty()) { return; }
// 排序
configCandidates.sort((bd1, bd2) -> {
int i1 = ConfigurationClassUtils.getOrder(bd1.getBeanDefinition());
int i2 = ConfigurationClassUtils.getOrder(bd2.getBeanDefinition());
return Integer.compare(i1, i2);
});
这儿会将BeanFactory中已经存在的BeanDefinitionName全部查出来并获取其BeanDefinition，由于我们的启动类@SpringbootApplication中已经带有@Configuration 所以这里是满足的(第一节中讲组合注解的时候讲过)
然后接下来会有查看是否有BeanNameGenerator和environment
SingletonBeanRegistry sbr = null; if (registry instanceof SingletonBeanRegistry) { sbr = (SingletonBeanRegistry) registry; if (!this.localBeanNameGeneratorSet) { BeanNameGenerator generator = (BeanNameGenerator) sbr.getSingleton(CONFIGURATION_BEAN_NAME_GENERATOR); if (generator != null) { this.componentScanBeanNameGenerator = generator; this.importBeanNameGenerator = generator; } } } if (this.environment == null) { this.environment = new StandardEnvironment(); }
然后我们就看到了本文最核心的代码了，也就是解析代码。
我们看下这个解析流程
// 构建一个ConfigurationClassParser 也就是解析器 ConfigurationClassParser parser = new ConfigurationClassParser( this.metadataReaderFactory, this.problemReporter, this.environment, this.resourceLoader, this.componentScanBeanNameGenerator, registry); //拿到我们解析的配置类 这儿的话是主启动类 Set<BeanDefinitionHolder> candidates = new LinkedHashSet<>(configCandidates); //已经解析的ConfigurationClass集合 Set<ConfigurationClass> alreadyParsed = new HashSet<>(configCandidates.size()); do { //开始解析 parser.parse(candidates); //验证 parser.validate(); //找到本次解析后发现的所有ConfigurationClass Set<ConfigurationClass> configClasses = new LinkedHashSet<>(parser.getConfigurationClasses()); //移除掉已经解析的 configClasses.removeAll(alreadyParsed); // 如果没有 则创建一个新的ConfigurationClassBeanDefinitionReader if (this.reader == null) { this.reader = new ConfigurationClassBeanDefinitionReader( registry, this.sourceExtractor, this.resourceLoader, this.environment, this.importBeanNameGenerator, parser.getImportRegistry()); } //将这些发现的找到本次解析后发现的所有ConfigurationClass再次解析掉 this.reader.loadBeanDefinitions(configClasses); //将其添加到已解析的集合中 alreadyParsed.addAll(configClasses); //清空candidates candidates.clear(); //如果registry中的BeanDefinition数量大于candidateNames 也就是一开始进入方法时的数量 //即找到的新的需要加入容器的bean了 if (registry.getBeanDefinitionCount() > candidateNames.length) { //拿到所有的已经存在的BeanDefinitionName String[] newCandidateNames = registry.getBeanDefinitionNames(); //初始进来的BeanDefinitionName Set<String> oldCandidateNames = new HashSet<>(Arrays.asList(candidateNames)); //创建已经解析的Class的名字的集合 Set<String> alreadyParsedClasses = new HashSet<>(); for (ConfigurationClass configurationClass : alreadyParsed) { //将已经解析的添加到集合中 alreadyParsedClasses.add(configurationClass.getMetadata().getClassName()); } //循环遍历 所有的BeanDefinition 看看有没有configuration被遗漏的 for (String candidateName : newCandidateNames) { //即不是初始化进来时的BeanDefinition if (!oldCandidateNames.contains(candidateName)) { //拿到这个BeanDefinition BeanDefinition bd = registry.getBeanDefinition(candidateName); //如果该BeanDefinition也是一个配置类并且没有存在于alreadyParsed 即被遗漏了 //那么将其添加到candidates方法 然后再进行 if (ConfigurationClassUtils.checkConfigurationClassCandidate(bd, this.metadataReaderFactory) && !alreadyParsedClasses.contains(bd.getBeanClassName())) { //则再将其添加进去 循环进行解析 candidates.add(new BeanDefinitionHolder(bd, candidateName)); } } } candidateNames = newCandidateNames; } } while (!candidates.isEmpty());
这段代码较长，逻辑还是较为清晰，其实通过这段代码我们就大概明白了springboot进行配置加载的流程了。即根据主启动类进行配置解析，并且将所有遇到的ConfigurationClass全部返回，然后再进行二次解析，最后对所有的BeanDefinition进行校验，如果发现其为ConfigurationClass但是却没有在已解析的集合中，那么久循环一下，再次进行解析。
篇幅有限，具体的解析流程放到下一篇， 解析完第一级BeanDefinitionRegistryPostProcessor后我们开始解析第二级
4.3 第二级BeanDefinitionRegistryPostProcessor(即实现了Ordered接口)
// Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered. postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) {
//过滤了第一级中存在的 if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); } } sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear();
可以发现其流程和第一级几乎一致，只是增加了一个过滤掉了第一级，所以这儿不讲，如果有自定义的BeanDefinitionRegistryPostProcessor可以测试一下。
4.4 第三级BeanDefinitionRegistryPostProcessor
// Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear. boolean reiterate = true; while (reiterate) { reiterate = false; postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false); for (String ppName : postProcessorNames) { if (!processedBeans.contains(ppName)) { currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class)); processedBeans.add(ppName); reiterate = true; } } sortPostProcessors(currentRegistryProcessors, beanFactory); registryProcessors.addAll(currentRegistryProcessors); invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry); currentRegistryProcessors.clear(); }
处理流程也和前两级几乎一致，这儿也不讲了
4.4 BeanFactoryPostProcessor的执行
即找到系统存在的BeanFactoryPostProcessor，同样按照三级的形式根据优先级来执行。具体的逻辑也和上面详细讲的那个一级是一致的。
String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false); //找到所有的BeanFactoryPostProcessor 并根据其级别进行归类 List<BeanFactoryPostProcessor> priorityOrderedPostProcessors = new ArrayList<>(); List<String> orderedPostProcessorNames = new ArrayList<>(); List<String> nonOrderedPostProcessorNames = new ArrayList<>(); for (String ppName : postProcessorNames) { if (processedBeans.contains(ppName)) { // skip - already processed in first phase above } else if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) { priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanFactoryPostProcessor.class)); } else if (beanFactory.isTypeMatch(ppName, Ordered.class)) { orderedPostProcessorNames.add(ppName); } else { nonOrderedPostProcessorNames.add(ppName); } } // 执行优先级最高的 即实现了PriorityOrdered接口的 sortPostProcessors(priorityOrderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory); // 执行第二级的的 即实现了Ordered接口的 List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(); for (String postProcessorName : orderedPostProcessorNames) { orderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } // 执行第三级的的 即啥都没实现的 sortPostProcessors(orderedPostProcessors, beanFactory); invokeBeanFactoryPostProcessors(orderedPostProcessors, beanFactory); // Finally, invoke all other BeanFactoryPostProcessors. List<BeanFactoryPostProcessor> nonOrderedPostProcessors = new ArrayList<>(); for (String postProcessorName : nonOrderedPostProcessorNames) { nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class)); } invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory); //清除缓存 beanFactory.clearMetadataCache();
到此，refresh方法中的两个重要方法第一个 invokeBeanFactoryPostProcessors，已经完成，而其中的ConfigurationClassPostProcessor(也就是BeanDefinitionRegistryPostProcessor的一种)负责了最为核心的容器类加载，也就是主要分析的类也分析完成。(详细的类解析过程篇幅问题放在下章)
总结
本文主要分为了两个部分，创建Spring应用上下文，和执行了其refresh方法中的invokeBeanFactoryPostProcessors方法。
创建应用上下文的同时也会创建一个DefaultListableBeanFactory，这个也是静态代理的体现。而在执行ApplicationContext的构造函数时，会创建一个AnnotatedBeanDefinitionReader，而这个类中会有一个BeanDefinitionRegistry属性，并将我们一些必须的BeanDefinition添加进去，例如最为核心的 ConfigurationClassPostProcessor也就是在这个时候被添加进去的。
执行invokeBeanFactoryPostProcessors方法则主要分为三个步骤
- 执行所有传入的BeanFactoryPostProcessor(如果为BeanFactoryPostProcessor)的postProcessBeanDefinitionRegistry方法
- 找到BeanFactory中所有的BeanDefinitionRegistryPostProcessor类型的类并按照三级标准执行(实现了PriorityOrdered接口，实现了Ordered接口，啥都没实现 )；
- 找到BeanFactory中所有的BeanFactoryPostProcessor类型的类并按照三级标准执行(实现了PriorityOrdered接口，实现了Ordered接口，啥都没实现 )；
而其第二步则执行了核心的ConfigurationClassPostProcessor，并且是以最优先级执行，该processer会加载系统中所有需要加入容器的类，并且会解析所有的Configuration class