2. 程式人生 > >Dubbo擴充套件點載入機制

Dubbo擴充套件點載入機制

阿新 • • 發佈：2019-01-26

概述

來源： 
Dubbo的擴充套件點載入從JDK標準的SPI(Service Provider Interface)擴充套件點發現機制加強而來。

Dubbo改進了JDK標準的SPI的以下問題：

  • JDK標準的SPI會一次性例項化擴充套件點所有實現，如果有擴充套件實現初始化很耗時，但如果沒用上也載入，會很浪費資源。

  • 如果擴充套件點載入失敗，連擴充套件點的名稱都拿不到了。比如：JDK標準的ScriptEngine，通過getName();獲取指令碼型別的名稱，但如果RubyScriptEngine因為所依賴的jruby.jar不存在，導致RubyScriptEngine類載入失敗，這個失敗原因被吃掉了，和ruby對應不起來，當用戶執行ruby指令碼時，會報不支援ruby，而不是真正失敗的原因。

  • 增加了對擴充套件點IoC和AOP的支援，一個擴充套件點可以直接setter注入其它擴充套件點。

約定： 
在擴充套件類的jar包內，放置擴充套件點配置檔案：META-INF/dubbo/介面全限定名，內容為：配置名=擴充套件實現類全限定名，多個實現類用換行符分隔。 
(注意：這裡的配置檔案是放在你自己的jar包內，不是dubbo本身的jar包內，Dubbo會全ClassPath掃描所有jar包內同名的這個檔案，然後進行合併)

擴充套件Dubbo的協議示例： 
在協議的實現jar包內放置文字檔案：META-INF/dubbo/com.alibaba.dubbo.rpc.Protocol，內容為：

xxx=com.alibaba.xxx.XxxProtocol

 實現內容：

  1. package com.alibaba.xxx;

  2. import com.alibaba.dubbo.rpc.Protocol;

  3. public class XxxProtocol implemenets Protocol {

  4. // ...

  5. }

 注意： 擴充套件點使用單一例項載入（請確保擴充套件實現的執行緒安全性），Cache在ExtensionLoader中

特性

  • 擴充套件點自動包裝
  • 擴充套件點自動裝配
  • 擴充套件點自適應
  • 擴充套件點自動啟用

相關文件可以參考dubbo的官方文件 ，本文主要通過分析相關的原始碼來體會dubbo的擴充套件點框架提供的特性。

原始碼分析

dubbo的擴充套件點框架主要位於這個包下：

    com.alibaba.dubbo.common.extension

大概結構如下：

  1. <code>com.alibaba.dubbo.common.extension  
  2.  |  
  3.  |--factory  
  4.  |     |--AdaptiveExtensionFactory   #稍後解釋  
  5.  |     |--SpiExtensionFactory        #稍後解釋  
  6.  |  
  7.  |--support  
  8.  |     |--ActivateComparator  
  9.  |  
  10.  |--Activate  #自動啟用載入擴充套件的註解  
  11.  |--Adaptive  #自適應擴充套件點的註解  
  12.  |--ExtensionFactory  #擴充套件點物件生成工廠介面  
  13.  |--ExtensionLoader   #擴充套件點載入器，擴充套件點的查詢，校驗，載入等核心邏輯的實現類  
  14.  |--SPI   #擴充套件點註解</code>  

 其中最核心的類就是ExtensionLoader，幾乎所有特性都在這個類中實現。

ExtensionLoader沒有提供public的構造方法，但是提供了一個public static的getExtensionLoader，這個方法就是獲取ExtensionLoader例項的工廠方法。其public成員方法中有三個比較重要的方法：

  • getActivateExtension ：根據條件獲取當前擴充套件可自動啟用的實現
  • getExtension ： 根據名稱獲取當前擴充套件的指定實現
  • getAdaptiveExtension : 獲取當前擴充套件的自適應實現

這三個方法將會是我們重點關注的方法；* 每一個ExtensionLoader例項僅負責載入特定SPI擴充套件的實現*。因此想要獲取某個擴充套件的實現，首先要獲取到該擴充套件對應的ExtensionLoader例項，下面我們就來看一下獲取ExtensionLoader例項的工廠方法getExtensionLoader：

  1. public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {

  2. if (type == null)

  3. throw new IllegalArgumentException("Extension type == null");

  4. if(!type.isInterface()) {

  5. throw new IllegalArgumentException("Extension type(" + type + ") is not interface!");

  6. }

  7. if(!withExtensionAnnotation(type)) { // 只接受使用@SPI註解註釋的介面型別

  8. throw new IllegalArgumentException("Extension type(" + type +

  9. ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!");

  10. }

  11. // 先從靜態快取中獲取對應的ExtensionLoader例項

  12. ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);

  13. if (loader == null) {

  14. EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type)); // 為Extension型別建立ExtensionLoader例項，並放入靜態快取

  15. loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);

  16. }

  17. return loader;

  18. }

 該方法需要一個Class型別的引數，該引數表示希望載入的擴充套件點型別，該引數必須是介面，且該介面必須被@SPI註解註釋，否則拒絕處理。檢查通過之後首先會檢查ExtensionLoader快取中是否已經存在該擴充套件對應的ExtensionLoader，如果有則直接返回，否則建立一個新的ExtensionLoader負責載入該擴充套件實現，同時將其快取起來。可以看到對於每一個擴充套件，dubbo中只會有一個對應的ExtensionLoader例項。

