[JVM]雙親委派

Duancf發表於2024-09-04
JVM

什麼是雙親委派機制

首先，我們知道，虛擬機器在載入類的過程中需要使用類載入器進行載入，而在Java中，類載入器有很多，那麼當JVM想要載入一個.class檔案的時候，到底應該由哪個類載入器載入呢？

這就不得不提到"雙親委派機制"。

首先，我們需要知道的是，Java語言系統中支援以下4種類載入器：

  • Bootstrap ClassLoader 啟動類載入器
  • Extention ClassLoader 標準擴充套件類載入器
  • Application ClassLoader 應用類載入器
  • User ClassLoader 使用者自定義類載入器

一般認為上一層載入器是下一層載入器的父載入器，那麼，除了BootstrapClassLoader之外，所有的載入器都是有父載入器的。

那麼，所謂的雙親委派機制，指的就是：當一個類載入器收到了類載入的請求的時候，他不會直接去載入指定的類，而是把這個請求委託給自己的父載入器去載入。只有父載入器無法載入這個類的時候，才會由當前這個載入器來負責類的載入。

那麼，什麼情況下父載入器會無法載入某一個類呢？

其實，Java中提供的這四種型別的載入器，是有各自的職責的：

  • Bootstrap ClassLoader ，主要負責載入Java核心類庫，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。
  • Extention ClassLoader，主要負責載入目錄%JRE_HOME%\lib\ext目錄下的jar包和class檔案。
  • Application ClassLoader ，主要負責載入當前應用的classpath下的所有類
  • User ClassLoader ， 使用者自定義的類載入器,可載入指定路徑的class檔案

那麼也就是說，一個使用者自定義的類，如com.hollis.ClassHollis 是無論如何也不會被Bootstrap和Extention載入器載入的。

為什麼需要雙親委派？

如上面我們提到的，因為類載入器之間有嚴格的層次關係，那麼也就使得Java類也隨之具備了層次關係。

或者說這種層次關係是優先順序。

比如一個定義在java.lang包下的類，因為它被存放在rt.jar之中，所以在被載入過程彙總，會被一直委託到Bootstrap ClassLoader，最終由Bootstrap ClassLoader所載入。

而一個使用者自定義的com.hollis.ClassHollis類，他也會被一直委託到Bootstrap ClassLoader，但是因為Bootstrap ClassLoader不負責載入該類，那麼會在由Extention ClassLoader嘗試載入，而Extention ClassLoader也不負責這個類的載入，最終才會被Application ClassLoader載入。

這種機制有幾個好處。

  • 首先，透過委派的方式，可以避免類的重複載入，當父載入器已經載入過某一個類時，子載入器就不會再重新載入這個類。

  • 另外，透過雙親委派的方式，還保證了安全性。因為Bootstrap ClassLoader在載入的時候，只會載入JAVA_HOME中的jar包裡面的類，如java.lang.Integer，那麼這個類是不會被隨意替換的，除非有人跑到你的機器上， 破壞你的JDK。

那麼，就可以避免有人自定義一個有破壞功能的java.lang.Integer被載入。這樣可以有效的防止核心Java API被篡改。

"父子載入器"之間的關係是繼承嗎？

很多人看到父載入器、子載入器這樣的名字，就會認為Java中的類載入器之間存在著繼承關係。

這裡需要明確一下，雙親委派模型中，類載入器之間的父子關係一般不會以繼承（Inheritance）的關係來實現，而是都使用組合（Composition）關係來複用父載入器的程式碼的。

如下為ClassLoader中父載入器的定義：

public abstract class ClassLoader {
    // The parent class loader for delegation
    private final ClassLoader parent;
}

雙親委派是怎麼實現的？

雙親委派模型對於保證Java程式的穩定運作很重要，但它的實現並不複雜。

實現雙親委派的程式碼都集中在java.lang.ClassLoader的loadClass()方法之中：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

程式碼不難理解，主要就是以下幾個步驟：

1、先檢查類是否已經被載入過
2、若沒有載入則呼叫父載入器的loadClass()方法進行載入
3、若父載入器為空則預設使用啟動類載入器作為父載入器。
4、如果父類載入失敗，丟擲ClassNotFoundException異常後，再呼叫自己的findClass()方法進行載入。

如何主動破壞雙親委派機制？

知道了雙親委派模型的實現，那麼想要破壞雙親委派機制就很簡單了。

因為他的雙親委派過程都是在loadClass方法中實現的，那麼想要破壞這種機制，那麼就自定義一個類載入器，重寫其中的loadClass方法，使其不進行雙親委派即可。

loadClass（）、findClass（）、defineClass（）區別

ClassLoader中和類載入有關的方法有很多，前面提到了loadClass，除此之外，還有findClass和defineClass等，那麼這幾個方法有什麼區別呢？

loadClass()
就是主要進行類載入的方法，預設的雙親委派機制就實現在這個方法中。
findClass()
根據名稱或位置載入.class位元組碼
definclass()
把位元組碼轉化為Class

這裡面需要展開講一下loadClass和findClass，我們前面說過，當我們想要自定義一個類載入器的時候，並且像破壞雙親委派原則時，我們會重寫loadClass方法。

那麼，如果我們想定義一個類載入器，但是不想破壞雙親委派模型的時候呢？

