前言

本次帶來 JVM 的另一塊重要內容，類加載機制，不廢話，直接開懟，

正文

1、類加載的程序，

類從被加載到虛擬機記憶體中開始，到卸載出記憶體為止，它的整個生命周期包括：加載、驗證、準備、決議、初始化、使用和卸載7個階段，其中驗證、準備、決議3個部分統稱為連接，

1）加載

“類加載”程序的一個階段，在加載階段，虛擬機需要完成以下3件事情：

通過一個類的全限定名來獲取定義此類的二進制位元組流，
將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構，
在記憶體中生成一個代表這個類的 java.lang.Class 物件，作為方法區這個類的各種資料的訪問入口，

2）驗證

連接階段的第一步，這一階段的目的是為了確保 Class 檔案的位元組流中包含的資訊符合當前虛擬機的要求，并且不會危害虛擬機自身的安全，從整體上看，驗證階段大致上會完成下面4個階段的檢驗動作：檔案格式驗證、元資料驗證、位元組碼驗證、符號參考驗證，

3）準備

該階段是正式為類變數（static修飾的變數）分配記憶體并設定類變數初始值的階段，這些變數所使用的記憶體都將在方法區中進行分配，這里所說的初始值“通常情況”下是資料型別的零值，下表列出了Java中所有基本資料型別的零值，

4）決議

該階段是虛擬機將常量池內的符號參考替換為直接參考的程序，決議動作主要針對類或介面、欄位、類方法、介面方法、方法型別、方法句柄和呼叫點限定符這7類符號參考進行，

5）初始化

到了初始化階段，才真正開始執行類中定義的Java程式代碼，在準備階段，變數已經賦過一次系統要求的初始零值，而在初始化階段，則會根據程式員通程序式制定的主觀計劃去初始化類變數和其他資源，

我們也可以從另外一種更直接的形式來表達：初始化階段是執行類構造器<clinit>()方法的程序，<clinit>() 不是程式員在 Java 代碼中直接撰寫的方法，而是由 Javac 編譯器自動生成的，

<clinit>() 方法是由編譯器自動收集類中的所有類變數的賦值動作和靜態陳述句塊（static{}塊）中的陳述句合并產生的，編譯器收集的順序是由陳述句在源檔案中出現的順序所決定的，靜態陳述句塊中只能訪問到定義在靜態陳述句塊之前的變數，定義在它之后的變數，在前面的靜態陳述句塊可以賦值，但是不能訪問，

我之前還寫過一篇關于初始化的面試題：一道有意思的“初始化”面試題，有興趣的同學可以看一看，

2、Java 虛擬機中有哪些類加載器？

從 Java 虛擬機的角度來講，只存在兩種不同的類加載器：

一種是啟動類加載器（Bootstrap ClassLoader），這個類加載器使用C++語言實作，是虛擬機自身的一部分；

另一種就是所有其他的類加載器，這些類加載器都由Java語言實作，獨立于虛擬機外部，并且全都繼承自抽象類java.lang.ClassLoader，

從Java開發人員的角度來看，絕大部分Java程式都會使用到以下3種系統提供的類加載器，

1）啟動類加載器（Bootstrap ClassLoader）：

這個類加載器負責將存放在<JAVA_HOME>\lib目錄中的，或者被-Xbootclasspath引數所指定的路徑中的，并且是虛擬機識別的（僅按照檔案名識別，如rt.jar，名字不符合的類別庫即使放在lib目錄中也不會被加載）類別庫加載到虛擬機記憶體中，

2）擴展類加載器（Extension ClassLoader）：

這個加載器由sun.misc.Launcher$ExtClassLoader實作，它負責加載<JAVA_HOME>\lib\ext目錄中的，或者被java.ext.dirs系統變數所指定的路徑中的所有類別庫，開發者可以直接使用擴展類加載器，

3）應用程式類加載器（Application ClassLoader）：

這個類加載器由sun.misc.Launcher$AppClassLoader實作，由于這個類加載器是ClassLoader中的getSystemClassLoader()方法的回傳值，所以一般也稱它為系統類加載器，它負責加載用戶類路徑（ClassPath）上所指定的類別庫，開發者可以直接使用這個類加載器，如果應用程式中沒有自定義過自己的類加載器，一般情況下這個就是程式中默認的類加載器，