接下來看下ExtensionLoader的私有建構函式：

  1. private ExtensionLoader(Class<?> type) {

  2. this.type = type;

  3. // 如果擴充套件型別是ExtensionFactory,那麼則設定為null

  4. // 這裡通過getAdaptiveExtension方法獲取一個執行時自適應的擴充套件型別(每個Extension只能有一個@Adaptive型別的實現，如果沒有dubbo會動態生成一個類)

  5. objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());

  6. }

 這裡儲存了對應的擴充套件型別，並且設定了一個額外的objectFactory屬性，他是一個ExtensionFactory型別，ExtensionFactory主要用於載入擴充套件的實現：

  1. @SPI

  2. public interface ExtensionFactory {

  3. /**

  4. * Get extension.

  5. *

  6. * @param type object type.

  7. * @param name object name.

  8. * @return object instance.

  9. */

  10. <T> T getExtension(Class<T> type, String name);

  11. }

 同時ExtensionFactory也被@SPI註解註釋，說明他也是一個擴充套件點，從前面com.alibaba.dubbo.common.extension包的結構圖中可以看到，dubbo內部提供了兩個實現類：SpiExtensionFactory 和 AdaptiveExtensionFactory，實際上還有一個SpringExtensionFactory，不同的實現可以已不同的方式來完成擴充套件點實現的載入，這塊稍後再來學習。從ExtensionLoader的建構函式中可以看到，如果要載入的擴充套件點型別是ExtensionFactory是，object欄位被設定為null。由於ExtensionLoader的使用範圍有限(基本上侷限在ExtensionLoader中)，因此對他做了特殊對待：在需要使用ExtensionFactory的地方，都是通過對應的自適應實現來代替。

預設的ExtensionFactory實現中，AdaptiveExtensionFactotry被@Adaptive註解註釋，也就是它就是ExtensionFactory對應的自適應擴充套件實現(每個擴充套件點最多隻能有一個自適應實現，如果所有實現中沒有被@Adaptive註釋的，那麼dubbo會動態生成一個自適應實現類)，也就是說，所有對ExtensionFactory呼叫的地方，實際上呼叫的都是AdpativeExtensionFactory，那麼我們看下他的實現程式碼：

  1. @Adaptive

  2. public class AdaptiveExtensionFactory implements ExtensionFactory {

  3. private final List<ExtensionFactory> factories;

  4. public AdaptiveExtensionFactory() {

  5. ExtensionLoader<ExtensionFactory> loader = ExtensionLoader.getExtensionLoader(ExtensionFactory.class);

  6. List<ExtensionFactory> list = new ArrayList<ExtensionFactory>();

  7. for (String name : loader.getSupportedExtensions()) { // 將所有ExtensionFactory實現儲存起來

  8. list.add(loader.getExtension(name));

  9. }

  10. factories = Collections.unmodifiableList(list);

  11. }

  12. public <T> T getExtension(Class<T> type, String name) {

  13. // 依次遍歷各個ExtensionFactory實現的getExtension方法，一旦獲取到Extension即返回

  14. // 如果遍歷完所有的ExtensionFactory實現均無法找到Extension,則返回null

  15. for (ExtensionFactory factory : factories) {

  16. T extension = factory.getExtension(type, name);

  17. if (extension != null) {

  18. return extension;

  19. }

  20. }

  21. return null;

  22. }

  23. }

 看完程式碼大家都知道是怎麼回事了，這貨就相當於一個代理入口，他會遍歷當前系統中所有的ExtensionFactory實現來獲取指定的擴充套件實現，獲取到擴充套件實現或遍歷完所有的ExtensionFactory實現。這裡呼叫了ExtensionLoader的getSupportedExtensions方法來獲取ExtensionFactory的所有實現，又回到了ExtensionLoader類，下面我們就來分析ExtensionLoader的幾個重要的例項方法。

方法呼叫流程

getExtension

  1. <code>getExtension(name)  
  2.     -> createExtension(name) #如果無快取則建立  
  3.         -> getExtensionClasses().get(name) #獲取name對應的擴充套件型別  
  4.         -> 例項化擴充套件類  
  5.         -> injectExtension(instance) # 擴充套件點注入  
  6.         -> instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance)) #迴圈遍歷所有wrapper實現，例項化wrapper並進行擴充套件點注入</code>  

 getAdaptiveExtension

  1. <code>public T getAdaptiveExtension()  
  2.     -> createAdaptiveExtension() #如果無快取則建立  
  3.         -> getAdaptiveExtensionClass().newInstance() #獲取AdaptiveExtensionClass  
  4.             -> getExtensionClasses() # 載入當前擴充套件所有實現，看是否有實現被標註為@Adaptive  
  5.             -> createAdaptiveExtensionClass() #如果沒有實現被標註為@Adaptive，則動態建立一個Adaptive實現類  
  6.                 -> createAdaptiveExtensionClassCode() #動態生成實現類java程式碼  
  7.                 -> compiler.compile(code, classLoader) #動態編譯java程式碼，載入類並例項化  
  8.         -> injectExtension(instance)</code>  

 getActivateExtesion 

