淺析Java SPI 與 dubbo SPI

Posted on by

Java原生SPI

面向接口編程+策略模式

實現

建立接口

Robot

public interface Robot {
    /**
     * 測試方法1
     */
    void sayHello();
}

多個實現類實現接口

RobotA

public class RobotA implements Robot {
    public RobotA() {
        System.out.println("Happy RobotA is loaded");
    }
    @Override
    public void sayHello() {
        System.out.println("i am a very very happy Robot ");
    }
    public void sayBye(){}
}

RobotB

public class RobotB implements Robot {
    public RobotB() {
        System.out.println("SB RobotB is loaded");
    }
    @Override
    public void sayHello() {
        System.out.println("i am a da sha bi ");
    }
    public void sayBye(){}
}

配置實現類與接口

在META-INF/services目錄下建立一個以接口全限定名為名字的文件,裡面的內容是實現類的全限定名

原理

通過ServiceLoader與配置文件中的全限定名加載所有實現類,根據迭代器獲取具體的某一個類

我們通過對下面一段代碼的分析來說明

ServiceLoader<Robot> serviceLoader=ServiceLoader.load(Robot.class);
serviceLoader.forEach(Robot::sayHello);

load(Robot.class)這個方法的目的隻是為瞭設置類加載器為線程上下文加載器,我們當然可以不這麼做,直接調用load(Class service,ClassLoader loader)方法

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

這個load方法其實也沒有做什麼實質的事,僅僅是實例化瞭一個ServiceLoad對象返回罷瞭

public static <S> ServiceLoader<S> load(Class<S> service,
                                        ClassLoader loader)
{
    return new ServiceLoader<>(service, loader);
}

那是不是構造方法做瞭最核心的事呢?

private ServiceLoader(Class<S> svc, ClassLoader cl) {
    service = Objects.requireNonNull(svc, "Service interface cannot be null");
    loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
    acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
    reload();
}
public void reload() {
    //這裡的provider是一個對於已實例化對象的緩存,為Map類型
        providers.clear();
        lookupIterator = new LazyIterator(service, loader);
    }

沒有,這裡僅僅隻是檢驗瞭參數和權限這樣一些準備操作.然後實例化瞭一個LazyIterator

這是LazyIterator的構造函數

private LazyIterator(Class<S> service, ClassLoader loader) {
    this.service = service;
    this.loader = loader;
}

然後….,沒瞭,ServiceLoader<Robot> serviceLoader=ServiceLoader.load(Robot.class);執行完畢瞭,到這裡,並沒有實例化我們所需要的Robot對象,而僅僅隻是返回瞭一個ServiceLoader對象

這時候如果我們去看serviceLoader的對象方法是這樣的

有用的隻有這三個方法,reload上面已經提到過,隻是重新實例化一個對象而已.

而另外兩個iterator()是個迭代器,foreach也隻是用於迭代的語法糖罷瞭.如果我們debug的話,會發現foreach的核心依舊會變成iterator(),好瞭,接下來重點看iterator()

public Iterator<S> iterator() {
    return new Iterator<S>() {

        Iterator<Map.Entry<String,S>> knownProviders
            = providers.entrySet().iterator();

        public boolean hasNext() {
            if (knownProviders.hasNext())
                return true;
            return lookupIterator.hasNext();
        }

        public S next() {
            if (knownProviders.hasNext())
                return knownProviders.next().getValue();
            return lookupIterator.next();
        }

        public void remove() {
            throw new UnsupportedOperationException();
        }

    };

這個方法實際上是返回瞭一個Iterator對象.而通過這個Iterator,我們可以遍歷獲取我們所需要的Robot對象.

我們來看其用於獲取對象的next方法

 public S next() {
            if (knownProviders.hasNext())
                return knownProviders.next().getValue();
            return lookupIterator.next();
        }

這個方法是先在緩存裡找,緩存裡找不到,就需要用最開始的實例化的lookupIterator找

再來看看它的next方法

public S next() {
    if (acc == null) {
        return nextService();
    } else {
        PrivilegedAction<S> action = new PrivilegedAction<S>() {
            public S run() { return nextService(); }
        };
        return AccessController.doPrivileged(action, acc);
    }
}

這方法的核心是nextService,我們繼續看實現,這個方法比較長,我貼一部分核心

if (!hasNextService())
    throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
    c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
    fail(service,
         "Provider " + cn + " not found");
}

用hasNextService()判斷是否還可以繼續迭代,通過class.forName反射獲取實例,最後再加入到provider緩存中.於是基本邏輯就完成瞭.那nextName哪來的.是在hasNextService()中獲取的.

依舊隻有核心代碼

//獲取文件
String fullName = PREFIX + service.getName();
if (loader == null)
    configs = ClassLoader.getSystemResources(fullName);
else
    configs = loader.getResources(fullName);
//解析文件配置
while ((pending == null) || !pending.hasNext()) {
                if (!configs.hasMoreElements()) {
                    return false;
                }
                pending = parse(service, configs.nextElement());
            }
            nextName = pending.next();

根據前綴(即META-INF/services)和接口的全限定名去找到對應的配置文件.然後加載裡面的配置,獲取具體實現類的名字.

Dubbo增強SPI

實現

建立接口

