关联博文:
​​AbstractApplicationContext中refresh方法详解​​Spring中refresh分析之prepareRefresh方法详解
Spring中refresh分析之obtainFreshBeanFactory方法详解
Spring中refresh分析之prepareBeanFactory方法详解
Spring中refresh分析之postProcessBeanFactory方法详解
Spring中refresh分析之invokeBeanFactoryPostProcessors方法详解
Spring中refresh分析之registerBeanPostProcessors方法详解
Spring中refresh分析之initMessageSource方法详解
Spring中refresh分析之initApplicationEventMulticaster方法详解
Spring中refresh分析之onRefresh方法详解
Spring中refresh分析之registerListeners方法详解
Spring中refresh分析之finishBeanFactoryInitialization方法详解
Spring中refresh分析之finishRefresh方法详解

接上文​​Spring中refresh分析之postProcessBeanFactory方法详解​​我们分析过postProcessBeanFactory后,本文分析invokeBeanFactoryPostProcessors方法。

方法功能总结:该方法执行后,DefaultListableBeanFactory中的beanDefinitionMap就拥有了系统中的BeanDefinition !

关于BeanFactoryPostProcessors的更多介绍可以参考博文:
​Spring中那些BeanFactoryPostProcessors详解(一)​​Spring中那些BeanFactoryPostProcessors详解(二)

【1】前言

在单例bean实例化前,实例化并调用所有注册的BeanFactoryPostProcessor,如果给定了order,则遵循顺序。注意哦,不是BeanPostProcessor。

protected void invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory beanFactory) {
PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(beanFactory, getBeanFactoryPostProcessors());

// Detect a LoadTimeWeaver and prepare for weaving, if found in the meantime
// (e.g. through an @Bean method registered by ConfigurationClassPostProcessor)
if (beanFactory.getTempClassLoader() == null && beanFactory.containsBean(LOAD_TIME_WEAVER_BEAN_NAME)) {
beanFactory.addBeanPostProcessor(new LoadTimeWeaverAwareProcessor(beanFactory));
beanFactory.setTempClassLoader(new ContextTypeMatchClassLoader(beanFactory.getBeanClassLoader()));
}
}

如上代码所示首先调用​​invokeBeanFactoryPostProcessors​​,然后判断是否有oadTimeWeaver 有则注册LoadTimeWeaverAwareProcessor到bean后置处理器集合并为beanFactory设置tempClassLoader。

LoadTimeWeaver是加载时织入,是AspectJ领域的东西。在Java 语言中,从织入切面的方式上来看,存在三种织入方式:编译期织入、类加载期织入和运行期织入。编译期织入是指在Java编译期,采用特殊的编译器,将切面织入到Java类中;而类加载期织入则指通过特殊的类加载器,在类字节码加载到JVM时,织入切面;运行期织入则是采用CGLib工具或JDK动态代理进行切面的织入。

AspectJ采用编译期织入和类加载期织入的方式织入切面,是语言级的AOP实现,提供了完备的AOP支持。它用AspectJ语言定义切面,在编译期或类加载期将切面织入到Java类中。

AspectJ提供了两种切面织入方式,第一种通过特殊编译器,在编译期,将AspectJ语言编写的切面类织入到Java类中,可以通过一个Ant或Maven任务来完成这个操作;第二种方式是类加载期织入,也简称为LTW(Load Time Weaving)。

① 什么是BeanFactoryPostProcessor?

这里我们首先有个问题,什么是​​BeanFactoryPostProcessor​​?其是一个工厂钩子,允许自定义修改bean定义并调整其属性值。

​BeanFactoryPostProcessor​​​可以与​​BeanDefinition​​交互并对其进行修改,但是不能与bean实例进行交互。这样做可能会导致过早实例化bean,导致意外的副作用。如果需要bean实例交互,请考虑实现BeanPostProcessor。

注册

​ApplicationContext​​​自动在其维护的吧​​beanDefinitionMap​​​中检测​​BeanFactoryPostProcessor​​,并在创建任何其他bean之前应用它们。

​BeanFactoryPostProcessor​​​也可以通过编程方式注册到​​ConfigurableApplicationContext​​。

排序