該方法有多個過載方法，不過最終都是呼叫了三個引數的那一個過載形式。其程式碼結構也相對剪短，就不需要在列出概要流程了。

詳細程式碼分析

getAdaptiveExtension 
從前面ExtensionLoader的私有建構函式中可以看出，在選擇ExtensionFactory的時候，並不是呼叫getExtension(name)來獲取某個具體的實現類，而是呼叫getAdaptiveExtension來獲取一個自適應的實現。那麼首先我們就來分析一下getAdaptiveExtension這個方法的實現吧：

  1. public T getAdaptiveExtension() {

  2. Object instance = cachedAdaptiveInstance.get(); // 首先判斷是否已經有快取的例項物件

  3. if (instance == null) {

  4. if(createAdaptiveInstanceError == null) {

  5. synchronized (cachedAdaptiveInstance) {

  6. instance = cachedAdaptiveInstance.get();

  7. if (instance == null) {

  8. try {

  9. instance = createAdaptiveExtension(); // 沒有快取的例項，建立新的AdaptiveExtension例項

  10. cachedAdaptiveInstance.set(instance);

  11. } catch (Throwable t) {

  12. createAdaptiveInstanceError = t;

  13. throw new IllegalStateException("fail to create adaptive instance: " + t.toString(), t);

  14. }

  15. }

  16. }

  17. }

  18. else {

  19. throw new IllegalStateException("fail to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError);

  20. }

  21. }

  22. return (T) instance;

  23. }

 首先檢查快取的adaptiveInstance是否存在，如果存在則直接使用，否則的話呼叫createAdaptiveExtension方法來建立新的adaptiveInstance並且快取起來。也就是說對於某個擴充套件點，每次呼叫ExtensionLoader.getAdaptiveExtension獲取到的都是同一個例項。

  1. private T createAdaptiveExtension() {

  2. try {

  3. return injectExtension((T) getAdaptiveExtensionClass().newInstance()); // 先獲取AdaptiveExtensionClass，在獲取其例項，最後進行注入處理

  4. } catch (Exception e) {

  5. throw new IllegalStateException("Can not create adaptive extenstion " + type + ", cause: " + e.getMessage(), e);

  6. }

  7. }

 在createAdaptiveExtension方法中，首先通過getAdaptiveExtensionClass方法獲取到最終的自適應實現型別，然後例項化一個自適應擴充套件實現的例項，最後進行擴充套件點注入操作。先看一個getAdaptiveExtensionClass方法的實現：

  1. private Class<?> getAdaptiveExtensionClass() {

  2. getExtensionClasses(); // 載入當前Extension的所有實現,如果有@Adaptive型別，則會賦值為cachedAdaptiveClass屬性快取起來

  3. if (cachedAdaptiveClass != null) {

  4. return cachedAdaptiveClass;

  5. }

  6. return cachedAdaptiveClass = createAdaptiveExtensionClass(); // 沒有找到@Adaptive型別實現，則動態建立一個AdaptiveExtensionClass

  7. }

 他只是簡單的呼叫了getExtensionClasses方法，然後在判adaptiveCalss快取是否被設定，如果被設定那麼直接返回，否則呼叫createAdaptiveExntesionClass方法動態生成一個自適應實現，關於動態生成自適應實現類然後編譯載入並且例項化的過程這裡暫時不分析，留到後面在分析吧。這裡我們看getExtensionClassses方法：

  1. private Map<String, Class<?>> getExtensionClasses() {

  2. Map<String, Class<?>> classes = cachedClasses.get(); // 判斷是否已經載入了當前Extension的所有實現類

  3. if (classes == null) {

  4. synchronized (cachedClasses) {

  5. classes = cachedClasses.get();

  6. if (classes == null) {

  7. classes = loadExtensionClasses(); // 如果還沒有載入Extension的實現，則進行掃描載入,完成後賦值給cachedClasses變數

  8. cachedClasses.set(classes);

  9. }

  10. }

  11. }

  12. return classes;

  13. }

 在getExtensionClasses方法中，首先檢查快取的cachedClasses，如果沒有再呼叫loadExtensionClasses方法來載入，載入完成之後就會進行快取。也就是說對於每個擴充套件點，其實現的載入只會執行一次。我們看下loadExtensionClasses方法：

  1. private Map<String, Class<?>> loadExtensionClasses() {

  2. final SPI defaultAnnotation = type.getAnnotation(SPI.class);

  3. if(defaultAnnotation != null) {

  4. String value = defaultAnnotation.value(); // 解析當前Extension配置的預設實現名，賦值給cachedDefaultName屬性

  5. if(value != null && (value = value.trim()).length() > 0) {

  6. String[] names = NAME_SEPARATOR.split(value);

  7. if(names.length > 1) { // 每個擴充套件實現只能配置一個名稱

  8. throw new IllegalStateException("more than 1 default extension name on extension " + type.getName()

  9. + ": " + Arrays.toString(names));

  10. }

  11. if(names.length == 1) cachedDefaultName = names[0];

  12. }

  13. }

  14. // 從配置檔案中載入擴充套件實現類

  15. Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();

  16. loadFile(extensionClasses, DUBBO_INTERNAL_DIRECTORY);

  17. loadFile(extensionClasses, DUBBO_DIRECTORY);

  18. loadFile(extensionClasses, SERVICES_DIRECTORY);

  19. return extensionClasses;

  20. }

 從程式碼裡面可以看到，在loadExtensionClasses中首先會檢測擴充套件點在@SPI註解中配置的預設擴充套件實現的名稱，並將其賦值給cachedDefaultName屬性進行快取，後面想要獲取該擴充套件點的預設實現名稱就可以直接通過訪問cachedDefaultName欄位來完成，比如getDefaultExtensionName方法就是這麼實現的。從這裡的程式碼中又可以看到，具體的擴充套件實現型別，是通過呼叫loadFile方法來載入，分別從一下三個地方載入：

  • META-INF/dubbo/internal/
  • META-INF/dubbo/
  • META-INF/services/

那麼這個loadFile方法則至關重要了，看看其原始碼：

private void loadFile(Map<String, Class<?>> extensionClasses, String dir) { String fileName = dir + type.getName(); // 配置檔名稱,掃描整個classpath try { // 先獲取該路徑下所有檔案 Enumeration<java.net.URL> urls; ClassLoader classLoader = findClassLoader(); if (classLoader != null) { urls = classLoader.getResources(fileName); } else { urls = ClassLoader.getSystemResources(fileName); } if (urls != null) { // 遍歷這些檔案並進行處理 while (urls.hasMoreElements()) { java.net.URL url = urls.nextElement(); // 獲取配置檔案路徑 try { BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream(), "utf-8")); try { String line = null; while ((line = reader.readLine()) != null) { // 一行一行讀取(一行一個配置) final int ci = line.indexOf('#'); if (ci >= 0) line = line.substring(0, ci); line = line.trim(); if (line.length() > 0) { try { String name = null; int i = line.indexOf('='); // 等號分割 if (i > 0) { name = line.substring(0, i).trim(); // 副檔名稱 line = line.substring(i + 1).trim(); // 擴充套件實現類 } if (line.length() > 0) { Class<?> clazz = Class.forName(line, true, classLoader); // 載入擴充套件實現類 if (! type.isAssignableFrom(clazz)) { // 判斷型別是否匹配 throw new IllegalStateException("Error when load extension class(interface: " + type + ", class line: " + clazz.getName() + "), class " + clazz.getName() + "is not subtype of interface."); } if (clazz.isAnnotationPresent(Adaptive.class)) { // 判斷該實現類是否@Adaptive,是的話不會放入extensionClasses/cachedClasses快取 if(cachedAdaptiveClass == null) { // 第一個賦值給cachedAdaptiveClass屬性 cachedAdaptiveClass = clazz; } else if (! cachedAdaptiveClass.equals(clazz)) { // 只能有一個@Adaptive實現,出現第二個就報錯了 throw new IllegalStateException("More than 1 adaptive class found: " + cachedAdaptiveClass.getClass().getName() + ", " + clazz.getClass().getName()); } } else { // 不是@Adaptive型別 try { clazz.getConstructor(type); // 判斷是否Wrapper型別 Set<Class<?>> wrappers = cachedWrapperClasses; if (wrappers == null) { cachedWrapperClasses = new ConcurrentHashSet<Class<?>>(); wrappers = cachedWrapperClasses; } wrappers.add(clazz); //放入到Wrapper實現類快取中 } catch (NoSuchMethodException e) { //不是Wrapper型別，普通實現型別 clazz.getConstructor(); if (name == null || name.length() == 0) { name = findAnnotationName(clazz); if (name == null || name.length() == 0) { if (clazz.getSimpleName().length() > type.getSimpleName().length() && clazz.getSimpleName().endsWith(type.getSimpleName())) { name = clazz.getSimpleName().substring(0, clazz.getSimpleName().length() - type.getSimpleName().length()).toLowerCase(); } else { throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + url); } } } String[] names = NAME_SEPARATOR.split(name); // 看是否配置了多個name if (names != null && names.length > 0) { Activate activate = clazz.getAnnotation(Activate.class); // 是否@Activate型別 if (activate != null) { cachedActivates.put(names[0], activate);// 是則放入cachedActivates快取 } // 遍歷所有name for (String n : names) { if (! cachedNames.containsKey(clazz)) { cachedNames.put(clazz, n); // 放入Extension實現類與名稱對映快取,每個class只對應第一個名稱有效 } Class<?> c = extensionClasses.get(n); if (c == null) { extensionClasses.put(n, clazz); // 放入到extensionClasses快取,多個name可能對應一個Class } else if (c != clazz) { // 存在重名 throw new IllegalStateException("Duplicate extension " + type.getName() + " name " + n + " on " + c.getName() + " and " + clazz.getName()); } } } } } } } catch (Throwable t) { IllegalStateException e = new IllegalStateException("Failed to load extension class(interface: " + type + ", class line: " + line + ") in " + url + ", cause: " + t.getMessage(), t); exceptions.put(line, e); } } } // end of while read lines } finally { reader.close(); } } catch (Throwable t) { logger.error("Exception when load extension class(interface: " + type + ", class file: " + url + ") in " + url, t); } } // end of while urls } } catch (Throwable t) { logger.error("Exception when load extension class(interface: " + type + ", description file: " + fileName + ").", t); } }

 程式碼比較長，大概的事情呢就是解析配置檔案，獲取擴充套件點實現對應的名稱和實現類，並進行分類處理和快取。當loadFile方法執行完成之後，以下幾個變數就會被附上值：

  • cachedAdaptiveClass : 當前Extension型別對應的AdaptiveExtension型別(只能一個)
  • cachedWrapperClasses : 當前Extension型別對應的所有Wrapper實現型別(無順序)
  • cachedActivates : 當前Extension實現自動啟用實現快取(map,無序)
  • cachedNames : 擴充套件點實現類對應的名稱(如配置多個名稱則值為第一個)

當loadExtensionClasses方法執行完成之後，還有一下變數被賦值：

  • cachedDefaultName : 當前擴充套件點的預設實現名稱

當getExtensionClasses方法執行完成之後，除了上述變數被賦值之外，還有以下變數被賦值：

  • cachedClasses : 擴充套件點實現名稱對應的實現類(一個實現類可能有多個名稱)

其實也就是說，在呼叫了getExtensionClasses方法之後，當前擴充套件點對應的實現類的一些資訊就已經載入進來了並且被快取了。後面的許多操作都可以直接通過這些快取資料來進行處理了。

回到createAdaptiveExtension方法，他呼叫了getExtesionClasses方法載入擴充套件點實現資訊完成之後，就可以直接通過判斷cachedAdaptiveClass快取欄位是否被賦值盤確定當前擴充套件點是否有預設的AdaptiveExtension實現。如果沒有，那麼就呼叫createAdaptiveExtensionClass方法來動態生成一個。在dubbo的擴充套件點框架中大量的使用了快取技術。

建立自適應擴充套件點實現型別和例項化就已經完成了，下面就來看下擴充套件點自動注入的實現injectExtension：

  1. private T injectExtension(T instance) {

  2. try {

  3. if (objectFactory != null) {

  4. for (Method method : instance.getClass().getMethods()) {

  5. if (method.getName().startsWith("set")

  6. && method.getParameterTypes().length == 1

  7. && Modifier.isPublic(method.getModifiers())) {// 處理所有set方法

  8. Class<?> pt = method.getParameterTypes()[0];// 獲取set方法引數型別

  9. try {

  10. // 獲取setter對應的property名稱

  11. String property = method.getName().length() > 3 ? method.getName().substring(3, 4).toLowerCase() + method.getName().substring(4) : "";

  12. Object object = objectFactory.getExtension(pt, property); // 根據型別，名稱資訊從ExtensionFactory獲取

  13. if (object != null) { // 如果不為空，說set方法的引數是擴充套件點型別，那麼進行注入

  14. method.invoke(instance, object);

  15. }

  16. } catch (Exception e) {

  17. logger.error("fail to inject via method " + method.getName()

  18. + " of interface " + type.getName() + ": " + e.getMessage(), e);

  19. }

  20. }

  21. }

  22. }

  23. } catch (Exception e) {

  24. logger.error(e.getMessage(), e);

  25. }

  26. return instance;

  27. }

 這裡可以看到，擴充套件點自動注入的一句就是根據setter方法對應的引數型別和property名稱從ExtensionFactory中查詢，如果有返回擴充套件點例項，那麼就進行注入操作。到這裡getAdaptiveExtension方法就分析完畢了。

getExtension

這個方法的主要作用是用來獲取ExtensionLoader例項代表的擴充套件的指定實現。已擴充套件實現的名字作為引數，結合前面學習getAdaptiveExtension的程式碼，我們可以推測，這方法中也使用了在呼叫getExtensionClasses方法的時候收集並快取的資料，其中涉及到名字和具體實現型別對應關係的快取屬性是cachedClasses。具體是是否如我們猜想的那樣呢，學習一下相關程式碼就知道了：

  1. public T getExtension(String name) {

  2. if (name == null || name.length() == 0)

  3. throw new IllegalArgumentException("Extension name == null");

  4. if ("true".equals(name)) { // 判斷是否是獲取預設實現

  5. return getDefaultExtension();

  6. }

  7. Holder<Object> holder = cachedInstances.get(name);// 快取

  8. if (holder == null) {

  9. cachedInstances.putIfAbsent(name, new Holder<Object>());

  10. holder = cachedInstances.get(name);

  11. }

  12. Object instance = holder.get();

  13. if (instance == null) {

  14. synchronized (holder) {

  15. instance = holder.get();

  16. if (instance == null) {

  17. instance = createExtension(name);// 沒有快取例項則建立

  18. holder.set(instance);// 快取起來

  19. }

  20. }

  21. }

  22. return (T) instance;

  23. }

 接著看createExtension方法的實現：

  1. private T createExtension(String name) {

  2. Class<?> clazz = getExtensionClasses().get(name); // getExtensionClass內部使用cachedClasses快取

  3. if (clazz == null) {

  4. throw findException(name);

  5. }

  6. try {

  7. T instance = (T) EXTENSION_INSTANCES.get(clazz); // 從已建立Extension例項快取中獲取

  8. if (instance == null) {

  9. EXTENSION_INSTANCES.putIfAbsent(clazz, (T) clazz.newInstance());

  10. instance = (T) EXTENSION_INSTANCES.get(clazz);

  11. }

  12. injectExtension(instance); // 屬性注入

  13. // Wrapper型別進行包裝，層層包裹

  14. Set<Class<?>> wrapperClasses = cachedWrapperClasses;

  15. if (wrapperClasses != null && wrapperClasses.size() > 0) {

  16. for (Class<?> wrapperClass : wrapperClasses) {

  17. instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));

  18. }

  19. }

  20. return instance;

  21. } catch (Throwable t) {

  22. throw new IllegalStateException("Extension instance(name: " + name + ", class: " +

  23. type + ") could not be instantiated: " + t.getMessage(), t);

  24. }

  25. }

 從程式碼中可以看到，內部呼叫了getExtensionClasses方法來獲取當前擴充套件的所有實現，而getExtensionClassse方法會在第一次被呼叫的時候將結果快取到cachedClasses變數中，後面的呼叫就直接從快取變數中獲取了。這裡還可以看到一個快取EXTENSION_INSTANCES，這個快取是ExtensionLoader的靜態成員，也就是全域性快取，存放著所有的擴充套件點實現型別與其對應的已經例項化的例項物件(是所有擴充套件點，不是某一個擴充套件點)，也就是說所有的擴充套件點實現在dubbo中最多都只會有一個例項。

