Java中怎么實現(xiàn)SPI機制

Java中怎么實現(xiàn)SPI機制，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站建設(shè)、網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元潼關(guān)做網(wǎng)站,已為上家服務(wù),為潼關(guān)各地企業(yè)和個人服務(wù),聯(lián)系電話:13518219792

2 什么是SPI機制

SPI是Service Provider Interface 的簡稱，即服務(wù)提供者接口的意思。根據(jù)字面意思我們可能還有點困惑，SPI說白了就是一種擴展機制，我們在相應(yīng)配置文件中定義好某個接口的實現(xiàn)類，然后再根據(jù)這個接口去這個配置文件中加載這個實例類并實例化，其實SPI就是這么一個東西。說到SPI機制，我們最常見的就是Java的SPI機制，此外，還有Dubbo和SpringBoot自定義的SPI機制。

有了SPI機制，那么就為一些框架的靈活擴展提供了可能，而不必將框架的一些實現(xiàn)類寫死在代碼里面。

那么，某些框架是如何利用SPI機制來做到靈活擴展的呢？下面舉幾個栗子來闡述下：

1.  JDBC驅(qū)動加載案例：利用Java的SPI機制，我們可以根據(jù)不同的數(shù)據(jù)庫廠商來引入不同的JDBC驅(qū)動包；

2.  SpringBoot的SPI機制：我們可以在spring.factories中加上我們自定義的自動配置類，事件監(jiān)聽器或初始化器等；

3.  Dubbo的SPI機制：Dubbo更是把SPI機制應(yīng)用的淋漓盡致，Dubbo基本上自身的每個功能點都提供了擴展點，比如提供了集群擴展，路由擴展和負載均衡擴展等差不多接近30個擴展點。如果Dubbo的某個內(nèi)置實現(xiàn)不符合我們的需求，那么我們只要利用其SPI機制將我們的實現(xiàn)替換掉Dubbo的實現(xiàn)即可。

上面的三個栗子先讓我們直觀感受下某些框架利用SPI機制是如何做到靈活擴展的。

3 如何使用Java的SPI？

我們先來看看如何使用Java自帶的SPI。先定義一個Developer接口

// Developer.java  package com.ymbj.spi;  public interface Developer {      void sayHi();  }

再定義兩個Developer接口的兩個實現(xiàn)類：

// JavaDeveloper.java  package com.ymbj.spi;  public class JavaDeveloper implements Developer {      @Override      public void sayHi() {          System.out.println("Hi, I am a Java Developer.");      }  }

// PythonDeveloper.java  package com.ymbj.spi;  public class PythonDeveloper implements Developer {      @Override      public void sayHi() {          System.out.println("Hi, I am a Python Developer.");      }  }

然后再在項目resources目錄下新建一個META-INF/services文件夾，然后再新建一個以Developer接口的全限定名命名的文件，文件內(nèi)容為：

// com.ymbj.spi.Developer文件  com.ymbj.spi.JavaDeveloper  com.ymbj.spi.PythonDeveloper

最后我們再新建一個測試類JdkSPITest：

// JdkSPITest.java  public class JdkSPITest {      @Test      public void testSayHi() throws Exception {          ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);          serviceLoader.forEach(Developer::sayHi);      }  }

運行上面那個測試類，運行成功結(jié)果如下截圖所示：

由上面簡單的Demo我們知道了如何使用Java的SPI機制來實現(xiàn)擴展點加載。

4 Java的SPI機制的源碼分析

通過前面擴展Developer接口的簡單Demo，我們看到Java的SPI機制實現(xiàn)跟ServiceLoader這個類有關(guān)，那么我們先來看下ServiceLoader的類結(jié)構(gòu)代碼：