​ApplicationContext​​​自动检测到的​​BeanFactoryPostProcessor​​​将会根据其​​PriorityOrdered​​​或者​​Ordered​​语义对其进行排序。

相对的,通过编程方式注册到​​ConfigurableApplicationContext​​​的​​BeanFactoryPostProcessor​​将会遵循注册的顺序,这时将会忽略PriorityOrdered或者Ordered的语义。

此外,​​BeanFactoryPostProcessor​​ Bean 不考虑@Order注解的应用。

如下所示,其是一个功能性接口,只有一个方法postProcessBeanFactory。该方法允许在bean factory实例化后、bean定义已经被加载但是没有被实例化前覆盖或添加属性,甚至是对渴望初始化的bean。

@FunctionalInterface
public interface BeanFactoryPostProcessor {

void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;

}

注册,如果自定义服务实现了该接口在方法里面触发了getBean,那么会导致Bean的过早实例化,可能会引起不可预知错误。

本文beanFactoryPostProcessors 有如下所示三个:

{SharedMetadataReaderFactoryContextInitializer$CachingMetadataReaderFactoryPostProcessor@5199} 
{ConfigurationWarningsApplicationContextInitializer$ConfigurationWarningsPostProcessor@5200}
{ConfigFileApplicationListener$PropertySourceOrderingPostProcessor@5201}

注意哦,这三个是在refresh前通过​​context.addBeanFactoryPostProcessor()​​​注册到​​DefaultListableBeanFactory​​​的​​List<BeanFactoryPostProcessor> beanFactoryPostProcessors​​中的。

② BeanDefinitionRegistryPostProcessor

为什么我们这里又继续提到了​​BeanDefinitionRegistryPostProcessor​​​?因为在方法​​invokeBeanFactoryPostProcessors​​​中首先就判断当前bean是否为​​BeanDefinitionRegistry​​​。而​​BeanDefinitionRegistryPostProcessor​​​从名字上看,就联想到其是处理​​BeanDefinitionRegistry​​的。

BeanDefinitionRegistry是Spring的bean工厂包中唯一一个封装bean定义注册的接口,其提供了beandefinition的注册、移除和查找、获取与统计。

​BeanDefinitionRegistryPostProcessor​​​继承自​​BeanFactoryPostProcessor​​​提供了​​postProcessBeanDefinitionRegistry​​​方法。其是对标准BeanFactoryPostProcessor SPI的扩展,允许在常规​​BeanFactoryPostProcessor​​​检测开始之前注册进一步的bean定义。尤其是,​​BeanDefinitionRegistryPostProcessor​​​可以注册更多的bean定义,这些定义反过来定义​​BeanFactoryPostProcessor​​实例。

​postProcessBeanDefinitionRegistry​​方法允许在标准初始化之后修改应用程序上下文的内部bean定义注册表。这时已加载所有常规bean定义,但尚未实例化任何bean。允许在下一个后处理阶段开始之前添加更多的bean定义。

比如MapperScannerConfigurer、ConfigurationClassPostProcessor均实现了BeanDefinitionRegistryPostProcessor接口。

【2】核心方法invokeBeanFactoryPostProcessors

这里触发的是​​PostProcessorRegistrationDelegate​​​的​​invokeBeanFactoryPostProcessors​​方法。

public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {

// Invoke BeanDefinitionRegistryPostProcessors first, if any.
// 记录已经处理过的Bean
Set<String> processedBeans = new HashSet<>();

// 判断是否为 BeanDefinitionRegistry
// 这里DefaultListableBeanFactory 实现了 BeanDefinitionRegistry
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;

// 创建了两个 List 集合, 用来存放处理器
// BeanDefinitionRegistryPostProcessor 是 BeanFactoryPostProcessor 的子接口
//还可以额外处理 BeanDefinition, 添加 BeanDefinition
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();

// 循环 beanFactoryPostProcessors
// beanFactoryPostProcessors 是使用 API context.addBeanFactoryPostProcessor 添加进来的,与getBean检索不同
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {

// BeanDefinitionRegistryPostProcessor 要单独添加到 registryProcessors
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;

// 处理 Bean 的信息
registryProcessor.postProcessBeanDefinitionRegistry(registry);
registryProcessors.add(registryProcessor);
} else {
// 常规的BeanFactoryPostProcessor
regularPostProcessors.add(postProcessor);
}
}

