Spring原始碼解讀之BeanFactoryPostProcessor的處理

前言

    前段時間旁聽了某課堂兩節Spring原始碼解析課，剛好最近自己又在重新學習中，便在這裡記錄一下學習所得。我之前寫過一篇博文，是介紹BeanFactoryPostProcessor跟BeanPostProcessor是如何發揮作用的，當時覺得講的還行，但是現在看來，太粗劣了，很多地方沒涉及到，而且重點都被我忽略了，簡直就是蠢得不行。現在就用這篇文章彌補一下前文中對BeanFactoryPostProcessor的講解，爭取把重點講到，至於BeanPostProcessor，由於涉及到的東西太多，限於本人目前的水平只能作罷，待後面感悟成熟了再來補充。

我們以AnnotationConfigApplicationContext為例來構建測試類，先附上此次打斷點除錯的三個簡約到極致的測試類：

public class SpringTest {

    public static void main(String[] args) {
        // 從這兩行程式碼，實地跟蹤考察Spring中的流程
        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(ScanConfig.class);
        applicationContext.getBean(Teacher.class).teach();
    }
}

package myPackage;
import org.springframework.stereotype.Service;

@Service
public class Teacher {
    public Teacher () {
        System.out.println("Teacher init");
    }
    public void teach () {
        System.out.println("teach");
    }
}

package myPackage;
import org.springframework.context.annotation.ComponentScan;

@ComponentScan("myPackage")
public class ScanConfig {
}

1、洞悉啟動容器時的準備工作

熟悉一些Spring的道友應該都知道，refresh方法中的invokeBeanFactoryPostProcessors方法實現了對BeanFactoryPostProcessor實現類的處理。大家如果只看invokeBeanFactoryPostProcessors方法的話，不會發現有何異常之處，此方法雖然較長，但是處理邏輯很清晰，先對重寫了BeanFactoryPostProcessor的子介面BeanDefinitionRegistryPostProcessor方法的實現類進行處理，後對重寫了BeanFactoryPostProcessor的方法的實現類做了處理。但是如果心細的話，你會發現問題，Spring是如何將@ComponentScan("myPackage")註解發揮作用的？這時帶著這樣的問題，我們再回過頭來看容器的構造方法，就會在這平實的表面下發現意想不到的 "殺機"。

public AnnotationConfigApplicationContext(Class<?>... annotatedClasses) {
        this();
        register(annotatedClasses);
        refresh();
    }

通過這個構造方法可以知道，在第二行將我們的測試類ScanConfig 註冊進了容器中，但這只是註冊，註冊之後是如何呼叫如何實現了@ComponentScan("myPackage")這個註解的包掃描的呢？這時我們將目光鎖定this()方法。點進去後發現是這樣的：

public AnnotationConfigApplicationContext() {
        this.reader = new AnnotatedBeanDefinitionReader(this);
        this.scanner = new ClassPathBeanDefinitionScanner(this);
    }

在第二行新建reader物件時，呼叫了這個構造方法：

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);
    }

其中的第六行，最終呼叫了AnnotationConfigUtils#registerAnnotationConfigProcessors方法，而就是在這個方法中完成了對多個重要Bean的註冊，跟我們關係比較大的有以下幾個：

        // BeanDefinitionHolder只是存放BD的，裡面有三個屬性：BD物件、beanName以及別名組成的String[]
        Set<BeanDefinitionHolder> beanDefs = new LinkedHashSet<BeanDefinitionHolder>(4);
        // 註冊最關鍵的類，對應的類為ConfigurationClassPostProcessor，父類的父類是BeanFactoryPostProcessor
        if (!registry.containsBeanDefinition(CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME)) {
            RootBeanDefinition def = new RootBeanDefinition(ConfigurationClassPostProcessor.class);
            def.setSource(source);
            // 將BD注入進容器中，沒經過什麼處理，只是放入了DefaultListableBeanFactory中的beanDefinitionMap跟存放beanName的list中
            beanDefs.add(registerPostProcessor(registry, def, CONFIGURATION_ANNOTATION_PROCESSOR_BEAN_NAME));
        }
        // 此類實現了BeanPostProcessor，用於處理@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));
        }
        // 此類也實現了BeanPostProcessor，用於處理有@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));
        }

其中第一個對應的類就是我們重點關注的物件 ConfigurationClassPostProcessor類，檢視此類的組成，發現它實現了BeanDefinitionRegistryPostProcessor介面，而此介面正是BeanFactoryPostProcessor的子介面。此時，縈繞在我們心頭的迷霧開始漸漸散開，我們彷彿能抓到一閃而過的邏輯走向，現在讓我們帶著之前的發現，進入正主invokeBeanFactoryPostProcessors方法中一探究竟。

