摘要：問題今天小伙伴跑過來說，搭建框架的時候出現配置好的信息不能夠及時注入到實體類中的情況。他通過實踐發現，加載的時候，通過注入的實體類里面沒有值。等到容器加載完成后，在層注入的是有數據的，搞了接近一天。表明當前依賴于另外一個，可以用來控制順序。

今天小伙伴跑過來說，搭建框架的時候出現disconf配置好的信息不能夠及時注入到實體類中的情況。他通過實踐發現，spring 加載Configuration 的時候，通過@Autowired注入的RedisProperties 實體類里面沒有值。等到容器加載完成后，在Controller 層注入的RedisProperties是有數據的，搞了接近一天。我在他控制臺看到了如下信息（簡化）：

**** DISCONF START FIRST SCAN ****
//此處省略
**** DISCONF END FIRST SCAN ****
//@configuration 注冊bean的信息（可以自己添加日志）
**** DISCONF START SECOND SCAN ****
//此處省略
**** DISCONF END SECOND SCAN ****

通過信息可以看出，關鍵問題出現在了第二次掃描在Bean注冊之后。第二次掃描負責將配置注入實體類中，詳細可以參考disconf-client設計

那么第二次掃描在什么時候進行的呢，打開DisconfMgrBeanSecond 類

public class DisconfMgrBeanSecond{
    public void init(){
        DisconfMgr.getInstance().secondScan(); //此處進行第二次掃描
    }
    public void destroy(){
        DisconfMgr.getInstance().close();
    }
}

現在的問題一下明了了，我們需要做的也就是將 DisconfMgrBeanSecond 的Bean注冊提前，提前至@Configuration之前。我這里用的是@DependsOn注解，將其放在Properties實體類上。表明當前Bean依賴于另外一個Bean，可以用來控制順序。

上面的方法只是使用技巧解決了實際問題，我們不禁要思考了，spring加載的順序到底是怎么樣的？為什么有的項目沒有加載順序問題，有的就會出bug。接下來我們就來深入擼一下spring的源碼。（本文基于的源碼為 spring boot 2.0.0.RELEASE）

很多人不太會調試源碼，一上手就從入口函數開始，點幾下就自己犯暈了。還有些人習慣看類圖，從全局去看，也會很累。這里不是說類圖方式不好，而是分情況而定。比如你讀 Java 集合框架，類圖就是一個不錯的選擇，一來集合類功能相對獨立，二來集合本身很符合面向對象的思想。面對spring這種名字很相似，代碼龐大的大型框架時，建議還是以點入面，有目的的去看。這里介紹一下我自己使用的方法：

編寫測試工程，比如我要理解spring @Configuration的加載過程，先用spring boot 快速搭建一個可以運行的工程

在自己需要了解的地方打斷點

觀察調用棧，找到關鍵方法

如下圖

Debugger 菜單欄中我們很容易找到調用棧的信息，觀察這些方法，我們可以看到這三個方法的方法名很像我們想知道的加載過程

在仔細點開源碼會發現 refresh()方法下的如下代碼

                this.postProcessBeanFactory(beanFactory); //上下文子類對beanFactory進行后置處理
                this.invokeBeanFactoryPostProcessors(beanFactory);//調用工廠處理器，對bean進行注冊
                this.registerBeanPostProcessors(beanFactory); // 注冊bean的攔截處理器
                this.initMessageSource(); //初始化消息源
                this.initApplicationEventMulticaster(); //初始化上下文事件多播器
                this.onRefresh(); //初始化其他子類上下文的特殊beans
                this.registerListeners(); //檢查監聽類的bean,并注冊他們
                this.finishBeanFactoryInitialization(beanFactory); //實例化剩余非懶加載的bean單利
                this.finishRefresh(); //完成后刷新，發布相應的事件

如果你通過idea把源碼下載下來的話，可以看到光標停在 this.finishBeanFactoryInitialization(beanFactory)處，表明此時具體進入的方法。好了，調試方法暫時就說到這里，還是來看源碼吧。

上面提了一下@Configuration注解的bean 入口在finishBeanFactoryInitialization(beanFactory)方法中，接著往下走到preInstantiateSingletons()方法中