// Do not initialize FactoryBeans here: We need to leave all regular beans
// uninitialized to let the bean factory post-processors apply to them!
// Separate between BeanDefinitionRegistryPostProcessors that implement
// PriorityOrdered, Ordered, and the rest.

// 先执行实现了 PriorityOrdered接口的,然后是 Ordered 接口的,最后执行剩下的
// currentRegistryProcessors 记录当前符合判断条件将要被执行的
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();

// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
// 第一步先调用实现了PriorityOrdered的BeanDefinitionRegistryPostProcessors

// 从容器中查找BeanDefinitionRegistryPostProcessor
// true表示包括非单例,false表示不允许早期/急切初始化
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
for (String ppName : postProcessorNames) {
// 判断是否实现了PriorityOrdered接口
if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
// 添加 bean到currentRegistryProcessors
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
// 这里只添加了名字 后面用来判断谁已经执行过了
processedBeans.add(ppName);
}
}
// 排序
sortPostProcessors(currentRegistryProcessors, beanFactory);
// 放到registryProcessors中
registryProcessors.addAll(currentRegistryProcessors);

// 循环执行 processors 的 postProcessBeanDefinitionRegistry 方法
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
// 清空currentRegistryProcessors
currentRegistryProcessors.clear();

// Next, invoke the BeanDefinitionRegistryPostProcessors that implement Ordered.
// 再次检索BeanDefinitionRegistryPostProcessor,因为其本身可能引入新的BeanDefinitionRegistryPostProcessor
postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
// 处理实现 Ordered 的 processor
for (String ppName : postProcessorNames) {
// 只有不包含的才执行, 执行完之后会添加进 processedBeans
if (!processedBeans.contains(ppName) && beanFactory.isTypeMatch(ppName, Ordered.class)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
}
}
// 排序
sortPostProcessors(currentRegistryProcessors, beanFactory);
// 放到registryProcessors
registryProcessors.addAll(currentRegistryProcessors);
// 循环调用BeanDefinitionRegistryPostProcessor的postProcessBeanDefinitionRegistry
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
// 清空currentRegistryProcessors
currentRegistryProcessors.clear();

// 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) {
// 只有不包含的才执行, 执行完之后会添加进 processedBeans
if (!processedBeans.contains(ppName)) {
currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
processedBeans.add(ppName);
reiterate = true;
}
}
sortPostProcessors(currentRegistryProcessors, beanFactory);
registryProcessors.addAll(currentRegistryProcessors);
// 比如MapperScannerConfigurer就是在前面被引入,这里会检测出来
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry, beanFactory.getApplicationStartup());
currentRegistryProcessors.clear();
}

// Now, invoke the postProcessBeanFactory callback of all processors handled so far.
// 上面处理的都是 postProcessBeanDefinitionRegistry 是在 -> BeanDefinitionRegistryPostProcessor 中
// 下面开始处理 postProcessBeanFactory -> 是在 BeanFactoryPostProcessor 中
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
} else {
// Invoke factory processors registered with the context instance.
// 不是 BeanDefinitionRegistry 则是普通 BeanFactory 直接执行 beanFactoryPostProcessors 即可
invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
}

// Do not initialize FactoryBeans here: We need to leave all regular beans
// uninitialized to let the bean factory post-processors apply to them!

// 第二部分--处理BeanFactoryPostProcessor
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);

// Separate between BeanFactoryPostProcessors that implement PriorityOrdered,
// Ordered, and the rest.
// 分成三个部分 PriorityOrdered Ordered及其他
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);
}
}

// First, invoke the BeanFactoryPostProcessors that implement PriorityOrdered.
// 执行实现 PriorityOrdered 的
sortPostProcessors(priorityOrderedPostProcessors, beanFactory);
invokeBeanFactoryPostProcessors(priorityOrderedPostProcessors, beanFactory);

