前言

ava虛擬機（JVM）的類加載機制是Java應用中不可或缺的一部分。本文將詳細介紹JVM的雙親委派機制，并闡述各關鍵點。

一、什么是雙親委派機制

雙親委派機制（Parent-Delegate Model）是Java類加載器中采用的一種類加載策略。該機制的核心思想是：如果一個類加載器收到了類加載請求，默認先將該請求委托給其父類加載器處理。只有當父級加載器無法加載該類時，才會嘗試自行加載。

二、類加載器與層級關系

Java中的類加載器主要有如下三種：

• 啟動類加載器（Bootstrap ClassLoader）： 負責加載 %JAVA_HOME%/jre/lib 目錄下的核心Java類庫如 rt.jar、charsets.jar 等。
• 擴展類加載器（Extension ClassLoader）： 負責加載 %JAVA_HOME%/jre/lib/ext 目錄下的擴展類庫。
• 應用類加載器（Application ClassLoader）： 負責加載用戶類路徑（ClassPath）下的應用程序類。

這三種類加載器之間存在父子層級關系。啟動類加載器是最高級別的加載器，沒有父加載器；擴展類加載器的父加載器是啟動類加載器；應用類加載器的父加載器是擴展類加載器。

  除了以上三個內置類加載器，用戶還可以通過繼承 java.lang.ClassLoader 類自定義類加載器，根據(jù)實際需求處理類加載請求。

三、雙親委派機制作用及如何破環(huán)機制

通過上述兩塊內容，我們對雙親委派機制、加載流程及層級有了一些了解，這時我們不妨拋出幾個疑問。

• 為什么需要雙親委派
• 雙親委派機制有哪些優(yōu)缺點
• 如何打破這個機制
• 有哪些工具選擇了破壞機制。

為什么需要雙親委派

1. 通過雙親委派機制，可以避免類的重復加載，當父加載器已經(jīng)加載過某一個類時，子加載器就不會再重新加載這個類。

2. 通過雙親委派機制，可以保證安全性。因為BootstrapClassLoader在加載的時候，只會加載JAVA_HOME中的jar包里面的類，如java.lang.String，那么這個類是不會被隨意替換的。

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

這是在JDK1.8的java.lang.ClassLoader類中的源碼，這個方法就是用于加載指定的類。

實現(xiàn)雙親委派機制 的代碼也都集中在這個方法之中：

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;
        }
    }

通過以上代碼得出結論：

• 當類加載器接收到類加載的請求時，首先檢查該類是否已經(jīng)被當前類加載器加載；
• 若該類未被加載過，當前類加載器會將加載請求委托給父類加載器去完成；
• 若當前類加載器的父類加載器為null，會委托啟動類加載器完成加載；
• 若父類加載器無法完成類的加載，當前類加載器才會去嘗試加載該類。

雙親委派機制的優(yōu)缺點

優(yōu)點：

• 避免重復加載：由于類加載器直接從父類加載器那里加載類，避免了類的重復加載。
• 提高安全性：通過雙親委派模型，Java 標準庫中的核心類庫（如 java.lang.*）由啟動類加載器加載，這樣能保證這些核心類庫不會被惡意代碼篡改或替換，從而提高程序的安全性。
• 保持類加載的一致性：這種方式確保了同一個類的加載由同一個類加載器完成，從而在運行時保證了類型的唯一性和相同性。這也有助于減輕類加載器在處理相互關聯(lián)的類時的復雜性。

缺點：

• 靈活性降低：由于類加載的過程需要不斷地委托給父類加載器，這種機制可能導致實際應用中類加載的靈活性降低。
• 增加了類加載時間：在類加載的過程中，需要不斷地查詢并委托父類加載器，這意味著類加載所需要的時間可能會增加。在類數(shù)量龐大或類加載器層次比較深的情況下，這種時間延遲可能會變得更加明顯。

如何打破這個機制

既然上述文章中我們已經(jīng)知道了雙親委派的實現(xiàn)方式，那么如何打破這個機制呢。

想要破壞這種機制，那么就需要自定義一個類加載器，繼承ClassLoader類重寫其中的loadClass方法，使其不進行雙親委派即可。

寫個示例

import java.lang.reflect.Method;
import java.nio.file.Files;
import java.nio.file.Paths;
public class CustomClassLoader extends ClassLoader {
    // 自定義類加載器必須提供一個加載類文件的位置
    private String classesPath;
    public CustomClassLoader(String classesPath, ClassLoader parent) {
        super(parent);
        this.classesPath = classesPath;
    }
    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        //首先,檢查已加載的類
        Class<?> loadedClass = findLoadedClass(name);
        if (loadedClass == null) {
            // 如果已加載類中沒有該類, 嘗試用自定義的方法加載
            try {
                loadedClass = findClassInPath(name);
            } catch (ClassNotFoundException e) {
                // 如果自定義加載方法找不到類,則委托給父類加載器
                loadedClass = super.loadClass(name, resolve);
            }
        }
        if (resolve) {
            resolveClass(loadedClass);
        }
        return loadedClass;
    }
    private Class<?> findClassInPath(String className) throws ClassNotFoundException {
        try {
            String filePath = className.replace('.', '/') + ".class";
            byte[] classBytes = Files.readAllBytes(Paths.get(classesPath, filePath));
            return defineClass(className, classBytes, 0, classBytes.length);
        } catch (Exception e) {
            throw new ClassNotFoundException("Class not found in classes path: " + className, e);
        }
    }
    public static void main(String[] args) throws Exception {
        String pathToClasses = "/path/to/your/classes";
        String className = "com.example.SampleClass";
        String methodName = "sampleMethod";
        // 創(chuàng)建自定義類加載器實例，將類的加載權交給它
        CustomClassLoader customClassLoader = new CustomClassLoader(pathToClasses, CustomClassLoader.class.getClassLoader());
        // 使用自定義類加載器加載類
        Class<?> customClass = customClassLoader.loadClass(className);
        // 創(chuàng)建類的實例并調用方法
        Object obj = customClass.newInstance();
        Method method = customClass.getDeclaredMethod(methodName);
        method.setAccessible(true);
        method.invoke(obj);
    }
}