// ServiceLoader實現(xiàn)了【Iterable】接口  public final class ServiceLoader<S>      implements Iterable<S>{      private static final String PREFIX = "META-INF/services/";      // The class or interface representing the service being loaded      private final Class<S> service;      // The class loader used to locate, load, and instantiate providers      private final ClassLoader loader;      // The access control context taken when the ServiceLoader is created      private final AccessControlContext acc;      // Cached providers, in instantiation order      private LinkedHashMap<String,S> providers = new LinkedHashMap<>();      // The current lazy-lookup iterator      private LazyIterator lookupIterator;      // 構(gòu)造方法      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();      }       // ...暫時省略相關(guān)代碼        // ServiceLoader的內(nèi)部類LazyIterator,實現(xiàn)了【Iterator】接口      // Private inner class implementing fully-lazy provider lookup      private class LazyIterator          implements Iterator<S>{          Class<S> service;          ClassLoader loader;          Enumeration<URL> configs = null;          Iterator<String> pending = null;          String nextName = null;          private LazyIterator(Class<S> service, ClassLoader loader) {              this.service = service;              this.loader = loader;          }          // 覆寫Iterator接口的hasNext方法          public boolean hasNext() {              // ...暫時省略相關(guān)代碼          }          // 覆寫Iterator接口的next方法          public S next() {              // ...暫時省略相關(guān)代碼          }          // 覆寫Iterator接口的remove方法          public void remove() {              // ...暫時省略相關(guān)代碼          }      }      // 覆寫Iterable接口的iterator方法，返回一個迭代器      public Iterator<S> iterator() {          // ...暫時省略相關(guān)代碼      }      // ...暫時省略相關(guān)代碼  }

可以看到，ServiceLoader實現(xiàn)了Iterable接口，覆寫其iterator方法能產(chǎn)生一個迭代器；同時ServiceLoader有一個內(nèi)部類LazyIterator，而LazyIterator又實現(xiàn)了Iterator接口，說明LazyIterator是一個迭代器。

4.1 ServiceLoader.load方法，為加載服務(wù)提供者實現(xiàn)類做前期準備

那么我們現(xiàn)在開始探究Java的SPI機制的源碼， 先來看JdkSPITest的第一句代碼ServiceLoader<Developer> serviceLoader = ServiceLoader.load(Developer.class);中的ServiceLoader.load(Developer.class)的源碼：

// ServiceLoader.java  public static <S> ServiceLoader<S> load(Class<S> service) {      //獲取當(dāng)前線程上下文類加載器      ClassLoader cl = Thread.currentThread().getContextClassLoader();      // 將service接口類和線程上下文類加載器作為參數(shù)傳入，繼續(xù)調(diào)用load方法      return ServiceLoader.load(service, cl);  }

我們再來看下ServiceLoader.load(service, cl);方法：

// ServiceLoader.java  public static <S> ServiceLoader<S> load(Class<S> service,                                          ClassLoader loader)  {      // 將service接口類和線程上下文類加載器作為構(gòu)造參數(shù)，新建了一個ServiceLoader對象      return  new ServiceLoader<>(service, loader);  }

繼續(xù)看new ServiceLoader<>(service, loader);是如何構(gòu)建的？

// ServiceLoader.java  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();  }

可以看到在構(gòu)建ServiceLoader對象時除了給其成員屬性賦值外，還調(diào)用了reload方法：

// ServiceLoader.java  public void reload() {      providers.clear();      lookupIterator = new LazyIterator(service, loader);  }

可以看到在reload方法中又新建了一個LazyIterator對象，然后賦值給lookupIterator。

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

可以看到在構(gòu)建LazyIterator對象時，也只是給其成員變量service和loader屬性賦值呀，我們一路源碼跟下來，也沒有看到去META-INF/services文件夾加載Developer接口的實現(xiàn)類！這就奇怪了，我們都被ServiceLoader的load方法名騙了。

還記得分析前面的代碼時新建了一個LazyIterator對象嗎？Lazy顧名思義是懶的意思，Iterator就是迭代的意思。我們此時猜測那么LazyIterator對象的作用應(yīng)該就是在迭代的時候再去加載Developer接口的實現(xiàn)類了。

4.2 ServiceLoader.iterator方法，實現(xiàn)服務(wù)提供者實現(xiàn)類的懶加載

我們現(xiàn)在再來看JdkSPITest的第二句代碼serviceLoader.forEach(Developer::sayHi);，執(zhí)行這句代碼后最終會調(diào)用serviceLoader的iterator方法：