// Next, invoke the BeanFactoryPostProcessors that implement Ordered.
List<BeanFactoryPostProcessor> orderedPostProcessors = new ArrayList<>(orderedPostProcessorNames.size());
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<>(nonOrderedPostProcessorNames.size());
for (String postProcessorName : nonOrderedPostProcessorNames) {
nonOrderedPostProcessors.add(beanFactory.getBean(postProcessorName, BeanFactoryPostProcessor.class));
}
invokeBeanFactoryPostProcessors(nonOrderedPostProcessors, beanFactory);

// Clear cached merged bean definitions since the post-processors might have
// modified the original metadata, e.g. replacing placeholders in values...
// 清空不必要的元数据信息
beanFactory.clearMetadataCache();
}

方法大致我们分为两个部分,以​​String[] postProcessorNames = beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);​​语句为分割线,其上属于第一部分,其下属于第二部分。

第一部分

第一部分分为两块,如果当前BeanFactory是BeanDefinitionRegistry实例则进行已经复杂的处理。否则直接调用invokeBeanFactoryPostProcessors。

我们来梳理一下BeanFactory是BeanDefinitionRegistry实例时流程:

  • 创建两个list,​​regularPostProcessors​​​和​​registryProcessors​​;
  • 循环遍历​​beanFactoryPostProcessors​​​,如果其是​​BeanDefinitionRegistryPostProcessor​​​类型则调用​​postProcessBeanDefinitionRegistryf​​​方法并放到​​registryProcessors​​​中,否则放到​​regularPostProcessors​​中。
  • 扫描容器中的​​BeanDefinitionRegistryPostProcessor​​​,分成​​PriorityOrdered​​​、​​Ordered​​​和​​其他​​​三个部分,对每一部分都进行排序然后触发每个实例的​​postProcessBeanDefinitionRegistry​​方法。
  • 最后对​​registryProcessors​​​和​​regularPostProcessors​​两个集合所有实例的postProcessBeanFactory方法进行执行。

第二部分

第一部分可以简单理解其是处理的​​BeanDefinitionRegistryPostProcessor​​​实例的​​postProcessBeanDefinitionRegistry​​​方法和​​postProcessBeanFactory​​方法。第二部分则是处理其父接口BeanFactoryPostProcessor的postProcessBeanFactory方法。

其从容器中扫描BeanFactoryPostProcessor然后分为三个部分:PriorityOrdered、Ordered和其他。对每一部分进行排序然后调用其postProcessBeanFactory方法。

beanFactoryPostProcessors来源

SharedMetadataReaderFactoryContextInitializer的initialize方法。

@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
applicationContext.addBeanFactoryPostProcessor(new CachingMetadataReaderFactoryPostProcessor());
}

ConfigurationWarningsApplicationContextInitializer的initialize方法。

@Override
public void initialize(ConfigurableApplicationContext context) {
context.addBeanFactoryPostProcessor(new ConfigurationWarningsPostProcessor(getChecks()));
}

ConfigFileApplicationListener的addPostProcessors方法。

protected void addPostProcessors(ConfigurableApplicationContext context) {
context.addBeanFactoryPostProcessor(new PropertySourceOrderingPostProcessor(context));
}

这三个方法均是在prepareContext方法中触发的,此时还没有进行refresh。

【3】CachingMetadataReaderFactoryPostProcessor

​CachingMetadataReaderFactoryPostProcessor​​​是​​SharedMetadataReaderFactoryContextInitializer​​​的静态内部类,实现了​​BeanDefinitionRegistryPostProcessor​​​和​​PriorityOrdered​​接口。

private static class CachingMetadataReaderFactoryPostProcessor
implements BeanDefinitionRegistryPostProcessor, PriorityOrdered {

@Override
public int getOrder() {
// Must happen before the ConfigurationClassPostProcessor is created
// Integer.MIN_VALUE
return Ordered.HIGHEST_PRECEDENCE;
}

@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
}

@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
register(registry);
configureConfigurationClassPostProcessor(registry);
}

// 注册SharedMetadataReaderFactoryBean BeanDefinition
private void register(BeanDefinitionRegistry registry) {
BeanDefinition definition = BeanDefinitionBuilder
.genericBeanDefinition(SharedMetadataReaderFactoryBean.class, SharedMetadataReaderFactoryBean::new)
.getBeanDefinition();
// internalCachingMetadataReaderFactory-definition
registry.registerBeanDefinition(BEAN_NAME, definition);
}

