在AbstractApplicationContext#refresh方法中会调用invokeBeanFactoryPostProcessors方法，用于实例化并且调用所有已经注册了的BeanFactoryPostProcessor；
AbstractApplicationContext#invokeBeanFactoryPostProcessors会调用PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors，入参如下；
参数beanFactory是refresh方法中传过来的，beanFactoryPostProcessors是当前应用中beanFactoryPostProcessor的值；
BeanDefinitionRegistryPostProcessor是BeanFactoryPostProcessor的子集，如下；
处理外部的BeanFactoryPostProcessor集合
由于BeanDefinitionRegistryPostProcessor是BeanFactoryPostProcessor的子集，invokeBeanFactoryPostProcessors首先处理外部的BeanFactoryPostProcessor集合，如下；
这个过程处理入参中的beanFactoryPostProcessors，将BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor区分开，分别使用registryProcessors和regularPostProcessors存储；beanFactoryPostProcessors默认为空，这个参数是用户手动注入的BeanFactoryPostProcessor接口的实现；
测试如下：
未手动注入BeanFactoryPostPorcessor接口实现前，如下：
@Test
public void beanLifeCycleTest() {
AnnotationConfigApplicationContext context =
new AnnotationConfigApplicationContext(BeanConfig.class);
}
手动注入BeanFactoryPostPorcessor接口实现前，如下：
@Test
public void addBeanFactoryPostProcessor() {
AnnotationConfigApplicationContext context =
new AnnotationConfigApplicationContext();
// 注册配置类
context.register(BeanConfig.class);
context.addBeanFactoryPostProcessor(new BFPPDemo2());
context.refresh();
}
处理容器中实现了BeanDefinitionRegistryPostProcessor接口的实例
然后，处理实现了BeanDefinitionRegistryPostProcessor接口的实例，通过类型匹配查找，如下；
上面两个框都是通过类型匹配查找到BeanDefinitionRegistryPostProcessor类型的beanName的数组，逻辑基本相同的，那为何要执行两次基本相同的逻辑？
通过类型匹配查找到BeanDefinitionRegistryPostProcessor类型的beanName的数组，存入postProcessorNames，遍历postProcessorNames将实现了PriorityOrder接口的BeanDefinitionRegistryPostProcessor类型的实例和实例的beanName分别存入currentRegistryProcessors和processedBeans，将要被执行的BeanDefinitionRegistryPostProcessor添加到processedBeans，防止processedBeans重复执行；
其中，AnnotatedBeanDefinitionReader实例化时会调用AnnotationConfigUtils#registerAnnotationConfigProcessors(org.springframework.beans.factory.support.BeanDefinitionRegistry, java.lang.Object)方法，注册所有注解相关的后置处理器，ConfigurationClassPostProcessor的beanDefinition就在这个过程注册的，ConfigurationClassPostProcessor用于参与BeanFactory的构建，主要功能：处理@Configuration注解的解析，解析@ComponentScan扫描的包，解析@ComponentScans扫描的包，解析@Import注解，如下；
AnnotationConfigUtils#registerAnnotationConfigProcessors(org.springframework.beans.factory.support.BeanDefinitionRegistry, java.lang.Object)
第一次执行只是获取了内置的后置处理器ConfigurationClassPostProcessor的beanName，执行invokeBeanDefinitionRegistryPostProcessors方法时，执行的是ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry方法，执行完该方法会将自定义的Bean的beanDefinition装载到beanDefinitionMap，beanDefinitionNames，效果如下；
此时，自定义的BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor的beanDefinition会重新添加到了beanDefinitionNames，再执行一次基本相同的逻辑因为上面的过程会新增新的BeanDefinitionRegistryPostProcessor和BeanFactoryPostProcessor；
执行sourtPostProcessors方法排序是将实现了Ordered接口的BeanDefinitionRegistryPostProcessor类型或BeanFactoryPostProcessor类型实例按照设置的order值排序，排序的是currentRegistryProcessors里面的实例，用于执行invokeBeanDefinitionRegistryPostProcessors或invokeBeanFactoryPostProcessors方法时，处理BeanDefinitionRegistryPostProcessor类型或BeanFactoryPostProcessor类型实例的优先级，而不是设置这些类型的创建实例的优先级，sortPostProcessors逻辑如下；
注：PriorityOrdered接口继承于Ordered接口
PostProcessorRegistrationDelegate#sortPostProcessors
判断入参beanFactory是否是DefaultListableBeanFactory类型，如果是则获取比较器，如果没有设置比较器，则使用默认的比较器比较；
默认的比较器OrderComparator实现了Comparator接口，比较的逻辑在doCompare方法，通过order值排序，order值越小，优先级越高；
执行sourtPostProcessors方法将存储后的currentRegistryProcessors按照优先级排序，测试如下：
@Component
public class BFPPDemo1 implements BeanFactoryPostProcessor, PriorityOrdered {
private final static Log LOG = LogFactory.getLog(BFPPDemo1.class);
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
LOG.info("-postProcessBeanFactory-");
}
@Override
public int getOrder() {
return Integer.MAX_VALUE - 1;
}
}
@Component
public class BFPPDemo2 implements BeanFactoryPostProcessor, PriorityOrdered {
private final static Log LOG = LogFactory.getLog(BFPPDemo2.class);
@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
LOG.info("-postProcessBeanFactory-");
}
@Override
public int getOrder() {
return Integer.MAX_VALUE - 2;
}
}
@Test
public void beanLifeCycleTest() {
AnnotationConfigApplicationContext context =
new AnnotationConfigApplicationContext(BeanConfig.class);
}
效果如下：
currentRegistryProcessors排序后作为invokeBeanDefinitionRegistryPostProcessors方法的入参，执行后置处理器的顺序是根据currentRegistryProcessors的；
上面的逻辑处理完后，会将currentRegistryProcessors集合清空，当处理剩下没有实现PriorityOrdered接口或Ordered接口的BeanDefinitionRegistryPostProcessor类型的实例，由于processedBeans存储了执行过的BeanDefinitionRegistryPostProcessor实例的beanName，下面的逻辑不会出现相同的BeanDefinitionRegistryPostProcessor类型的实例重复执行；
下面会调用BeanDefinitionRegistryPostProcessor#postProcessBeanFactory方法，因为BeanDefinitionRegistryPostProcessor继承了BeanDefinitionPostProcessor，那么BeanDefinitionRegistryPostProcessor实现了BeanFactoryPostProcessor#postProcessBeanFactory方法的实例将会被调用；
处理容器中实现了BeanFactoryPostProcessor接口的实例
入参的beanFactoryPostProcessor和容器中所有BeanDefinitionRegistryPostProcessor处理完，最后，处理实现了容器中实现了BeanFactoryPostProcessor接口的实例，通过类型匹配查找实例的beanName，处理逻辑跟上面类似；
实现了PriorityOrdered接口的BeanFactoryPostProcessor的实例存放到priorityOrderedPostProcessors；
实现了Ordered接口的BeanFactoryPostProcessor的beanName存放到orderedPostProcessorNames；
没有实现PriorityOrdered,Ordered接口的BeanFactoryPostProcessor的beanName存放到nonOrderedPostProcessorNames；
后面就是跟之前逻辑一样，排序，之后执行对应的后置处理器；
调用clearMetadataCache
最后，调用clearMetadataCache清理merged beanDefinitionMap（这里是为了后面的beanDefinition的合并操作），以及allBeanNamesByType缓存；