拿到擴充套件點實現型別對應的例項之後，呼叫了injectExtension方法對該例項進行擴充套件點注入，緊接著就是遍歷該擴充套件點介面的所有Wrapper來對真正的擴充套件點例項進行Wrap操作，都是對通過將上一次的結果作為下一個Wrapper的建構函式引數傳遞進去例項化一個Wrapper物件，最後總返回回去的是Wrapper型別的例項而不是具體實現類的例項。

這裡或許有一個疑問： 從程式碼中看，不論instance是否存在於EXTENSION_INSTANCE，都會進行擴充套件點注入和Wrap操作。那麼如果對於同一個擴充套件點，呼叫了兩次createExtension方法的話，那不就進行了兩次Wrap操作麼？

如果外部能夠直接呼叫createExtension方法，那麼確實可能出現這個問題。但是由於createExtension方法是private的，因此外部無法直接呼叫。而在ExtensionLoader類中呼叫它的getExtension方法(只有它這一處呼叫)，內部自己做了快取(cachedInstances)，因此當getExtension方法內部呼叫了一次createExtension方法之後，後面對getExtension方法執行同樣的呼叫時，會直接使用cachedInstances快取而不會再去呼叫createExtension方法了。

getActivateExtension

getActivateExtension方法主要獲取當前擴充套件的所有可自動啟用的實現。可根據入參(values)調整指定實現的順序，在這個方法裡面也使用到getExtensionClasses方法中收集的快取資料。

  1. public List<T> getActivateExtension(URL url, String[] values, String group) {

  2. List<T> exts = new ArrayList<T>();

  3. List<String> names = values == null ? new ArrayList<String>(0) : Arrays.asList(values); // 解析配置要使用的名稱

  4. // 如果未配置"-default",則載入所有Activates擴充套件(names指定的擴充套件)

  5. if (! names.contains(Constants.REMOVE_VALUE_PREFIX + Constants.DEFAULT_KEY)) {

  6. getExtensionClasses(); // 載入當前Extension所有實現,會獲取到當前Extension中所有@Active實現，賦值給cachedActivates變數

  7. for (Map.Entry<String, Activate> entry : cachedActivates.entrySet()) { // 遍歷當前擴充套件所有的@Activate擴充套件

  8. String name = entry.getKey();

  9. Activate activate = entry.getValue();

  10. if (isMatchGroup(group, activate.group())) { // 判斷group是否滿足,group為null則直接返回true

  11. T ext = getExtension(name); // 獲取擴充套件示例

  12. // 排除names指定的擴充套件;並且如果names中沒有指定移除該擴充套件(-name)，且當前url匹配結果顯示可啟用才進行使用

  13. if (! names.contains(name)

  14. && ! names.contains(Constants.REMOVE_VALUE_PREFIX + name)

  15. && isActive(activate, url)) {

  16. exts.add(ext);

  17. }

  18. }

  19. }

  20. Collections.sort(exts, ActivateComparator.COMPARATOR); // 預設排序

  21. }

  22. // 對names指定的擴充套件進行專門的處理

  23. List<T> usrs = new ArrayList<T>();

  24. for (int i = 0; i < names.size(); i ++) { // 遍歷names指定的副檔名

  25. String name = names.get(i);

  26. if (! name.startsWith(Constants.REMOVE_VALUE_PREFIX)

  27. && ! names.contains(Constants.REMOVE_VALUE_PREFIX + name)) { // 未設定移除該擴充套件

  28. if (Constants.DEFAULT_KEY.equals(name)) { // default表示上面已經載入並且排序的exts,將排在default之前的Activate擴充套件放置到default組之前,例如:ext1,default,ext2

  29. if (usrs.size() > 0) { // 如果此時user不為空,則user中存放的是配置在default之前的Activate擴充套件

  30. exts.addAll(0, usrs); // 注意index是0，放在default前面

  31. usrs.clear(); // 放到default之前，然後清空

  32. }

  33. } else {

  34. T ext = getExtension(name);

  35. usrs.add(ext);

  36. }

  37. }

  38. }

  39. if (usrs.size() > 0) { // 這裡留下的都是配置在default之後的

  40. exts.addAll(usrs); // 新增到default排序之後

  41. }

  42. return exts;

  43. }

