目前我們分析的代碼已經到了容器處理相關的SpringBoot原理般码，代碼如下：
public ConfigurableApplicationContext run(String... args) {
//DONE 擴展點 SpringApplicationRunListeners listeners.starting();
//DONE 配置文件的處理和抽象封裝 ConfigurableEnvironment
//容器相關處理
//1)核心就是創(chuàng)建了Context和BeanFactory對象退个，內部初始化了Reader和Scanner,加載了一些內部Bean
context = createApplicationContext();
exceptionReporters = getSpringFactoriesInstances(SpringBootExceptionReporter.class,
new Class[] {ConfigurableApplicationContext.class }, context);
//2) 給容器Context咧纠、BeanFactory設置了一堆屬性和組件，執(zhí)行了initialize/listener的擴展點
//比較重要屬性有：singletonObjects 呐舔、beanDefinitionMap 淑趾、beanFactoryPostProcessors烹棉、applicationListeners
prepareContext(context, environment, listeners, applicationArguments,printedBanner);
//3) TODO 容器關鍵的擴展操作執(zhí)行了攒霹，也是很多容器功能和第三方功能的擴展之處
refreshContext(context);
//其他邏輯
}
已經分析的階段如下圖：
prepareContext()準備完成之后，接下來就是refreshContext()浆洗。容器關鍵的擴展操作執(zhí)行了催束，也是很多容器功能和第三方功能的擴展之處，我們來一起看下吧伏社。
快速摸一下refreshCotenxt的脈絡
refreshCotenxt()方法最終調用了容器的refresh方法抠刺，我們還是先來看下它的脈絡，之后從中間抽絲剝繭的找到重點摘昌。
先來快速的看下它的代碼脈絡：
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
initMessageSource();
// Initialize event multicaster for this context.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
onRefresh();
// Check for listener beans and register them.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
整體由一個try-catch構成,內部有很多個方法組成速妖，看上去讓人找不到重點所在，感覺每個方法都挺重要的聪黎。
我第一次看的時候罕容，每個方法，都分開從脈絡到細節(jié)稿饰，分析锦秒。
最后抓大放小，其實refresh在上面最重要的三個方法是：
invokeBeanFactoryPostProcessors 執(zhí)行了容器擴展點喉镰，自動裝配配置旅择、其他技術的常擴展處
onRefresh 內嵌的web容器啟動，默認是tomcat
finishBeanFactoryInitialization bean的實例化
那么侣姆，本著抓大放小的思想生真，其余的方法不是很重要，這個確認過程就不帶大家一一去展開看每個方法了捺宗。
當然除了核心給大家分析上面這三個方法柱蟀，其他的會順帶提到下，讓大家了解下就行偿凭。
今天我們就來先refresh的看看第一個核心方法做了什么产弹。
invokeBeanFactoryPostProcessors執(zhí)行容器擴展點之前的主要操作
refresh()執(zhí)行到invokeBeanFactoryPostProcessors是非常重要的邏輯派歌，前面的方法大體可以概括如下圖所示：
整個過程中弯囊，不是很重要,用淺藍色標注的內容：
涉及設置了一些無關緊要的值痰哨，startupDate、setSerializationId匾嘱、BeanExpressionResolver等等
也設涉及了基本對象集合的初始化earlyApplicationEvents斤斧、earlyApplicationListeners
也標注了幾個容器注入對象需要特別考慮和忽略的接口等
setignoreDependencyInterface 設置忽略的接口，不會注冊成bean
registerResolvableDependency 指明Spring內部一些接口 默認會注入的容器對象
相對重要一點的點是霎烙，圖中用綠色標注了下：
主要還補充了一些Spring自己的對Bean的擴展點BeanPostProcessor撬讽，Spring默認的BeanPostProcessor，補充一些BeanDefinition悬垃、registerSingleton補充一些內部的對象到集合游昼。
術語普及BeanPostProcessor是什么？
之前BeanFactoryPostProcessor是對容器的擴展尝蠕，主要有一個方法烘豌，可以給容器設置屬性，補充一些單例對象看彼，補充一些BeanDefinition廊佩。
那BeanPostProcessor是對bean的擴展，有before和after兩類方法靖榕，對Bean如何做擴展标锄，在bean的創(chuàng)建前后，給bean補充一些屬性等茁计。
invokeBeanFactoryPostProcessors之前的邏輯料皇，我們快速過一下就好，當中并沒有特別重要的邏輯簸淀，主要是Spring對內部的處理瓶蝴，給容器補充了一堆屬性。
invokeBeanFactoryPostProcessors的核心脈絡
大體了解了invokeBeanFactoryPostProcessors之前的主要操作后租幕，接下來我們核心首先來先看看這個方法的脈絡舷手，看看它主要做了寫什么的？
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()));
}
}
乍一看劲绪，這個方法好像挺簡單的男窟， 只有2段邏輯，你很容易抓到重點
invokeBeanFactoryPostProcessors執(zhí)行擴展點贾富，這個應該是核心觸發(fā)容器的擴展點地方歉眷。
根據條件，補充一個Bean的擴展操作颤枪，BeanPostProcessor汗捡，這個明顯不是啥重點邏輯，之前做過很多類似的操作了。
如下圖所示：
那你深入到PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors這個方法是扇住，你會發(fā)現(xiàn)如下一大坨的代碼：
public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
// Invoke BeanDefinitionRegistryPostProcessors first, if any.
Set<String> processedBeans = new HashSet<>();
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;
registryProcessor.postProcessBeanDefinitionRegistry(registry);
registryProcessors.add(registryProcessor);
}
else {
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.
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
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);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 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();
// 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();
}
// Now, invoke the postProcessBeanFactory callback of all processors handled so far.
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
else {
// Invoke factory processors registered with the context instance.
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!
String[] postProcessorNames =
beanFactory.getBeanNamesForType(BeanFactoryPostProcessor.class, true, false);
// Separate between BeanFactoryPostProcessors that implement PriorityOrdered,
// Ordered, and the rest.
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.
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();
}
這個方法春缕，初看上去的是有一點復雜，但是沒關系艘蹋，你可以先摸清一下它的脈絡：
1）首先主要有一個if-else組成
2）之后是連續(xù)的3個for循環(huán)
如下圖：
好了锄贼，這就是這個方法的核心脈絡了，接下來我們分別來弄清楚女阀，if-else邏輯在做什么宅荤，之后的3個for循環(huán)在做什么，這個方法基本就知道在做什么了浸策。
讓我們來看下第一個if-else在做什么呢冯键？
if-esle核心脈絡邏輯
第一個if-esle核心邏輯主要是判斷了容器是否實現(xiàn)了BeanDefinitionRegistry這個接口，從而決定如何執(zhí)行BeanFactoryPostProcessor的擴展操作庸汗。
BeanDefinitionRegistry這個接口琼了，之前我們普及過，封裝了對BeanDefinition常見操作的接口夫晌，容器默認實現(xiàn)了這個接口雕薪，所以一般它也代表了容器，可以通過實現(xiàn)的方法晓淀，維護容器內List<BeanDefinition>所袁。
代碼如下：
public static void invokeBeanFactoryPostProcessors(
ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {
if (beanFactory instanceof BeanDefinitionRegistry) {
}else {
// Invoke factory processors registered with the context instance.
invokeBeanFactoryPostProcessors(beanFactoryPostProcessors, beanFactory);
}
}
容器默認是實現(xiàn)了BeanDefinitionRegistry接口，正常會執(zhí)行if邏輯凶掰。由于if邏輯相對復雜燥爷，我們先來看下，else邏輯在做什么懦窘，再去理解if邏輯前翎。
else邏輯
else邏輯比較簡單主要就是觸發(fā)了入參中的beanFactoryPostProcessors的擴展方法postProcessBeanFactory(),代碼如下：
private static void invokeBeanFactoryPostProcessors(
Collection<? extends BeanFactoryPostProcessor> postProcessors, ConfigurableListableBeanFactory beanFactory) {
for (BeanFactoryPostProcessor postProcessor : postProcessors) {
postProcessor.postProcessBeanFactory(beanFactory);
}
}
疑問：入參中這些內部的BeanFactoryPostProcessor這個是哪里來的？
是通過從容器中的一個屬性 List<BeanFactoryPostProcessor> beanFactoryPostProcessors畅涂。
這個屬性時之前通過listener等擴展點增加進來的一些Spring內部的BeanFactoryPostProcessor港华。主要有如下三個:
beanFactoryPostProcessors = {ArrayList@2882} size = 3
0 = {SharedMetadataReaderFactoryContextInitializer
$CachingMetadataReaderFactoryPostProcessor@2887}
1 = {ConfigurationWarningsApplicationContextInitializer
$ConfigurationWarningsPostProcessor@2888}
2 = {ConfigFileApplicationListener
$PropertySourceOrderingPostProcessor@2889}
我們這里把它們稱之為inernalBeanFactoryPostProcessors
如下圖：
那最終else邏輯其實主要就是觸發(fā)了這些內部BeanFactoryPostProcessor的postProcessBeanFactory()擴展方法而已。整體如下圖所示：
至于這些擴展操作具體做了什么午衰，我們稍后在分析立宜，先整體摸清楚方法脈絡在來看細節(jié)。
if邏輯
了解了else 的邏輯之后臊岸，我們再看下if主要做了什么橙数。因為if-else邏輯，其實默認是不會執(zhí)行的else的帅戒，優(yōu)先執(zhí)行的肯定是if灯帮。
這里要先普及一些概念，才可以更好的理解if的代碼邏輯。
術語普及BeanDefinitionRegistryPostProcessor是什么钟哥？
BeanDefinitionRegistryPostProcessor
也是擴展點响疚，繼承自BeanFactoryPostProcessor，對BeanFactoryPostProcessor增加了一個擴展方法而已瞪醋。
整體設計如下圖所示：
BeanFactoryPostProcessor可以有兩個擴展操作
也就是說，原來的BeanFactoryPostProcessor的擴展方法装诡，從一個增加到了兩個银受，一個是postProcessBeanFactory(),另一個事postProcessBeanDefinitionRegistry()。
另外一個要強調的其實是BeanFactoryPostProcessor來源有兩個
1）容器中鸦采，事先通過擴展點加入的BeanFactoryPostProcessor
2）BeanDefinition中的宾巍，定義的但是沒有實例化的BeanFactoryPostProcessor
如下圖：
BeanFactoryPostProcessor可以有兩個擴展操作、BeanFactoryPostProcessor來源有兩個
這2點很關鍵渔伯，帶著這個知識顶霞，我們再看if邏輯，就會很容易锣吼。
if邏輯主要代碼如下：
if (beanFactory instanceof BeanDefinitionRegistry) {
BeanDefinitionRegistry registry = (BeanDefinitionRegistry) beanFactory;
List<BeanFactoryPostProcessor> regularPostProcessors = new ArrayList<>();
List<BeanDefinitionRegistryPostProcessor> registryProcessors = new ArrayList<>();
for (BeanFactoryPostProcessor postProcessor : beanFactoryPostProcessors) {
if (postProcessor instanceof BeanDefinitionRegistryPostProcessor) {
BeanDefinitionRegistryPostProcessor registryProcessor =
(BeanDefinitionRegistryPostProcessor) postProcessor;
registryProcessor.postProcessBeanDefinitionRegistry(registry);
registryProcessors.add(registryProcessor);
}
else {
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.
List<BeanDefinitionRegistryPostProcessor> currentRegistryProcessors = new ArrayList<>();
// First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
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);
registryProcessors.addAll(currentRegistryProcessors);
invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
currentRegistryProcessors.clear();
// 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();
// 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();
}
// Now, invoke the postProcessBeanFactory callback of all processors handled so far.
invokeBeanFactoryPostProcessors(registryProcessors, beanFactory);
invokeBeanFactoryPostProcessors(regularPostProcessors, beanFactory);
}
這個if邏輯的代碼脈絡选浑，主要的邏輯是有3個for+1while邏輯，其實可以按照擴展操作1和擴展操作2的執(zhí)行劃分開玄叠。
讓我們分別看下古徒。
執(zhí)行擴展方法1：postProcessBeanDefinitionRegistry()
執(zhí)行擴展方法1時，首先就需要分別從兩個來源開始執(zhí)行,而且執(zhí)行的是實現(xiàn)了BeanDefinitionRegistryPostProcessor的BeanFactoryPostProcessor读恃。
主要邏輯可以概括如下圖：
用文字解釋下上圖的話隧膘，就是：
1)容器中，之前增加的內部相關的BeanFactoryPostProcessor有沒有實現(xiàn)這個BeanDefinitionRegistryPostProcessor接口增加了擴展方法postProcessBeanDefinitionRegistry()的寺惫？如果有疹吃，對應的所有BeanFactoryPostProcessor，通過for循環(huán)執(zhí)行這個方法西雀。并且記錄這些執(zhí)行的BeanFactoryPostProcessor和未執(zhí)行的BeanFactoryPostProcessor萨驶。
2)容器中，之前增加的內部相關的BeanDefinition中艇肴，有沒有定義為BeanFactoryPostProcessor的篡撵，如果有，按照實現(xiàn)了PrioriyOrder接口豆挽、Order接口育谬、無Order接口的分別執(zhí)行擴展方法postProcessBeanDefinitionRegistry()，使用了2for循環(huán)+一個while循環(huán)執(zhí)行帮哈，執(zhí)行完成記錄這些BeanFactoryPostProcessor膛檀。
執(zhí)行擴展方法2：postProcessBeanFactory()
之前執(zhí)行擴展方法1的時候記錄的所有BeanFactoryPostProcessor，包括擴展點之前添加的，BeanDefinition定義的咖刃。
我們可以通過記錄的這些BeanFactoryPostProcessor 泳炉，來在執(zhí)行執(zhí)行擴展方法2—postProcessBeanFactory()。
如下圖所示：
整個if-else的邏輯的脈絡嚎杨，我們就摸清楚了花鹅，至于這些擴展操作具體做了什么，我們稍后在分析枫浙，還是先整體摸清楚方法脈絡在來看細節(jié)刨肃。
3個For循環(huán)的核心脈絡邏輯
invokeBeanFactoryPostProcessors的核心脈絡中，除了一個if-else邏輯箩帚，接下來的就是連續(xù)的3次for循環(huán)執(zhí)行真友。
分為主要排序、排序紧帕、無順序要求的BeanFactoryPostProcessor三類盔然，主要執(zhí)行擴展點BeanFactoryPostProcessor的postProcessBeanFactory方法。
這個邏輯聽上去是嗜，其實和之前if-else中的邏輯是很像的愈案。只不過之前執(zhí)行的是BeanDefinitionRegistryPostProcessor。
而且此時的BeanFactoryPostProcessor都來自與BeanDefinition中的鹅搪。
你可能說刻帚，之前已經執(zhí)行過了BeanDefinition中的BeanFactoryPostProcessor了，怎么還有涩嚣？
之前執(zhí)行的是Spring內部定義好的一些BeanFactoryPostProcessor崇众，在執(zhí)行了if-else邏輯后，其實掃描出來了ClassPath下更多第三方和其他的BeanFactoryPostProcessor
這些新掃描出來BeanFactoryPostProcessor航厚，參考之前BeanDefinitionRegistryPostProcessor的執(zhí)行方式顷歌，執(zhí)行了如下的擴展操作：
3個for的邏輯的脈絡，其實并不復雜幔睬，至于這些擴展操作具體做了什么眯漩，既然我們摸清楚了整個方法invokeBeanFactoryPostProcessors的脈絡了，我們下一節(jié)馬上就來分析麻顶。
小結
最后赦抖，簡單小結下，invokeBeanFactoryPostProcessors主要做的就是執(zhí)行BeanDefinitionRegistryPostProcessor辅肾、BeanFactoryPostProcessor的2個擴展方法队萤。這些BeanFactoryPostProcessors可能是內部Spring實現(xiàn)添加好的，也可能是來自ClassPath掃描出來的BeanFactoryPostProcessors矫钓。
這些擴展點具體執(zhí)行了寫什么要尔，有哪些重點操作呢舍杜？我們下一節(jié)一起來仔細看看細節(jié)。我們下節(jié)再見赵辕！
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布既绩！
