你確定你真的理解“雙親委派“了嗎？！

GitHub 19k Star 的Java工程師成神之路，不來了解一下嗎！

最近一段時間，我在面試的程序中，很喜歡問雙親委派的一些問題，因為我發現這個問題真的可以幫助我全方位的了解一個候選人，

記得前幾天一次面試程序中，我和一位候選人聊到了JVM的類加載機制的問題，他談到了雙親委派，并且很自信的給我講了一下他對于雙親委派的理解，

因為難得碰到一個對著塊知識了解的比較多的候選人，于是我們展開了"300回合"的交鋒，當問完這些問題的之后，大概半個小時已經過去了，

最后，這個后續人和我說："我萬萬沒想到，我一個作業7年的技術經理，竟然被雙親委派給虐了！！！"

先來回顧下我都問了他哪些問題，看看你能回答上來多少個：

1、什么是雙親委派？ 2、為什么需要雙親委派，不委派有什么問題？ 3、"父加載器"和"子加載器"之間的關系是繼承的嗎？ 4、雙親委派是怎么實作的？ 5、我能不能主動破壞這種雙親委派機制？怎么破壞？ 6、為什么重寫loadClass方法可以破壞雙親委派，這個方法和findClass（）、defineClass（）區別是什么？ 7、說一說你知道的雙親委派被破壞的例子吧 8、為什么JNDI、JDBC等需要破壞雙親委派？ 9、為什么TOMCAT要破壞雙親委派？ 10、談談你對模塊化技術的理解吧！

以上，10個問題，從頭開始答，你大概可以堅持到第幾題？

什么是雙親委派機制

首先，我們知道，虛擬機在加載類的程序中需要使用類加載器進行加載，而在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<Driver> 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);
            }
      }
}

總結

以上，從什么是雙親委派，到如何實作與破壞雙親委派，又從破壞雙親委派的示例等多個方面全面介紹了關于雙親委派的知識，

相信通過學習本文，你一定對雙親委派機制有了更加深刻的了解，

閱讀過本文之后，反手在簡歷上寫下：熟悉Java的類加載機制，不服來問！

關于作者：Hollis，一個對Coding有著獨特追求的人，阿里巴巴技術專家，《程式員的三門課》聯合作者，《Java工程師成神之路》系列文章作者，

如果您有任何意見、建議，或者想與作者交流，都可以關注公眾號【Hollis】，直接后臺給我留言，