總結

基本上將dubbo的擴充套件點載入機制學習了一遍，有幾點可能需要注意的地方：

  • 每個ExtensionLoader例項只負責載入一個特定擴充套件點實現
  • 每個擴充套件點對應最多隻有一個ExtensionLoader例項
  • 對於每個擴充套件點實現，最多隻會有一個例項
  • 一個擴充套件點實現可以對應多個名稱(逗號分隔)
  • 對於需要等到執行時才能決定使用哪一個具體實現的擴充套件點，應獲取其自使用擴充套件點實現(AdaptiveExtension)
  • @Adaptive註解要麼註釋在擴充套件點@SPI的方法上，要麼註釋在其實現類的類定義上
  • 如果@Adaptive註解註釋在@SPI介面的方法上，那麼原則上該介面所有方法都應該加@Adaptive註解(自動生成的實現中預設為註解的方法拋異常)
  • 每個擴充套件點最多隻能有一個被AdaptiveExtension
  • 每個擴充套件點可以有多個可自動啟用的擴充套件點實現(使用@Activate註解)
  • 由於每個擴充套件點實現最多隻有一個例項，因此擴充套件點實現應保證執行緒安全
  • 如果擴充套件點有多個Wrapper，那麼最終其執行的順序不確定(內部使用ConcurrentHashSet儲存)