與原生SPI不同,dubbo需要加入@SPI註解

Robot

@SPI
public interface Robot {
    /**
     * 測試方法1
     */
    void sayHello();
}

多個實現類實現接口

RobotA

public class RobotA implements Robot {
    public RobotA() {
        System.out.println("Happy RobotA is loaded");
    }
    @Override
    public void sayHello() {
        System.out.println("i am a very very happy Robot ");
    }
    public void sayBye(){}
}

RobotB

public class RobotB implements Robot {
    public RobotB() {
        System.out.println("SB RobotB is loaded");
    }
    @Override
    public void sayHello() {
        System.out.println("i am a da sha bi ");
    }
    public void sayBye(){}
}

配置實現類與接口

在META-INF/dubbo目錄下建立一個以接口全限定名為名字的文件,裡面的內容是自定義名字與類的全限定名的鍵值對,舉個例子

robotA = cn.testlove.double_dubbo.inter.impl.RobotA
robotB=cn.testlove.double_dubbo.inter.impl.RobotB

原理

我們通過對下列代碼的調用來進行分析

ExtensionLoader<Robot> extensionLoader= ExtensionLoader.getExtensionLoader(Robot.class);
Robot robotB = extensionLoader.getExtension("robotB");

第一句代碼沒什麼好說的,隻是獲取一個Robot的ExtensionLoader對象並且緩存在Map中,下次如果是同樣的接口可以直接從map中獲取

ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
if (loader == null) {
    EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
    loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
}

再來看第二句代碼

//從緩存中找
final Holder<Object> holder = getOrCreateHolder(name);
Object instance = holder.get();
//雙重檢查
if (instance == null) {
    synchronized (holder) {
        instance = holder.get();
        if (instance == null) {
            instance = createExtension(name);
            holder.set(instance);
        }
    }
}

首先從緩存裡找，找不到再創建一個新的對象。

再看createExtension(name)方法

Class<?> clazz = getExtensionClasses().get(name);

T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
    EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
    instance = (T) EXTENSION_INSTANCES.get(clazz);
}
injectExtension(instance);
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (CollectionUtils.isNotEmpty(wrapperClasses)) {
    for (Class<?> wrapperClass : wrapperClasses) {
        instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
    }
}
initExtension(instance);
return instance;

註意對於Class<?> clazz = getExtensionClasses().get(name);這一句的理解，這一句是獲取配置文件中所有類的Class實例，而不是獲取所有擴展類的實例。

接下來的流程其實也就簡單瞭從EXTENSION_INSTANCES緩存中獲取instance實例,如果沒有,就借助Class對象實例化一個,再放入緩存中

接著用這個instance去實例化一個包裝類然後返回.自此,一個我們需要的對象產生瞭.

最後我們看看getExtensionClasses()這個方法

Map<String, Class<?>> classes = cachedClasses.get();
if (classes == null) {
    synchronized (cachedClasses) {
        classes = cachedClasses.get();
        if (classes == null) {
            classes = loadExtensionClasses();
            cachedClasses.set(classes);
        }
    }
}
return classes;

這裡的classes就是用來存各個擴展類Class的Map緩存,如果不存在的話,會調用loadExtensionClasses();去加載,剩下的就是找到對應路徑下的配置文件,獲取全限定名瞭

上文我在分析Dubbo SPI時,多次提到Map,緩存二詞,我們可以具體有以下這些.其實看名字就大概知道作用瞭

private final ConcurrentMap<Class<?>, String> cachedNames = new ConcurrentHashMap<>();
private final Holder<Map<String, Class<?>>> cachedClasses = new Holder<>()    
private final Map<String, Object> cachedActivates = new ConcurrentHashMap<>();
private final ConcurrentMap<String, Holder<Object>> cachedInstances = new ConcurrentHashMap<>();
private final Holder<Object> cachedAdaptiveInstance = new Holder<>();
private volatile Class<?> cachedAdaptiveClass = null;
private String cachedDefaultName;

對比原生的java SPI,dubbo的無疑更靈活,可以按需去加載某個類,也可以很便捷的通過自定義的名字去獲取類.而且Dubbo還支持setter註入.這點以後再講.

最後提一個問題,java原生的SPI隻有在用iterator遍歷到的時候才會實例化對象,那能不能在遇到自己想要的實現對象時就停止遍歷,避免不必要的資源消耗呢?

補充：下面看下Dubbo SPI 和 Java SPI 區別？

JDK SPI

JDK 標準的 SPI 會一次性加載所有的擴展實現，如果有的擴展吃實話很耗時，但

也沒用上，很浪費資源。

所以隻希望加載某個的實現，就不現實瞭

DUBBO SPI

1，對 Dubbo 進行擴展，不需要改動 Dubbo 的源碼

2，延遲加載，可以一次隻加載自己想要加載的擴展實現。

3，增加瞭對擴展點 IOC 和 AOP 的支持，一個擴展點可以直接 setter 註入其它擴展點。

3，Dubbo 的擴展機制能很好的支持第三方 IoC 容器，默認支持 Spring Bean。

以上就是Java SPI 與 dubbo SPI的詳細內容，更多關於Java SPI 與 dubbo SPI的資料請關註WalkonNet其它相關文章！

推薦閱讀：