// serviceLoader.java  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;              // 調(diào)用lookupIterator即LazyIterator的hasNext方法              // 可以看到是委托給LazyIterator的hasNext方法來實現(xiàn)              return lookupIterator.hasNext();          }          public S next() {              if (knownProviders.hasNext())                  return knownProviders.next().getValue();              // 調(diào)用lookupIterator即LazyIterator的next方法              // 可以看到是委托給LazyIterator的next方法來實現(xiàn)              return lookupIterator.next();          }          public void remove() {              throw new UnsupportedOperationException();          }      }; }

可以看到調(diào)用serviceLoader的iterator方法會返回一個匿名的迭代器對象，而這個匿名迭代器對象其實相當(dāng)于一個門面類，其覆寫的hasNext和next方法又分別委托LazyIterator的hasNext和next方法來實現(xiàn)了。

我們繼續(xù)調(diào)試，發(fā)現(xiàn)接下來會進入LazyIterator的hasNext方法：

// serviceLoader$LazyIterator.java  public boolean hasNext() {      if (acc == null) {          // 調(diào)用hasNextService方法          return hasNextService();      } else {          PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {              public Boolean run() { return hasNextService(); }          };          return AccessController.doPrivileged(action, acc);      }  }

繼續(xù)跟進hasNextService方法：

// serviceLoader$LazyIterator.java  private boolean hasNextService() {      if (nextName != null) {          return true;      }      if (configs == null) {          try {              // PREFIX = "META-INF/services/"              // service.getName()即接口的全限定名              // 還記得前面的代碼構(gòu)建LazyIterator對象時已經(jīng)給其成員屬性service賦值嗎              String fullName = PREFIX + service.getName();              // 加載META-INF/services/目錄下的接口文件中的服務(wù)提供者類              if (loader == null)                  configs = ClassLoader.getSystemResources(fullName);              else                  // 還記得前面的代碼構(gòu)建LazyIterator對象時已經(jīng)給其成員屬性loader賦值嗎                  configs = loader.getResources(fullName);          } catch (IOException x) {              fail(service, "Error locating configuration files", x);          }      }      while ((pending == null) || !pending.hasNext()) {          if (!configs.hasMoreElements()) {              return false;          }          // 返回META-INF/services/目錄下的接口文件中的服務(wù)提供者類并賦值給pending屬性          pending = parse(service, configs.nextElement());      }      // 然后取出一個全限定名賦值給LazyIterator的成員變量nextName      nextName = pending.next();      return true;  }

可以看到在執(zhí)行LazyIterator的hasNextService方法時最終將去META-INF/services/目錄下加載接口文件的內(nèi)容即加載服務(wù)提供者實現(xiàn)類的全限定名，然后取出一個服務(wù)提供者實現(xiàn)類的全限定名賦值給LazyIterator的成員變量nextName。到了這里，我們就明白了LazyIterator的作用真的是懶加載，在用到的時候才會真正去加載服務(wù)提供者實現(xiàn)類。

思考：為何這里要用懶加載呢？懶加載的思想是怎樣的呢？懶加載有啥好處呢？你還能舉出其他懶加載的案例嗎？

同樣，執(zhí)行完LazyIterator的hasNext方法后，會繼續(xù)執(zhí)行LazyIterator的next方法：

// serviceLoader$LazyIterator.java  public S next() {      if (acc == null) {          // 調(diào)用nextService方法          return nextService();      } else {          PrivilegedAction<S> action = new PrivilegedAction<S>() {              public S run() { return nextService(); }          };          return AccessController.doPrivileged(action, acc);      }  }

我們繼續(xù)跟進nextService方法：

// serviceLoader$LazyIterator.java  private S nextService() {      if (!hasNextService())          throw new NoSuchElementException();      // 還記得在hasNextService方法中為nextName賦值過服務(wù)提供者實現(xiàn)類的全限定名嗎      String cn = nextName;      nextName = null;      Class<?> c = null;      try {          // 【1】去classpath中根據(jù)傳入的類加載器和服務(wù)提供者實現(xiàn)類的全限定名去加載服務(wù)提供者實現(xiàn)類          c = Class.forName(cn, false, loader);      } catch (ClassNotFoundException x) {          fail(service,               "Provider " + cn + " not found");      }      if (!service.isAssignableFrom(c)) {          fail(service,               "Provider " + cn  + " not a subtype");      }      try {          // 【2】實例化剛才加載的服務(wù)提供者實現(xiàn)類，并進行轉(zhuǎn)換          S p = service.cast(c.newInstance());          // 【3】最終將實例化后的服務(wù)提供者實現(xiàn)類放進providers集合          providers.put(cn, p);          return p;      } catch (Throwable x) {          fail(service,               "Provider " + cn + " could not be instantiated",               x);      }      throw new Error();          // This cannot happen  }