TODO：

  • 學習一下動態生成AdaptiveExtension類的實現過程 
    官方文件描述動態生成的AdaptiveExtension程式碼如下：

  1. package <擴充套件點介面所在包>;

  2. public class <擴充套件點介面名>$Adpative implements <擴充套件點介面> {

  3. public <有@Adaptive註解的介面方法>(<方法引數>) {

  4. if(是否有URL型別方法引數?) 使用該URL引數

  5. else if(是否有方法型別上有URL屬性) 使用該URL屬性

  6. # <else 在載入擴充套件點生成自適應擴充套件點類時拋異常，即載入擴充套件點失敗！>

  7. if(獲取的URL == null) {

  8. throw new IllegalArgumentException("url == null");

  9. }

  10. 根據@Adaptive註解上宣告的Key的順序，從URL獲致Value，作為實際擴充套件點名。

  11. 如URL沒有Value，則使用預設擴充套件點實現。如沒有擴充套件點， throw new IllegalStateException("Fail to get extension");

  12. 在擴充套件點實現呼叫該方法，並返回結果。

  13. }

  14. public <有@Adaptive註解的介面方法>(<方法引數>) {

  15. throw new UnsupportedOperationException("is not adaptive method!");

  16. }

  17. }

 規則如下：

  • 先在URL上找@Adaptive註解指定的Extension名；
  • 如果不設定則預設使用Extension介面類名的點分隔小寫字串(即對於Extension介面com.alibaba.dubbo.xxx.YyyInvokerWrapper的預設值為String[] {“yyy.invoker.wrapper”})。
  • 使用預設實現(@SPI指定)，如果沒有設定預設擴充套件，則方法呼叫會丟擲IllegalStateException。