我們發現這個方法里有一個特別顯眼的屬性，beanDefinitionNames，這個就是容器的注冊順序。

我們端點是打在了Test類初始化的地方，但通過debugger 可以發現入口方法加載的反而是TestController類，并且中間方法的調用并沒有出現HelloServiceimpl類和TestServiceImpl類的加載。可見真實bean初始化的順序并不是這樣的。

回頭去找 beanDefinitionNames在哪里初始化的，可以發現在registerBeanDefinition(String beanName, BeanDefinition beanDefinition)方法中，循環添加的，接下來再去找registerBeanDefinition 在什么地方調用。

再次打斷點定位到 ClassPathBeanDefinitionScanner.doscan() 方法上

protected Set doScan(String... basePackages) {
        Assert.notEmpty(basePackages, "At least one base package must be specified");
        Set beanDefinitions = new LinkedHashSet<>();
        for (String basePackage : basePackages) {
            //掃描package,尋找候選組件
            Set candidates = findCandidateComponents(basePackage);
            //候選組件進行處理，處理其他注解
            for (BeanDefinition candidate : candidates) {
                ScopeMetadata scopeMetadata = this.scopeMetadataResolver.resolveScopeMetadata(candidate);
                candidate.setScope(scopeMetadata.getScopeName());
                String beanName = this.beanNameGenerator.generateBeanName(candidate, this.registry);
                if (candidate instanceof AbstractBeanDefinition) {
                    postProcessBeanDefinition((AbstractBeanDefinition) candidate, beanName);
                }
                if (candidate instanceof AnnotatedBeanDefinition) {
                    AnnotationConfigUtils.processCommonDefinitionAnnotations((AnnotatedBeanDefinition) candidate);
                }
                if (checkCandidate(beanName, candidate)) {
                    BeanDefinitionHolder definitionHolder = new BeanDefinitionHolder(candidate, beanName);
                    definitionHolder =
                            AnnotationConfigUtils.applyScopedProxyMode(scopeMetadata, definitionHolder, this.registry);
                    beanDefinitions.add(definitionHolder);
                    registerBeanDefinition(definitionHolder, this.registry);
                }
            }
        }
        return beanDefinitions;
    }

首先通過掃描找出候選組件，掃描的范圍包含basePackages目錄下的所有class文件，如果符合條件，將其放在LinkedHashSet中，使其保證唯一有序。判斷條件在ClassPathScanningCandidateComponentProvider.isCandidateComponent()方法中。這個類有兩個屬性，excludeFilters和includeFilters，分別控制著候選類的排除鏈和包含鏈。我debugger不進行設置的話，默認選取下面三種接口子類作為候選加載類，org.springframework.stereotype.Component，javax.annotation.ManagedBean，javax.inject.Named，而@Configuration，@Controller，@Service，@Repository，都是基于Component的注解。

上面只是說明白了類文件的注冊順序，他是通過掃描包名，類名這樣排下來的，只是一個初步順序。

先來看一下之前調試的初步順序 testConfig-->helloController-->testController-->helloServiceImpl-->testServiceImpl-->test

整體看下來，他是按照包名和類型排序的，只不過有一點需要注意 test 所在的包實際上是在Impl 前面的，且Test類上沒有任何注解，這表明他們的注冊順序其實是：先掃描Component，在掃描@Bean注解。

當bean真正加載的時候是這樣加載的，每加載一個類，看他有沒有依賴，有的話同時加載依賴bean。這也就解釋了為什么testController為什么跳過impl 直接加載test。

其實有很多方法控制順序，依賴注入提前，@DepensOn 和 @Order注解，實現Ordered接口等等。像面對disconf這種第三方框架類的bean，最好是使用@DepensOn 來控制加載順序

bean的加載還有很多其他的細節，這里就不一一展開了。本文主要專注加載順序，順便聊一下初學如何去看源碼。總結起來就是一句話，小目標，不拓展。

寫到最后才發現上面的問題，加載順序并不是主要原因！！(°?°?) 好吧，下次一定搞清楚了再動筆，這里也買一個關子，感興趣的童鞋可以自己Debugger找一下原因。這里給個小提示，是跟代理有關。