可以看到LazyIterator的nextService方法最終將實例化之前加載的服務(wù)提供者實現(xiàn)類，并放進providers集合中，隨后再調(diào)用服務(wù)提供者實現(xiàn)類的方法（比如這里指JavaDeveloper的sayHi方法）。注意，這里是加載一個服務(wù)提供者實現(xiàn)類后，若main函數(shù)中有調(diào)用該服務(wù)提供者實現(xiàn)類的方法的話，緊接著會調(diào)用其方法；然后繼續(xù)實例化下一個服務(wù)提供者類。

因此，我們看到了ServiceLoader.iterator方法真正承擔(dān)了加載并實例化META-INF/services/目錄下的接口文件里定義的服務(wù)提供者實現(xiàn)類。

設(shè)計模式：可以看到，Java的SPI機制實現(xiàn)代碼中應(yīng)用了迭代器模式，迭代器模式屏蔽了各種存儲對象的內(nèi)部結(jié)構(gòu)差異，提供一個統(tǒng)一的視圖來遍歷各個存儲對象（存儲對象可以為集合，數(shù)組等）。java.util.Iterator也是迭代器模式的實現(xiàn)：同時Java的各個集合類一般實現(xiàn)了Iterable接口，實現(xiàn)了其iterator方法從而獲得Iterator接口的實現(xiàn)類對象（一般為集合內(nèi)部類），然后再利用Iterator對象的實現(xiàn)類的hasNext和next方法來遍歷集合元素。

5 JDBC驅(qū)動加載源碼解讀

前面分析了Java的SPI機制的源碼實現(xiàn)，現(xiàn)在我們再來看下Java的SPI機制的實際案例的應(yīng)用。

我們都知道，JDBC驅(qū)動加載是Java的SPI機制的典型應(yīng)用案例。JDBC主要提供了一套接口規(guī)范，而這套規(guī)范的api在java的核心庫（rt.jar）中實現(xiàn)，而不同的數(shù)據(jù)庫廠商只要編寫符合這套JDBC接口規(guī)范的驅(qū)動代碼，那么就可以用Java語言來連接數(shù)據(jù)庫了。

java的核心庫（rt.jar）中跟JDBC驅(qū)動加載的最核心的接口和類分別是java.sql.Driver接口和java.sql.DriverManager類，其中java.sql.Driver是各個數(shù)據(jù)庫廠商的驅(qū)動類要實現(xiàn)的接口，而DriverManager是用來管理數(shù)據(jù)庫的驅(qū)動類的，值得注意的是DriverManager這個類有一個registeredDrivers集合屬性，用來存儲MySQL的驅(qū)動類。

// DriverManager.java  // List of registered JDBC drivers  private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();

這里以加載Mysql驅(qū)動為例來分析JDBC驅(qū)動加載的源碼。

我們的項目引入mysql-connector-java依賴（這里的版本是5.1.47）后，那么Mysql的驅(qū)動實現(xiàn)類文件如下圖所示：

可以看到Mysql的驅(qū)動包中有兩個Driver驅(qū)動類，分別是com.mysql.jdbc.Driver和com.mysql.fabric.jdbc.FabricMySQLDriver，默認情況下一般我們只用到前者。

5.1 利用Java的SPI加載Mysql的驅(qū)動類

那么接下來我們就來探究下JDBC驅(qū)動加載的代碼是如何實現(xiàn)的。

先來看一下一個簡單的JDBC的測試代碼：