相關推薦

Dubbo——擴充套件點載入機制

一、getAdaptiveExtension()方法：獲取擴充套件點實現類的介面卡類例項。從ExtensionLoader.cachedAdaptiveInstance變數中獲取，若為空，則呼叫createAdaptiveExtension方法建立介面卡類的例項，並將介面卡類的例項快取到cachedAda

Dubbo擴充套件點載入機制

概述 來源：  Dubbo的擴充套件點載入從JDK標準的SPI(Service Provider Interface)擴充套件點發現機制加強而來。 Dubbo改進了JDK標準的SPI的以下問題： JDK標準的SPI會一次性例項化擴充套件點所有實現，如果有擴充套件實現

Dubbo 擴充套件點載入機制：從 Java SPI 到 Dubbo SPI

SPI 全稱為 Service Provider Interface，是一種服務發現機制。當程式執行呼叫介面時，會根據配置檔案或預設規則資訊載入對應的實現類。所以在程式中並沒有直接指定使用介面的哪個實現，而是在外部進行裝配。 要想了解 Dubbo 的設計與實現，其中 Dubbo SPI 載入機制是必須瞭解

擴充套件點載入機制(ExtensionLoader)

概述 來源： Dubbo的擴充套件點載入從JDK標準的SPI(Service Provider Interface)擴充套件點發現機制加強而來。 Dubbo改進了JDK標準的SPI的以下問題： JDK標準的SPI會一次性例項化擴充套件點所有實現，如果有

dubbo擴充套件點機制