2、invokeBeanFactoryPostProcessors

該方法位於AbstractApplicationContext的refresh方法中，如下所示：

 1 public void refresh() throws BeansException, IllegalStateException {
 2         synchronized (this.startupShutdownMonitor) {
 3             // Prepare this context for refreshing.
 4             prepareRefresh();
 5 
 6             // Tell the subclass to refresh the internal bean factory.
 7             ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
 8 
 9             // Prepare the bean factory for use in this context.
10             prepareBeanFactory(beanFactory);
11 
12             try {
13                 // Allows post-processing of the bean factory in context subclasses.
14                 postProcessBeanFactory(beanFactory);
15 
16                 // Invoke factory processors registered as beans in the context. 
17                 invokeBeanFactoryPostProcessors(beanFactory);

即第17行呼叫的方法。初學者看到這個方法的內部實現時，會發現此方法無外乎是找到所有實現了BeanDefinitionRegistryPostProcessor跟BeanFactoryPostProcessor介面的類，按照優先順序（實現了PriorityOrdered介面的先於實現了Ordered介面，前兩者均先於未實現的，且同一類中按照getOrder方法返回值排優先順序）順序執行它們的重寫方法，先執行BeanDefinitionRegistryPostProcessor的重寫方法，再執行BeanFactoryPostProcessor的重寫方法，很容易理解的邏輯。但是現在我們是帶著前面準備工作中得到的線索來的，此時再看，就能透過這個方法樸實的外表發現它潛藏的凶險，它如平地一聲雷般讓人猛地驚出一身冷汗。

我們打斷點進入PostProcessorRegistrationDelegate類中的下面方法中

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

先略過開始對手動新增進去的beanFactoryPostProcessors處理邏輯，看後面的部分程式碼（由於此方法程式碼較多，此處就不全部貼上出來了，因為邏輯很好理解，所以只貼上重點）：

            String[] postProcessorNames =
                    beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);

            // First, invoke the BeanDefinitionRegistryPostProcessors that implement PriorityOrdered.
            List<BeanDefinitionRegistryPostProcessor> priorityOrderedPostProcessors = new ArrayList<BeanDefinitionRegistryPostProcessor>();
            // 1.2 先處理實現了PriorityOrdered的類
            for (String ppName : postProcessorNames) {
                if (beanFactory.isTypeMatch(ppName, PriorityOrdered.class)) {
                    // 此處通過getBean來生成ConfigurationClassPostProcessor例項物件
                    priorityOrderedPostProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
                    processedBeans.add(ppName);
                }
            }
            // 就一個物件，有啥好排序的
            sortPostProcessors(beanFactory, priorityOrderedPostProcessors);
            registryPostProcessors.addAll(priorityOrderedPostProcessors);
            // 執行ConfigurationClassPostProcessor中的重寫方法postProcessBeanDefinitionRegistry，會將所有加了註解的類註冊到容器中
            // 此處才是整個invokeBeanFactoryPostProcessors方法的核心所在，需要詳述 下面進入ConfigurationClassPostProcessor中的postProcessBeanDefinitionRegistry中一探究竟
            invokeBeanDefinitionRegistryPostProcessors(priorityOrderedPostProcessors, registry);

debug到第一行的時候，會發現此處獲取到的postProcessorNames 中只有一個值，就是前面準備工作中通過硬編碼往容器裡註冊的ConfigurationClassPostProcessor類。下面的邏輯就是進行各種判斷，最後在第19行完成了對ConfigurationClassPostProcessor中postProcessBeanDefinitionRegistry方法的呼叫。

就是在這個後置處理方法中，完成了@ComponentScan("myPackage")中對包的掃描，完成了所有Bean的註冊。執行完這個方法後，你會發現beanDefinitionMap中所有應該容器管理的類全都齊活了，包括其他的後置處理器。這樣，後面繼續呼叫beanFactory.getBeanNamesForType方法時，獲取到的是所有滿足條件的類，後面的工作就會有條不紊的開展下去了。

總結

    本文著重追溯了BeanFactoryPostProcessor及其子介面是如何在Spring中發揮作用的。先通過Spring初始化容器時註冊進去的ConfigurationClassPostProcessor類觸發對其他類的掃描，待全部註冊進容器後，再從容器中取對應的BeanFactoryPostProcessor及其子介面的實現類，逐一對重寫方法進行呼叫。

雖然魔鬼在細節，但這也正是解讀原始碼的快樂之處，不是嗎？