// JdbcTest.java  public class JdbcTest {      public static void main(String[] args) {          Connection connection = null;          Statement statement = null;         ResultSet rs = null;          try {              // 注意：在JDBC 4.0規(guī)范中，這里可以不用再像以前那樣編寫顯式加載數(shù)據(jù)庫的代碼了              // Class.forName("com.mysql.jdbc.Driver");              // 獲取數(shù)據(jù)庫連接，注意【這里將會加載mysql的驅(qū)動包】              /***************【主線，切入點】****************/              connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/jdbc", "root", "123456");              // 創(chuàng)建Statement語句              statement = connection.createStatement();              // 執(zhí)行查詢語句              rs = statement.executeQuery("select * from user");              // 遍歷查詢結(jié)果集              while(rs.next()){                  String name = rs.getString("name");                  System.out.println(name);              }          } catch(Exception e) {              e.printStackTrace();          } finally {              // ...省略釋放資源的代碼          }      }  }

在JdbcTest的main函數(shù)調(diào)用DriverManager的getConnection方法時，此時必然會先執(zhí)行DriverManager類的靜態(tài)代碼塊的代碼，然后再執(zhí)行g(shù)etConnection方法，那么先來看下DriverManager的靜態(tài)代碼塊：

// DriverManager.java  static {      // 加載驅(qū)動實現(xiàn)類      loadInitialDrivers();  println("JDBC DriverManager initialized");  }

繼續(xù)跟進loadInitialDrivers的代碼：

// DriverManager.java  private static void loadInitialDrivers() {      String drivers;      try {          drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {              public String run() {                  return System.getProperty("jdbc.drivers");              }          });      } catch (Exception ex) {          drivers = null;      }      AccessController.doPrivileged(new PrivilegedAction<Void>() {          public Void run() {              // 來到這里，是不是感覺似曾相識，對，沒錯，我們在前面的JdkSPITest代碼中執(zhí)行過下面的兩句代碼              // 這句代碼前面已經(jīng)分析過，這里不會真正加載服務(wù)提供者實現(xiàn)類              // 而是實例化一個ServiceLoader對象且實例化一個LazyIterator對象用于懶加載              ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);              // 調(diào)用ServiceLoader的iterator方法，在迭代的同時，也會去加載并實例化META-INF/services/java.sql.Driver文件              // 的com.mysql.jdbc.Driver和com.mysql.fabric.jdbc.FabricMySQLDriver兩個驅(qū)動類              /****************【主線，重點關(guān)注】**********************/              Iterator<Driver> driversIterator = loadedDrivers.iterator();              try{                  while(driversIterator.hasNext()) {                      driversIterator.next();                  }              } catch(Throwable t) {              // Do nothing             }              return null;          }      });      println("DriverManager.initialize: jdbc.drivers = " + drivers);      if (drivers == null || drivers.equals("")) {          return;      }      String[] driversdriversList = drivers.split(":");      println("number of Drivers:" + driversList.length);      for (String aDriver : driversList) {          try {              println("DriverManager.Initialize: loading " + aDriver);              Class.forName(aDriver, true,                      ClassLoader.getSystemClassLoader());          } catch (Exception ex) {              println("DriverManager.Initialize: load failed: " + ex);          }      }  }

在上面的代碼中，我們可以看到Mysql的驅(qū)動類加載主要是利用Java的SPI機制實現(xiàn)的，即利用ServiceLoader來實現(xiàn)加載并實例化Mysql的驅(qū)動類。

5.2 注冊Mysql的驅(qū)動類

那么，上面的代碼只是Mysql驅(qū)動類的加載和實例化，那么，驅(qū)動類又是如何被注冊進DriverManager的registeredDrivers集合的呢？

這時，我們注意到com.mysql.jdbc.Driver類里面也有個靜態(tài)代碼塊，即實例化該類時肯定會觸發(fā)該靜態(tài)代碼塊代碼的執(zhí)行，那么我們直接看下這個靜態(tài)代碼塊做了什么事情：

// com.mysql.jdbc.Driver.java  // Register ourselves with the DriverManager  static {      try {          // 將自己注冊進DriverManager類的registeredDrivers集合          java.sql.DriverManager.registerDriver(new Driver());      } catch (SQLException E) {          throw new RuntimeException("Can't register driver!");      }  }

可以看到，原來就是Mysql驅(qū)動類com.mysql.jdbc.Driver在實例化的時候，利用執(zhí)行其靜態(tài)代碼塊的時機時將自己注冊進DriverManager的registeredDrivers集合中。