spring是如何啟動容器的 常見的一種在本地使用main方法啟動spring的方法 public static void main(String[] args) throws Exception { ClassPathXmlAp

Dubbo擴充套件點機制分析

一、擴充套件點配置詳見我在《Java的SPI機制分析》文章中關於Dubbo的SPI機制的介紹，在此不再贅述。二、擴充套件點流程分析之SPI    下面以Container載入的過程為例，來說明SPI擴充套件的實現流程：所有加上@SPI註解的擴充套件點可以有不同的擴充套件，Co

Dubbo 的 SPI 機制（三）（Extension 擴充套件點補充）

相關部落格： Dubbo的SPI機制（一）（Java的SPI） Dubbo的SPI機制（二）（Dubbo優化後的SPI實現）   Dubbo 的 Extension 主要是基於 SPI 思想實現的自己的 SPI 的工具。  在上一篇部落格（Dubbo的SP

Dubbo/Dubbox的服務暴露（二）-擴充套件點機制

上文書留的疑問，這兩句到底在幹啥 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, regis

Dubbo原始碼分析——擴充套件點機制

Dubbo作為開源框架，必須要提供很多的可擴充套件點。Dubbo的擴充套件點載入採用了微核心外掛式的開發模式，它是比較符合OCP原則。 微核心 由一個外掛生命週期管理容器，構成微核心， 核心不包括任何功能，這樣可以確保所有功能都能被替換，並且框架實現的功能，

Dubbo剖析-增強SPI中擴充套件點自動包裝的實現

一、前言 在Spring AOP中可以使用多個切面對指定類的方法進行增強，在Dubbo中也提供了類似的功能，在dubbo中你可以指定多個Wrapper類對指定的擴充套件點的實現類的方法進行增強 二、一個例子 Protocol protocol = ExtensionLoader.getEx

Dubbo原始碼實現四：Dubbo中的擴充套件點與SPI

       SPI的全稱是ServiceProviderInterface，即服務提供商介面。直白的說，它主要用來實現一個可擴充套件的Java應用。有人會覺得這就是建立在面向介面程式設計下的一種為了使元件可擴充套件或動態變更實現的規範，常見的類SPI的設計有JDBC、JN

Dubbo擴充套件機制：ExtensionLoader

一、前言     Dubbo的ExtensionLoader是實現“微核心+外掛式”的重要元件，它基於java spi機制卻又提供瞭如下擴充套件：jdk spi僅僅通過介面類名獲取所有實現，而ExtensionLoader則通過介面類名和key值獲取一個實現Adaptive實

DexClassLoader和PathClassLoader類載入機制

分析 sbin 分享 return bject _id ise 否則 nts 0x00 在DexClassLoader和PathClassLoader載入Dex流程一文中，我們分析了dex文件怎樣形成了DexFile結構體。本文中解說類載入機制，實際上就是生

聊聊Dubbo - Dubbo可擴展機制實戰

Java摘要： 在Dubbo的官網上，Dubbo描述自己是一個高性能的RPC框架。今天我想聊聊Dubbo的另一個很棒的特性, 就是它的可擴展性。1. Dubbo的擴展機制在Dubbo的官網上，Dubbo描述自己是一個高性能的RPC框架。今天我想聊聊Dubbo的另一個很棒的特性, 就是它的可擴展性。 如同羅馬不

《深入理解Java虛擬機器》個人讀書總結——虛擬機器類載入機制

我們都知道Java虛擬機器是用來執行我們編譯好的.class檔案的，class檔案中夾帶類的各種資訊，虛擬機器要執行這些檔案，第一件事就是要載入到虛擬機器中，這就引出了這次總結的問題——虛擬機器是如何載入這些class檔案的？載入後虛擬機器是怎麼處理檔案中夾帶的資訊的？ 類載入機制

tomcat執行載入機制，dns地址解析，tcp/ip三握四揮（全）

一.瞭解從輸入url到顯示頁面過程中都發生了什麼：    1.通過url並利用DNS解析出目的主機的ip地址；     2.找到目標主機，建立TCP/IP連線；    3.Tomcat監聽

JVM的虛擬機器類載入機制

首先，我們要知道為什麼會存在類的載入機制。Java語言編寫的.java在經過編譯器編譯後會生成.class檔案，這個和C\C++語言是不一樣的。 C語言它們是會被編譯生成為本地機器碼，然後在被執行。這種做法的缺點就是無法完成編寫程式碼的跨平臺使用。想想就知道，windows下編譯好的程式碼在li

關於Class物件、類載入機制、虛擬機器執行時記憶體佈局的全面解析和推測

簡介： 本文是對Java的類載入機制，Class物件，反射原理等相關概念的理解、驗證和Java虛擬機器中記憶體佈局的一些推測。本文重點講述瞭如何理解Class物件以及Class物件的作用。 歡迎探討，如有錯誤敬請指正 如需轉載，請註明出處 http://www.cnblogs.com/nul

JVM原理（二）類載入機制與GC演算法

一. 類的載入機制 過程 將.class的二進位制資料讀入記憶體，放入方法區中 在堆中建立一個java.lang.Class物件，封裝類在方法區中的資料結構，並提供訪問方法區資料結構的介面 類的生命週期 類的載入過程

php自動載入機制

為什麼要實現自動載入機制？ 在大專案中，就不用每次include/require檔案，省心又高效，只要你不嫌累的話，就可以不使用。 一、spl_autoload_register 語法： sql_autoload_register(callback $function_n