我們的應用程式都是由這3種類加載器互相配合進行加載的，如果有必要，還可以加入自己定義的類加載器，這些類加載器之間的關系一般如圖所示，

3、什么是雙親委派模型？

如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去加載，

類加載的原始碼如下：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // 1、檢查請求的類是否已經被加載過了
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    // 2、將類加載請求先委托給父類加載器
                    if (parent != null) {
                        // 父類加載器不為空時，委托給父類加載進行加載
                        c = parent.loadClass(name, false);
                    } else {
                        // 父類加載器為空，則代表當前是Bootstrap，從Bootstrap中加載類
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // 如果父類加載器拋出ClassNotFoundException
                    // 說明父類加載器無法完成加載請求
                }

                if (c == null) {
                    // 3、在父類加載器無法加載的時候，再呼叫本身的findClass方法來進行類加載
                    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;
        }
    }

4、為什么使用雙親委派模式？

1）使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是 Java 類隨著它的類加載器一起具備了一種帶有優先級的層次關系，

2）如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己撰寫了一個java.lang.Object 的類，并放在程式的 ClassPath 中，那系統中將會出現多個不同的 Object 類，Java 型別體系中最基礎的行為也就無法保證，應用程式也將會變得一片混亂，

5、有哪些場景破壞了雙親委派模型？

目前比較常見的場景主要有：

1）執行緒背景關系類加載器，典型的：JDBC 使用執行緒背景關系類加載器加載 Driver 實作類

2）Tomcat 的多 Web 應用程式

3）OSGI 實作模塊化熱部署

6、為什么要破壞雙親委派模型？

原因其實很簡單，就是使用雙親委派模型無法滿足需求了，因此只能破壞它，這邊以面試常問的 Tomcat 為例，

我們知道 Tomcat 容器可以同時部署多個 Web 應用程式，多個 Web 應用程式很容易存在依賴同一個 jar 包，但是版本不一樣的情況，例如應用1和應用2都依賴了 spring ，應用1使用的 3.2.* 版本，而應用2使用的是 4.3.* 版本，

如果遵循雙親委派模型，這個時候使用哪個版本了？

其實使用哪個版本都不行，很容易出現兼容性問題，因此，Tomcat 只能選擇破壞雙親委派模型，

7、如何破壞雙親委派模型？

破壞雙親委派模型的思路都比較類似，這邊以面試中常問到的 Tomcat 為例，

其實原理非常簡單，我們可以看到上面的類加載方法原始碼（loadClass）的方法修飾符是 protected，因此我們只需以下幾步就能破壞雙親委派模型，

1）繼承 ClassLoader，Tomcat 中的 WebappClassLoader 繼承 ClassLoader 的子類 URLClassLoader，

2）重寫 loadClass 方法，實作自己的邏輯，不要每次都先委托給父類加載，例如可以先在本地加載，這樣就破壞了雙親委派模型了，

8、Tomcat 的類加載器？

Tomcat 的類加載器如下圖所示：

1）Bootstrap ClassLoader：可以看到上圖中缺少了 Extension ClassLoader，在 Tomcat 中 Extension ClassLoader 被集成到了 Bootstrap ClassLoader 里面，

2）System ClassLoader 就是 Application ClassLoader：Tomcat 中的系統類加載器不會加載 CLASSPATH 環境變數的內容，而是從以下資源庫構建 System 類加載器，

$CATALINA_HOME/bin/bootstrap.jar，包含用于初始化Tomcat服務器的 main() 方法，以及它所依賴的類加載器實作類，
$CATALINA_BASE/bin/tomcat-juli.jar 或 $CATALINA_HOME/bin/tomcat-juli.jar，日志實作類，
如果 $CATALINA_BASE/bin 中存在 tomcat-juli.jar，則使用它來代替 $CATALINA_HOME/bin中的那個，
$CATALINA_HOME/bin/commons-daemon.jar