好，繼續(xù)跟進DriverManager的registerDriver方法：

// DriverManager.java  public static synchronized void registerDriver(java.sql.Driver driver)      throws SQLException {      // 繼續(xù)調(diào)用registerDriver方法      registerDriver(driver, null);  }  public static synchronized void registerDriver(java.sql.Driver driver,          DriverAction da)      throws SQLException {      /* Register the driver if it has not already been added to our list */      if(driver != null) {          // 將driver驅(qū)動類實例注冊進registeredDrivers集合          registeredDrivers.addIfAbsent(new DriverInfo(driver, da));      } else {          // This is for compatibility with the original DriverManager          throw new NullPointerException();      }      println("registerDriver: " + driver);  }

分析到了這里，我們就明白了Java的SPI機制是如何加載Mysql的驅(qū)動類的并如何將Mysql的驅(qū)動類注冊進DriverManager的registeredDrivers集合中的。

5.3 使用之前注冊的Mysql驅(qū)動類連接數(shù)據(jù)庫

既然Mysql的驅(qū)動類已經(jīng)被注冊進來了，那么何時會被用到呢？

我們要連接Mysql數(shù)據(jù)庫，自然需要用到Mysql的驅(qū)動類，對吧。此時我們回到JDBC的測試代碼JdbcTest類的connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/jdbc", "root", "123456");這句代碼中，看一下getConnection的源碼：

// DriverManager.java  @CallerSensitive  public static Connection getConnection(String url,      String user, String password) throws SQLException {      java.util.Properties info = new java.util.Properties();      if (user != null) {          info.put("user", user);      }      if (password != null) {          info.put("password", password);      }      // 繼續(xù)調(diào)用getConnection方法來連接數(shù)據(jù)庫      return (getConnection(url, info, Reflection.getCallerClass()));  }

繼續(xù)跟進getConnection方法：

// DriverManager.java  private static Connection getConnection(          String url, java.util.Properties info, Class<?> caller) throws SQLException {            ClassLoader callercallerCL = caller != null ? caller.getClassLoader() : null;          synchronized(DriverManager.class) {              // synchronize loading of the correct classloader.              if (callerCL == null) {                  callerCL = Thread.currentThread().getContextClassLoader();              }          }          if(url == null) {              throw new SQLException("The url cannot be null", "08001");          }          println("DriverManager.getConnection(\"" + url + "\")");          // Walk through the loaded registeredDrivers attempting to make a connection.          // Remember the first exception that gets raised so we can reraise it.          SQLException reason = null;          // 遍歷registeredDrivers集合，注意之前加載的Mysql驅(qū)動類實例被注冊進這個集合          for(DriverInfo aDriver : registeredDrivers) {              // If the caller does not have permission to load the driver then              // skip it.              // 判斷有無權(quán)限              if(isDriverAllowed(aDriver.driver, callerCL)) {                  try {                      println("    trying " + aDriver.driver.getClass().getName());                      // 利用Mysql驅(qū)動類來連接數(shù)據(jù)庫                      /*************【主線，重點關(guān)注】*****************/                      Connection con = aDriver.driver.connect(url, info);                      // 只要連接上，那么加載的其余驅(qū)動類比如FabricMySQLDriver將會忽略，因為下面直接返回了                      if (con != null) {                         // Success!                          println("getConnection returning " + aDriver.driver.getClass().getName());                          return (con);                      }                  } catch (SQLException ex) {                      if (reason == null) {                          reason = ex;                      }                  }              } else {                  println("    skipping: " + aDriver.getClass().getName());              }          }          // if we got here nobody could connect.          if (reason != null)    {              println("getConnection failed: " + reason);              throw reason;          }          println("getConnection: no suitable driver found for "+ url);          throw new SQLException("No suitable driver found for "+ url, "08001");      }

可以看到，DriverManager的getConnection方法會從registeredDrivers集合中拿出剛才加載的Mysql驅(qū)動類來連接數(shù)據(jù)庫。

好了，到了這里，JDBC驅(qū)動加載的源碼就基本分析完了。

6 線程上下文類加載器