上面的示例代碼中，我們重寫了 loadClass 方法，先嘗試通過 findClassInPath 從指定的路徑加載類，如果無法加載就委托給父類加載器。這樣，我們就實現(xiàn)了打破雙親委派機制的自定義類加載器。

以下是代碼的詳細解析：

• 自定義類加載器 CustomClassLoader 繼承 Java ClassLoader 類。
• 在類加載器的構造方法中設置自定義類加載器的類路徑 classesPath 和父加載器 parent。
• 重寫 loadClass 方法。首先檢查已加載的類，如果已加載則返回。否則嘗試用自定義的方法在 classesPath 中加載類。如果自定義加載方法找不到類，則委托給父類加載器。
• 實現(xiàn)名為 findClassInPath 的自定義加載方法。這個方法使用類名 className 在 classesPath 指定的目錄下查找對應的 .class 文件，然后將文件內容讀取為字節(jié)數(shù)組并調用 defineClass 方法，將其轉換為 Java 類的 Class 對象。如果類不存在或出現(xiàn)其他錯誤，會拋出 ClassNotFoundException 異常。
• 在 main 方法中，創(chuàng)建一個 CustomClassLoader 類的實例。將類的加載任務交給自定義類加載器，指定加載路徑和要加載的類。
• 使用自定義類加載器加載目標類，創(chuàng)建類的實例，并調用指定方法。

有哪些工具選擇了破壞機制

既然在上文中，我們已經(jīng)清楚怎么打破雙親機制，那么有哪些工具選擇了破壞機制呢？為什么？

• OSGi（Open Service Gateway Initiative）：OSGi 是一個模塊化系統(tǒng)和服務平臺，提供了一個強大的類加載器模型。在 OSGi 中，每個模塊都有一個獨立的類加載器，可以按需加載來自不同模塊的類。這有助于解決 JAR 地獄問題，提高模塊化和動態(tài)更新能力。
• Tomcat Web容器：Tomcat 的 Web 應用類加載器可以加載 Web 應用程序中的本地類庫，從而使得每個 Web 應用程序可以使用各自的版本的類庫。這些 Web 應用的類加載器都是${tomcat-home}/lib 中類庫的子類加載器。
• Java Agent: Java Agent 是一種基于 Java Instrumentation API 的技術，它可以在運行時修改已加載的類的字節(jié)碼，從而實現(xiàn)類的熱替換、AOP（面向切面編程）等功能。這種技術在諸如熱部署、性能監(jiān)控和分布式追蹤等場景中有廣泛應用。
• JDK 中的 URLClassLoader：JDK 自帶的 URLClassLoader 可以用來加載指定 URL 路徑下的類。實際上，它實現(xiàn)了一種子類優(yōu)先的策略，先嘗試加載自身路徑下的類，再委托給父類加載器，從而打破了雙親委派機制。

這些工具和技術之所以要打破雙親委派機制，主要是出于以下原因：

• 實現(xiàn)模塊化和動態(tài)更新：例如 OSGi，通過獨立的類加載器實現(xiàn)不同模塊間解耦，并支持模塊的動態(tài)卸載和更新。
• 解決類庫版本沖突（JAR地獄問題）：在復雜系統(tǒng)中，不同模塊可能依賴不同版本的類庫。為避免版本沖突，可使用獨立的類加載器，使它們分別加載各自的類庫版本。
• 運行時修改類：Java Agent 可以在運行時修改類字節(jié)碼，從而支持熱替換、AOP 和性能監(jiān)控等功能。
• 支持 Web 應用程序的獨立部署和更新：例如 Tomcat，可以為每個 Web 應用程序分配一個獨立的類加載器，實現(xiàn)各自部署與更新。

需要注意的是，打破雙親委派機制可能會帶來類加載沖突、安全性和性能等問題，因此在實際應用中要謹慎使用。

四、總結

本文介紹了JVM的雙親委派機制，包括概念、類加載器層級關系、雙親委派流程及實例分析等方面的內容。雙親委派機制可以確保Java應用類型安全，同時避免類加載沖突。在某些特定場景下，我們可以通過自定義類加載器對類加載策略進行調整，以滿足應用特性和性能需求。

以上就是Java雙親委派機制全面分析講解的詳細內容，更多關于Java雙親委派機制的資料請關注腳本之家其它相關文章！

最新評論