private void configureConfigurationClassPostProcessor(BeanDefinitionRegistry registry) {
try {
BeanDefinition definition = registry
.getBeanDefinition(AnnotationConfigUtils.CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME);
// internalConfigurationAnnotationProcessor添加metadataReaderFactory=internalCachingMetadataReaderFactory
definition.getPropertyValues().add("metadataReaderFactory", new RuntimeBeanReference(BEAN_NAME));
}
catch (NoSuchBeanDefinitionException ex) {
}
}

}

可以看到其postProcessBeanDefinitionRegistry方法做了两件事:

  • 注册​​BeanDefinition:internalCachingMetadataReaderFactory​​​—​​SharedMetadataReaderFactoryBean​​;
  • 获取​​internalConfigurationAnnotationProcessor​​​的BeanDefinition为其添加属性值​​metadataReaderFactory​​​—​​new RuntimeBeanReference(internalCachingMetadataReaderFactory)​

​SharedMetadataReaderFactoryBean​​​也是​​SharedMetadataReaderFactoryContextInitializer​​的静态内部类,如下所示其维护了一个metadataReaderFactory成员。

static class SharedMetadataReaderFactoryBean
implements FactoryBean<ConcurrentReferenceCachingMetadataReaderFactory>, BeanClassLoaderAware,
ApplicationListener<ContextRefreshedEvent> {

private ConcurrentReferenceCachingMetadataReaderFactory metadataReaderFactory;

@Override
public void setBeanClassLoader(ClassLoader classLoader) {
this.metadataReaderFactory = new ConcurrentReferenceCachingMetadataReaderFactory(classLoader);
}
//...
}

如下所示这里获取的​​internalConfigurationAnnotationProcessor​​​的​​BeanDefinition​​​是​​ConfigurationClassPostProcessor​​。

Spring中refresh分析之invokeBeanFactoryPostProcessors方法详解_BeanFactory后置处理

【4】ConfigurationClassPostProcessor

​ConfigurationClassPostProcessor​​​做了什么事情呢?如下所示其实现了​​BeanDefinitionRegistryPostProcessor​​​和​​PriorityOrdered​​及其他三个XXXAware接口。

public class ConfigurationClassPostProcessor implements BeanDefinitionRegistryPostProcessor,
PriorityOrdered, ResourceLoaderAware, BeanClassLoaderAware, EnvironmentAware {
//....
}

其核心是用来处理@Configuration标注的配置类!这个ConfigurationClassPostProcessor 后处理器是按优先级排序的,因为在​​@Configuration​​​配置类中声明的任何​​@Bean​​方法都必须在任何其他BeanFactoryPostProcessor执行之前注册相应的Bean定义,这一点很重要。

其postProcessBeanDefinitionRegistry方法如下所示,其首先对registry进行判断是否已经处理过,没有处理过则调用​​processConfigBeanDefinitions(registry);​​方法。

@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
int registryId = System.identityHashCode(registry);
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);
//处理配置bean定义
processConfigBeanDefinitions(registry);
}

关于ConfigurationClassPostProcessor本文我们这里不做进一步分析,简单梳理其作用如下:

  • 对于候选配置类使用CGLIB Enhancer增强
  • 解析处理@PropertySource 注解
  • 解析@ComponentScan注解,扫描@Configuration、@Service、@Controller、@Repository和@Component注解并注册BeanDefinition
  • 解析@Import注解,然后进行实例化,并执行ImportBeanDefinitionRegistrar的registerBeanDefinitions逻辑,或者ImportSelector的selectImports逻辑
  • 解析@ImportResource注解,并加载相关配置信息
  • 解析方法级别@Bean注解并将返回值注册成BeanDefinition
  • 注册ImportAwareBeanPostProcessor到容器中,用于处理ImportAware

总结一点就是,经过​​ConfigurationClassPostProcessor​​​和​​MapperScannerConfigurer​​​的处理,我们的​​DefaultListableBeanFactory​​​的​​beanDefinitionMap​​中已经拥有了应用程序中的静态BeanDefinition(可能不是全部,比如程序动态添加)。