這時候，就可以繼承ClassLoader，並且重寫findClass方法。findClass()方法是JDK1.2之後的ClassLoader新新增的一個方法。

 /**
 * @since  1.2
 */
protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}

這個方法只丟擲了一個異常，沒有預設實現。

JDK1.2之後已不再提倡使用者直接覆蓋loadClass()方法，而是建議把自己的類載入邏輯實現到findClass()方法中。

因為在loadClass()方法的邏輯裡，如果父類載入器載入失敗，則會呼叫自己的findClass()方法來完成載入。

所以，如果你想定義一個自己的類載入器，並且要遵守雙親委派模型，那麼可以繼承ClassLoader，並且在findClass中實現你自己的載入邏輯即可。

雙親委派被破壞的例子

雙親委派機制的破壞不是什麼稀奇的事情，很多框架、容器等都會破壞這種機制來實現某些功能。

第一種被破壞的情況是在雙親委派出現之前。

由於雙親委派模型是在JDK1.2之後才被引入的，而在這之前已經有使用者自定義類載入器在用了。所以，這些是沒有遵守雙親委派原則的。

第二種，是JNDI、JDBC等需要載入SPI介面實現類的情況。

第三種是為了實現熱插拔熱部署工具。為了讓程式碼動態生效而無需重啟，實現方式時把模組連同類載入器一起換掉就實現了程式碼的熱替換。

第四種時tomcat等web容器的出現。

第五種時OSGI、Jigsaw等模組化技術的應用。

為什麼JNDI，JDBC等需要破壞雙親委派？

我們日常開發中，大多數時候會透過API的方式呼叫Java提供的那些基礎類，這些基礎類時被Bootstrap載入的。

但是，呼叫方式除了API之外，還有一種SPI的方式。

如典型的JDBC服務，我們通常透過以下方式建立資料庫連線：

Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234");
在以上程式碼執行之前，DriverManager會先被類載入器載入，因為java.sql.DriverManager類是位於rt.jar下面的 ，所以他會被根載入器載入。

類載入時，會執行該類的靜態方法。其中有一段關鍵的程式碼是：

ServiceLoader loadedDrivers = ServiceLoader.load(Driver.class);
這段程式碼，會嘗試載入classpath下面的所有實現了Driver介面的實現類。

那麼，問題就來了。

DriverManager是被根載入器載入的，那麼在載入時遇到以上程式碼，會嘗試載入所有Driver的實現類，但是這些實現類基本都是第三方提供的，根據雙親委派原則，第三方的類不能被根載入器載入。

那麼，怎麼解決這個問題呢？

於是，就在JDBC中透過引入ThreadContextClassLoader（執行緒上下文載入器，預設情況下是AppClassLoader）的方式破壞了雙親委派原則。

我們深入到ServiceLoader.load方法就可以看到：

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

第一行，獲取當前執行緒的執行緒上下⽂類載入器 AppClassLoader，⽤於載入 classpath 中的具體實現類。

為什麼Tomcat要破壞雙親委派

我們知道，Tomcat是web容器，那麼一個web容器可能需要部署多個應用程式。

不同的應用程式可能會依賴同一個第三方類庫的不同版本，但是不同版本的類庫中某一個類的全路徑名可能是一樣的。

如多個應用都要依賴hollis.jar，但是A應用需要依賴1.0.0版本，但是B應用需要依賴1.0.1版本。這兩個版本中都有一個類是com.hollis.Test.class。

如果採用預設的雙親委派類載入機制，那麼是無法載入多個相同的類。

所以，Tomcat破壞雙親委派原則，提供隔離的機制，為每個web容器單獨提供一個WebAppClassLoader載入器。

Tomcat的類載入機制：為了實現隔離性，優先載入 Web 應用自己定義的類，所以沒有遵照雙親委派的約定，每一個應用自己的類載入器——WebAppClassLoader負責載入本身的目錄下的class檔案，載入不到時再交給CommonClassLoader載入，這和雙親委派剛好相反。

模組化技術與類載入機制

近幾年模組化技術已經很成熟了，在JDK 9中已經應用了模組化的技術。

其實早在JDK 9之前，OSGI這種框架已經是模組化的了，而OSGI之所以能夠實現模組熱插拔和模組內部可見性的精準控制都歸結於其特殊的類載入機制，載入器之間的關係不再是雙親委派模型的樹狀結構，而是發展成複雜的網狀結構。

在JDK中，雙親委派也不是絕對的了。

在JDK9之前，JVM的基礎類以前都是在rt.jar這個包裡，這個包也是JRE執行的基石。

這不僅是違反了單一職責原則，同樣程式在編譯的時候會將很多無用的類也一併打包，造成臃腫。

在JDK9中，整個JDK都基於模組化進行構建，以前的rt.jar, tool.jar被拆分成數十個模組，編譯的時候只編譯實際用到的模組，同時各個類載入器各司其職，只載入自己負責的模組。

Class<?> c = findLoadedClass(cn);
if (c == null) {
    // 找到當前類屬於哪個模組
    LoadedModule loadedModule = findLoadedModule(cn);
    if (loadedModule != null) {
        //獲取當前模組的類載入器
        BuiltinClassLoader loader = loadedModule.loader();
        //進行類載入
        c = findClassInModuleOrNull(loadedModule, cn);
     } else {
          // 找不到模組資訊才會進行雙親委派
            if (parent != null) {
              c = parent.loadClassOrNull(cn);
            }
      }
}

相關文章