在 Java 的世界中，我們知道 Spring 是當下最主流的開發框架，沒有之一。而在使用 Dubbo、MyBatis 等開源框架時，我們發現可以采用和 Spring 完全一樣的方式來使用它們。

圖 1 基于統一的方法使用不同的框架

可能你平時使用時，并沒有意識到這一點，但仔細想一想，你會覺得這是一件比較神奇的事情。本來就是不同的框架，怎么能夠無縫地集成在一起呢？這就是今天我們要討論的話題。Spring 為我們內置了一組功能非常強大的啟動擴展點。通過這些啟動擴展點，可以實現我們想要的集成效果。

系統初始化

我們先來看兩個非常常見的 Spring 啟動擴展點 InitializingBean 和 DisposableBean。在 Spring 中，這兩個擴展點分別作用于 Bean 的初始化和銷毀階段，開發人員可以通過它們實現一些定制化的處理邏輯。

顧名思義，InitializingBean 用于初始化 Bean，接口定義如下：

public interface InitializingBean {
    void afterPropertiesSet() throws Exception;
}

我們看到 InitializingBean 接口只有一個方法，即 afterPropertiesSet。從命名上看，這個方法應該作用于屬性被設置之后。也就是說，這個方法的初始化會晚于屬性的初始化。

實際上，InitializingBean 只是 Spring 初始化時可以采用的其中一個擴展點。與 InitializingBean 類似的一種機制是 InitMethod。我們知道在 Spring 中可以配置 Bean 的 init-method 屬性，具體使用方式是這樣的：

<bean class="com.xiaoyiran.springinitialization. TestInitBean" init-method="initMethod"></bean>

這兩種 Spring 初始化擴展機制都非常常見，我們在閱讀 Dubbo、MyBatis、Spring Cloud 等框架源碼時會經常遇到。那么，這里就有一個問題，既然它們都能對初始化過程做一定的控制，執行順序是怎么樣的呢？我們通過一個示例來分析各個機制的執行順序，示例代碼如下所示：

public class TestInitBean implements InitializingBean {
    public TestInitBean (){
        System.out.println("constructMethod");
    }
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("afterPropertiesSet");
    }
    public void initMethod() {
        System.out.println("initMethod");
    }
}

上述示例的執行結果如下所示：

constructMethod
afterPropertiesSet
initMethod

顯然，基于以上結果，我們可以得出這三者生效的先后順序。

圖 2 三種初始化方法的執行順序

結論已經有了，我們簡單地對這個結論做一個源碼分析。在 Spring 中，我們找到 AbstractAutowireCapableBeanFactory 的 initializeBean 方法，這個方法完成了我們提到的相關操作。在表現形式上，我們對這個方法上做一些簡化，可以得到這樣的代碼結構：

protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
     //執行 Aware 方法
 invokeAwareMethods(beanName, bean);
    Object wrappedBean = bean;
    //在初始化之前執行 PostProcessor 方法
    wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
     //執行初始化方法
    invokeInitMethods(beanName, wrappedBean, mbd);
    //在初始化之后執行 PostProcessor 方法
    wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
    return wrappedBean;
}

你可以看一下圖 3，是這段代碼的執行流程。我們先執行 Aware 方法，然后在初始化之前執行 PostProcessor 方法，接著執行初始化方法，最后在初始化之后執行 PostProcessor 方法。

圖 3 initializeBean 執行流程

我們來看這里的 invokeInitMethods 方法。從命名上看，這個方法的作用是調用一批初始化方法，我們繼續對這個方法的代碼結構做一些簡化調整，以便我們理解。

protected void invokeInitMethods(String beanName, final Object bean, RootBeanDefinition mbd) throws Throwable {
         boolean isInitializingBean = (bean instanceof InitializingBean);
         //判斷是否實現 InitializingBean 接口
         if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
              //直接調用 afterPropertiesSet 方法
              ((InitializingBean) bean).afterPropertiesSet();
         }
         if (mbd != null) {
              String initMethodName = mbd.getInitMethodName();
              if (initMethodName != null && !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&!mbd.isExternallyManagedInitMethod(initMethodName)) {
                    //執行自定義的 init-method
                    invokeCustomInitMethod(beanName, bean, mbd);
               }
         }
  }

可以看到，這里我們首先判斷當前 Bean 是不是一個 InitializingBean 接口的實例，如果是就直接調用它的 afterPropertiesSet 方法，我們再根據 Bean 的定義獲取它的 init-method 屬性，如果設置了這個屬性，那么就調用一個 invokeCustomInitMethod 方法。這個方法會找到 init-method 屬性并執行指定的方法。因為在代碼執行流程上的前后順序，決定了 afterPropertiesSet 方法在 init-method 之前被觸發。

Aware 機制

我們在前面的執行流程圖中還看到了一個 invokeAwareMethods 方法。這個 invokeAwareMethods 就涉及了接下來我們要介紹的 Spring 中提供的 Aware 系列擴展機制。

在 Spring 中，Aware 接口是一個空接口，但卻有一大批直接或間接的子接口。我們以常見的 ApplicationContextAware 接口為例來說明問題。

public interface ApplicationContextAware extends Aware {
      void setApplicationContext(ApplicationContext applicationContext) throws BeansException;
}

ApplicationContextAware 的使用方法非常簡單，我們可以直接使用它提供的 setApplicationContext 方法，把傳入的 ApplicationContext 暫存起來使用。通過這種方法，我們就可以獲取上下文對象 ApplicationContext。一旦獲取了 ApplicationContext，那么我們就可以對 Spring 中所有的 Bean 進行操作了。

圖 4 ApplicationContextAware 的效果圖