前面基本分析完了JDBC驅(qū)動加載的源碼，但是還有一個很重要的知識點還沒講解，那就是破壞類加載機制的雙親委派模型的線程上下文類加載器。

我們都知道，JDBC規(guī)范的相關(guān)類（比如前面的java.sql.Driver和java.sql.DriverManager）都是在Jdk的rt.jar包下，意味著這些類將由啟動類加載器(BootstrapClassLoader)加載；而Mysql的驅(qū)動類由外部數(shù)據(jù)庫廠商實現(xiàn)，當(dāng)驅(qū)動類被引進項目時也是位于項目的classpath中,此時啟動類加載器肯定是不可能加載這些驅(qū)動類的呀，此時該怎么辦？

由于類加載機制的雙親委派模型在這方面的缺陷，因此只能打破雙親委派模型了。因為項目classpath中的類是由應(yīng)用程序類加載器(AppClassLoader)來加載，所以我們可否"逆向"讓啟動類加載器委托應(yīng)用程序類加載器去加載這些外部數(shù)據(jù)庫廠商的驅(qū)動類呢？如果可以，我們怎樣才能做到讓啟動類加載器委托應(yīng)用程序類加載器去加載classpath中的類呢？

答案肯定是可以的，我們可以將應(yīng)用程序類加載器設(shè)置進線程里面，即線程里面新定義一個類加載器的屬性contextClassLoader，然后在某個時機將應(yīng)用程序類加載器設(shè)置進線程的contextClassLoader這個屬性里面，如果沒有設(shè)置的話，那么默認就是應(yīng)用程序類加載器。然后啟動類加載器去加載java.sql.Driver和java.sql.DriverManager等類時，同時也會從當(dāng)前線程中取出contextClassLoader即應(yīng)用程序類加載器去classpath中加載外部廠商提供的JDBC驅(qū)動類。因此，通過破壞類加載機制的雙親委派模型，利用線程上下文類加載器完美的解決了該問題。

此時我們再回過頭來看下在加載Mysql驅(qū)動時是什么時候獲取的線程上下文類加載器呢？

答案就是在DriverManager的loadInitialDrivers方法調(diào)用了ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);這句代碼，而取出線程上下文類加載器就是在ServiceLoader的load方法中取出：

public static <S> ServiceLoader<S> load(Class<S> service) {      // 取出線程上下文類加載器取出的是contextClassLoader，而contextClassLoader裝的應(yīng)用程序類加載器      ClassLoader cl = Thread.currentThread().getContextClassLoader();      // 把剛才取出的線程上下文類加載器作為參數(shù)傳入，用于后去加載classpath中的外部廠商提供的驅(qū)動類      return ServiceLoader.load(service, cl);  }

因此，到了這里，我們就明白了線程上下文類加載器在加載JDBC驅(qū)動包中充當(dāng)?shù)淖饔昧恕４送?，我們?yīng)該知道，Java的絕大部分涉及SPI的加載都是利用線程上下文類加載器來完成的，比如JNDI,JCE,JBI等。

擴展：打破類加載機制的雙親委派模型的還有代碼的熱部署等，另外，Tomcat的類加載機制也值得一讀。

7 擴展：Dubbo的SPI機制

前面也講到Dubbo框架身上處處是SPI機制的應(yīng)用，可以說處處都是擴展點，真的是把SPI機制應(yīng)用的淋漓盡致。但是Dubbo沒有采用默認的Java的SPI機制，而是自己實現(xiàn)了一套SPI機制。

那么，Dubbo為什么沒有采用Java的SPI機制呢？

原因主要有兩個：

1.  Java的SPI機制會一次性實例化擴展點所有實現(xiàn)，如果有擴展實現(xiàn)初始化很耗時，但如果沒用上也加載，會很浪費資源;

2.  Java的SPI機制沒有Ioc和AOP的支持，因此Dubbo用了自己的SPI機制：增加了對擴展點IoC和AOP的支持，一個擴展點可以直接setter注入其它擴展點。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

分享名稱：Java中怎么實現(xiàn)SPI機制
URL分享：http://muchs.cn/article4/gdciie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)站制作、域名注冊、靜態(tài)網(wǎng)站、虛擬主機、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)