3）Common ClassLoader：從名字也看出來來了，主要包含一些通用的類，這些類對 Tomcat 內部類和所有 Web 應用程式都可見，

該類加載器搜索的位置由 $CATALINA_BASE/conf/catalina.properties 中的 common.loader 屬性定義，默認設定將按照順序搜索以下位置，

$CATALINA_BASE/lib 中未打包的類和資源
$CATALINA_BASE/lib 目錄下的JAR 檔案
$CATALINA_HOME/lib 中未打包的類和資源
$CATALINA_HOME/lib 目錄下的JAR檔案

4）WebappX ClassLoader：Tomcat 為每個部署的 Web 應用程式創建一個單獨的類加載器，這樣保證了不同應用之間是隔離的，類和資源對其他 Web 應用是不可見的，加載的路徑如下：

Web應用的 /WEB-INF/classes 目錄下的所有未打包的類和資源
Web應用的 /WEB-INF/lib 目錄下的 JAR 檔案中的類和資源

9、Tomcat 的類加載程序？

Tomcat 的類加載程序，也就是 WebappClassLoaderBase#loadClass 的邏輯如下，

1）首先本地快取 resourceEntries，如果已經被加載過則直接回傳快取中的資料，

2）檢查 JVM 是否已經加載過該類，如果是則直接回傳，

3）檢查要加載的類是否是 Java SE 的類，如果是則使用 BootStrap 類加載器加載該類，以防止 webapp 的類覆寫了 Java SE 的類，

例如你寫了一個 java.lang.String 類，放在當前應用的 /WEB-INF/classes 中，如果沒有此步驟的保證，那么之后專案中使用的 String 類都是你自己定義的，而不是 rt.jar 下面的，可能會導致很多隱患，

4）針對委托屬性 delegate 顯示設定為 true、或者一些特殊的類（javax、org 包下的部分類），使用雙親委派模式加載，只有很少部分使用雙親委派模型來加載，

5）嘗試從本地加載類，如果步驟5中加載失敗也會走到本步驟，這邊打破了雙親委派模型，優先從本地進行加載，

7）走到這，代表步驟6加載失敗，如果之前不是使用雙親委派模式，則在這邊會委托給父類加載器來嘗試加載，

8）走到這邊代表所有的嘗試都加載失敗，拋出 ClassNotFoundException，

10、JDBC 使用執行緒背景關系類加載器的原理

JDBC 功能相關的基礎類是由 Java 統一定義的，在 rt.jar 里面，例如 DriverManager，也就是由 Bootstrap ClassLoader 來加載，而 JDBC 的實作類是在各廠商的實作 jar 包里，例如 MySQL 是在 mysql-connector-java 里，oracle、sqlserver 也會有各自的實作 jar，

此時需要 JDBC 的基礎類呼叫其他廠商實作并部署在應用程式的 ClassPath 下的 JDBC 服務提供介面（SPI，Service Provider Interface）的代碼，當類A呼叫類B時，此時類B是由類A的類加載器來負責加載，而 JDBC 的基礎類都是由 Bootstrap ClassLoader 來加載，但是 Bootstrap ClassLoader 是不認識也不會去加載這些廠商實作的代碼的，

因此，Java 提供了執行緒背景關系類加載器，允許通過 Thread#setContextClassLoader/Thread#getContextClassLoader() 來設定和獲取當前執行緒的背景關系類加載器，如果創建執行緒時沒有設定，則會繼承父執行緒的，如果在應用程式的全域范圍內都沒有設定過的話，那這個類加載器默認就是應用程式類加載器（Application ClassLoader），

綜上，JDBC 可以通過執行緒背景關系類加載器，來實作父類加載器“委托”子類加載器完成類加載的行為，這個就明顯不遵守雙親委派模型了，不過這也是雙親委派模型自身的缺陷導致的，

最后

我是囧輝，一個堅持分享原創技術干貨的程式員，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/294467.html

標籤：java

上一篇：想罵人！開發語言不能統一成一個么？

下一篇：Python 用類多載乘法運算子計算和列印楊輝三角形

面試必問的 JVM 類加載機制，你懂了嗎？

前言

正文