面試官問我什么是擴展自適應機制

當時留了個坑，現(xiàn)在填上。

這行代碼是要通過擴展實現(xiàn)類 set 方法上的參數(shù)找到擴展點要注入的對象，而這個 objectFactory 就是自適應擴展代理類。

Dubbo 中的注入相對 Spring 而言比較復雜，因為有可能需要注入的是 Dubbo 中其它自適應擴展對象，也有可能注入的是 Spring Bean，或者是我們自行定義的容器里面的對象等等。

所以依賴注入的對象需要去多處查找，因此加了一層，搞了個自適應代理擴展類。

在 Dubbo 中的 ExtensionFactory (擴展工廠，從工廠中查找要注入的對象)有三個實現(xiàn)：

• SpringExtensionFactory：從 Spring 容器中去加載 Extension
• SpiExtensionFactory：Dubbo 自己的SPI 去加載 Extension
• AdaptiveExtensionFactory: 自適應的 AdaptiveExtensionLoader，也就是我們上面提到的代理類，由人工編寫的。

ExtensionLoader 中的 objectFactory 用的就是 AdaptiveExtensionFactory 這個實現(xiàn)類了，咱們跑起來打個斷點看看。

嗯，確實是，還能看到 AdaptiveExtensionFactory 的成員變量 factories 還保存了另外兩個工廠。

我們來簡單地看下 AdaptiveExtensionFactory 。

這個工廠會先去加載所有 ExtensionFactory 的擴展類，然后查找 Extension 的時候會遍歷每個 ExtensionFactory 實現(xiàn)類去找要注入的對象，找到了就返回。

所以 Dubbo 就是通過這種方式來實現(xiàn) IOC 的注入，很粗暴簡單，每個工廠遍歷過去查找需要注入的對象。

好了，填了之前文章 Dubbo IOC 的坑，也講了下 @Adaptive 修飾類的情況（就是直接把這個類作為代理類）。

接下來要講講修飾方法的情況，相對而言比修飾類要復雜。

不過也不難，無非就是多了幾步，要用字節(jié)碼工具生成代理類的源碼，然后編譯成 Java 字節(jié)碼，然后加載到 JVM 中，就是這樣。

我們來看看源碼，入口就是 getAdaptiveExtension 方法。

那個 cachedApaptiveClass 就是 SPI 掃描對應文件夾加載類的時候記錄的。

結合上面兩個代碼圖就知曉為什么類上標注 @Adaptive 的時候直接就用那個類，不然就需要框架生成代理類了。

我們再來看看框架生成的代碼是怎樣的。

我們看的是 Protocol （協(xié)議接口，Dubbo 支持很多協(xié)議，默認dubbo協(xié)議）的自適應擴展代碼，我們先看下 Protocol 這個接口的定義，然后再看看生成的代碼。

如何生成上面 code 內容的方法我就不分析了，反正就是各種判斷然后字符串拼接而成的，至于編譯之前也提到了，Dubbo 默認選的是 javassist。

至此整個自適應邏輯擴展已經很清晰了，然后上完整 SPI 的圖，相信看了圖之后整個流程就了然于心了！

Dubbo 中的 Activate

再提一提 @Activate ，這個就不進行源碼分析了，此注解是用來實現(xiàn)自動激活特性的。

主要的參數(shù)是：

• group：表明類得在 Provider 端被激活還是在 Consumer 端被激活。
• value：URL 參數(shù)上出現(xiàn)指定的值被激活。
• order：擴展激活類之間的排序。

簡單地說就是標注了這個注解的擴展會被記錄，然后調用的時候根據(jù)參數(shù)來選取合適的擴展實現(xiàn)類。

比如參數(shù)的 group 和當前擴展類的 group 匹配，出現(xiàn)了指定的 key ，然后就會被激活。

對于 Filter 或者一些 Listener 來說比較有用，用來同時加載多個實現(xiàn)類，再看下官網(wǎng)的例子已經就比較清楚了。

最后

Dubbo SPI 內容算完結了，源碼分析其實不適合在公眾號看，所以建議摸魚的時候偷偷在電腦上打開看。

為了能讓大家更好的理解，我已經做了標紅的注釋和畫圖了，不知道效果如何。

反正源碼肯定是枯燥的，但是不管是為了深入學習還是為了應付面試，看源碼這一步是一定要走的。

等 Dubbo 系列寫完之后我再整理成 pdf，基本上看來下對 Dubbo 內部還是會有一定的了解的。