事實上，各種 Aware 接口中都只有一個類似 setApplicationContext 的 set 方法。如果一個 Bean 想要獲取并使用 Spring 容器中的相關對象，我們就不需要再次執行重復的啟動過程，而是可以通過 Aware 接口提供的這些方法直接引入相關對象即可。

Dubbo 基于啟動擴展點集成 Spring 原理分析

了解了 Spring 內置的系統初始化方法和 Aware 機制，接下來我們基于具體的開源框架分析一下，怎么和 Spring 完成啟動過程的無縫集成。今天，我們討論的對象是非常經典的分布式服務框架 Dubbo。

Dubbo 服務器端啟動過程分析

在 Dubbo 中，負責執行服務器端啟動的是 ServiceBean。我們先來看 ServiceBean 這個 Bean 的類定義以及主體代碼結構。

public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener<ContextRefreshedEvent>, BeanNameAware {
         public void afterPropertiesSet() {}
         ...
         public void setApplicationContext(ApplicationContext applicationContext) {}
         ...
         public void setBeanName(String name) {}
         ...
         public void onApplicationEvent(ApplicationEvent event) {}
         ...
         public void destroy() {}
}

可以看到 ServiceBean 實現了 Spring 的 InitializingBean、DisposableBean ApplicationContextAware 和 ApplicationListener 等接口，重寫了 afterPropertiesSet、destroy、setApplicationContext、onApplicationEvent 等方法。這些方法就是 Dubbo 和 Spring 整合的關鍵，我們在自己實現與 Spring 框架的集成時，通常也會使用這些方法。

我們先來關注一下 ServiceBean 中實現 InitializingBean 接口的 afterPropertiesSet 方法，這個方法非常長，但結構并不復雜，你可以看一下這個方法的結構。

public void afterPropertiesSet(){
         getProvider();
         getApplication()
         getModule();
         getRegistries();
         getMonitor();
         getProtocols();
         getPath();
         if (!isDelay()) {
              export();
         }
}

這個代碼結構中的 getProvider、getApplication、getModule、getMonitor 等方法的執行邏輯和流程基本一致。以 getProvider 方法為例，Dubbo 首先會從配置文件中讀取 dubbo:provide 配置項。顯然，Provider、Application 和 Module 在 Dubbo 中應該只能出現一次。通過執行上述的 afterPropertiesSet 方法，相當于在 Dubbo 框架啟動的同時，執行了 Spring 容器的初始化過程，并把從這里獲取的一組 Dubbo 對象加載到了 Spring 容器中。

而 ServiceBean 也實現了 Spring 的 ApplicationContextAware 接口，所以我們不難想象存在這樣的 setApplicationContext 方法。

@Override
public void setApplicationContext(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
        SpringExtensionFactory.addApplicationContext(applicationContext);
}

可以看到，Dubbo 通過這個方法獲取了 ApplicationContext，然后通過自己的 SpringExtensionFactory 工廠類把上下文對象保存到了框架內部，方便后續使用。

Dubbo 客戶器端啟動過程分析

有了 Dubbo 服務器端的基礎后，我們再看 Dubbo 的客戶端就會變得更簡單明了。Dubbo 的客戶端啟動方法需要參考 ReferenceBean 類。

public class ReferenceBean<T> extends ReferenceConfig<T> implements FactoryBean, ApplicationContextAware, InitializingBean, DisposableBean {
}

可以看到，ReferenceBean 實現了 Spring 提供的 FactoryBean、ApplicationContextAware、InitializingBean 和 DisposableBean 這四個擴展點。這次，我們先挑最簡單的進行介紹。FactoryBean 和 ApplicationContextAware 接口實現非常簡單，setApplicationContext 方法只是把傳入的 applicationContext 同時保存在 ReferenceBean 內部以及 SpringExtensionFactory 中。

接下來，我們看一下 InitializingBean 接口的 afterPropertiesSet 方法，這個方法同樣非常長，但結構也不復雜，而且與 ServiceBean 中的 afterPropertiesSet 方法結構比較對稱。這里，我們不再給出這個方法的主體代碼結構，而是直接來到末端，找到方法中最核心的代碼。

getObject();

這個 getObject 方法，實際上并不是 ReferenceBean 自身的代碼，而是實現了 FactoryBean 接口的同名方法。這里的 FactoryBean 接口，我們前面沒有介紹過，你可以看一下它的定義：

public interface FactoryBean<T> {
         T getObject() throws Exception;
         Class<?> getObjectType();
         boolean isSingleton();
}

實際上，FactoryBean 是 Spring 框架中非常核心的一個接口，負責從容器中獲取具體的 Bean 對象。我們重點來看 ReferenceBean 中的 getObject 方法，這個方法又調用了 ReferenceBean 的父類 ReferenceConfig 中的 get 方法。

public synchronized T get() {
        if (destroyed) {
            throw new IllegalStateException("Already destroyed!");
        }
        if (ref == null) {
            init();
        }
        return ref;
}

很明顯，這里的核心應該是 init 方法。這個 init 方法和 ServiceConfig 中的 export 方法一樣，做了非常多的準備和校驗工作，最終得到了這行代碼。

ref = createProxy(map);

顧名思義，用 createProxy 方法來創建代理對象；通過代理對象，客戶端訪問遠程服務就像在調用本地方法一樣。到這里，Dubbo 客戶端啟動過程也介紹完畢。

總結

作為系統啟動和初始化相關的常見擴展點，今天我們介紹的 InitializingBean 接口和 Aware 系列接口可以說應用非常廣泛。我們發現主流的 Dubbo、MyBatis 等框架都是基于這些擴展性接口完成與 Spring 框架的整合的。如果我們需要實現與 Spring 框架的集成和擴展，這些接口是必須要掌握的內容。建議你在日常開發過程中，多關注這些接口的應用場景和方式，并根據情況集成到自己的代碼當中。