# 一、背景

名單 管理系統是手機上各個模組將需要管控的應用配置到檔案中，然後下發到手機上進行應用管控的系統，比如各個應用的耗電量管控；各個模組的管控應用檔案考慮到安全問題，有自己的不同的加密方式，按照以往的經驗，我們可以利用模板方法+工廠模式來根據模組的型別來獲取到不同的加密方法。程式碼類層次結構示意如下:

![](https://static001.geekbang.org/infoq/90/90a38cd54568568a85533928bfa686ef.png)

獲取不同加密方法的類結構圖

利用工廠模式和模板方法模式，在有新的加密方法時，我們可以透過新增新的handler來滿足"對修改關閉，對擴充套件開放"的原則，但是這種方式不可避免的需要修改程式碼和需要重新發版本和上線。那麼有沒有更好的方式能夠去解決這個問題，這裡就是我們今天要重點講的主題。

# 二、類載入的時機

一個型別從被載入到虛擬機器記憶體中開始，到解除安裝出記憶體為止，它的整個生命週期將會經歷載入 （Loading）、驗證（Verification）、準備（Preparation）、解析（Resolution）、初始化 （Initialization）、使用（Using）和解除安裝（Unloading）七個階段，其中驗證、準備、解析三個部分統稱為連線（Linking）。這七個階段的發生順序如圖1所示。

![](https://static001.geekbang.org/infoq/93/9345bd742840291c67b4b1daf94e9827.png)

雖然classloader的載入過程有複雜的7步，但事實上除了載入之外的四步，其它都是由JVM虛擬機器控制的，我們除了適應它的規範進行開發外，能夠干預的空間並不多。而載入則是我們控制classloader實現特殊目的最重要的手段了。也是接下來我們介紹的重點了。

# 三、載入

“載入”（Loading）階段是整個“類載入”（Class Loading）過程中的一個階段。在載入階段，Java虛擬機器需要完成以下三件事情：

-   透過一個類的全限定名來獲取定義此類的二進位制位元組流。

-   將這個位元組流所代表的靜態儲存結構轉化為方法區的執行時資料結構。

-   在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口。

《Java虛擬機器規範》對這三點沒有進行特別具體的要求，從而留給虛擬機器實現與Java應用的靈活度都是相當大的。例如“透過一個類的全限定名來獲取定義此類的二進位制位元組流”這條規則，它並沒有指明二 進位制位元組流必須得從某個Class檔案中獲取，確切地說是根本沒有指明要從哪裡獲取、如何獲取。比如我們可以從ZIP壓縮包中讀取、從網路中獲取、執行時計算生成、由其他檔案生成、從資料庫中讀取。也可以可以從加密檔案中獲取。

從這裡我們可以看出，只需要我們能夠獲取到加密類的.class檔案，我們就可以透過類載入器獲取到對應的加密類class物件，進而透過反射去呼叫具體的加密方法。因此類載入器在.class檔案的載入過程有著至關重要的地位。

# 四、雙親委派模型

目前Java虛擬機器已經存在三種類載入器，分別為啟動類載入器、擴充套件類載入器和應用程式類載入器；絕大多數的Java程式都會使用這三種類載入器進行載入。

![](https://static001.geekbang.org/infoq/dc/dc59d75b2abe3c5339698a0c877f0dc2.png)

## 4.1 啟動類載入器

這個類由C++實現，負責載入存放在\\lib目錄，或者被-Xbootclasspath引數所指定的路徑中存放的，而且是Java虛擬機器能夠識別的（按照檔名識別，如rt.jar、tools.jar，名字不符合的類庫即使放在lib目錄中也不會被載入）類庫載入到虛擬機器的記憶體中。啟動類載入器無法被Java程式直接引用，使用者在編寫自定義類載入器時， 如果需要把載入請求委派給引導類載入器去處理，那直接使用null代替即可。

## 4.2 擴充套件類載入器

這個類載入器是在類sun.misc.Launcher$ExtClassLoader 中以Java程式碼的形式實現的。它負責載入\\lib\\ext目錄中，或者被java.ext.dirs系統變數所指定的路徑中所有的類庫。根據“擴充套件類載入器”這個名稱，就可以推斷出這是一種Java系統類庫的擴充套件機制，JDK的開發團隊允許使用者將具有通用性的類庫放置在ext目錄裡以擴充套件Java SE的功能，在JDK9之後，這種擴充套件機制被模組化帶來的天然的擴充套件能力所取代。由於擴充套件類載入器是由Java程式碼實現的，開發者可以直接在程式中使用擴充套件類載入器來載入Class檔案。

## 4.3 應用程式類載入器

這個類載入器由sun.misc.Launcher$AppClassLoader來實現。由於應用程式類載入器是ClassLoader類中的getSystemClassLoader()方法的返回值，所以有些場合中也稱它為“系統類載入器”。它負責載入使用者類路徑（ClassPath）上所有的類庫，開發者同樣可以直接在程式碼中使用這個類載入器。如果應用程式中沒有自定義過自己的類載入器，一般情況下這個就是程式中預設的類載入器。

由於現有的類載入器載入路徑都有特殊的要求，自己所編譯的加密類所產生的.class檔案所存放的路徑不在三個現有類載入器的路徑裡面，因此我們有必要自己定義類載入器。

# 五、自定義類載入器

除了根類載入器，所有類載入器都是ClassLoader的子類。所以我們可以透過繼承ClassLoader來實現自己的類載入器。

ClassLoader類有兩個關鍵的方法：

-   protected Class loadClass(String name, boolean resolve)：name為類名，resove如果為true，在載入時解析該類。

-   protected Class findClass(String name) ：根據指定類名來查詢類。

所以，如果要實現自定義類，可以重寫這兩個方法來實現。但推薦重寫findClass方法，而不是重寫loadClass方法，重寫loadClass方法可能會破壞類載入的雙親委派模型，因為loadClass方法內部會呼叫findClass方法。

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

```

loadClass載入方法流程：

-   判斷此類是否已經載入；

-   如果父載入器不為null，則使用父載入器進行載入；反之，使用根載入器進行載入；

-   如果前面都沒載入成功，則使用findClass方法進行載入。

所以，為了不影響類的載入過程，我們重寫findClass方法即可簡單方便的實現自定義類載入。

# 六、程式碼實現

## 6.1 實現自定義的類載入器

```java
public class DynamicClassLoader extends ClassLoader {
 
    private static final String CLASS_EXTENSION = "class";
 
    @Override
    public Class> findClass(String encryptClassInfo) {
        EncryptClassInfo info = JSON.parseObject(encryptClassInfo, EncryptClassInfo.class);
        String filePath = info.getAbsoluteFilePath();
        String systemPath = System.getProperty("java.io.tmpdir");
        String normalizeFileName = FilenameUtils.normalize(filePath, true);
        if (StringUtils.isEmpty(normalizeFileName) || !normalizeFileName.startsWith(systemPath)
                ||getApkFileExtension(normalizeFileName) == null
                || !CLASS_EXTENSION.equals(getApkFileExtension(normalizeFileName))) {
            return null;
        }
 
        String className = info.getEncryptClassName();
        byte[] classBytes = null;
        File customEncryptFile = new File(filePath);
        try {
            Path path = Paths.get(customEncryptFile.toURI());
            classBytes = Files.readAllBytes(path);
        } catch (IOException e) {
            log.info("加密錯誤", e);
        }
        if (classBytes != null) {
            return defineClass(className, classBytes, 0, classBytes.length);
        }
        return null;
    }
 
    private static String getApkFileExtension(String fileName) {
        int index = fileName.lastIndexOf(".");
        if (index != -1) {
            return fileName.substring(index + 1);
        }
        return null;
    }
}
```

這裡主要是透過整合ClassLoader，複寫findClass方法，從加密類資訊中獲取到對應的.class檔案資訊，最後獲取到加密類的物件

## 6.2 .class檔案中的encrypt()方法

```java
public String encrypt(String rawString) {
        String keyString = "R.string.0x7f050001";
        byte[] enByte = encryptField(keyString, rawString.getBytes());
        return Base64.encode(enByte);
    }
```

## 6.3 具體的呼叫

```java
public class EncryptStringHandler {
 
    private static final Map<string class="">> classMameMap = new HashMap<>();
 
    @Autowired
    private VivofsFileHelper vivofsFileHelper;
 
    @Autowired
    private DynamicClassLoader dynamicClassLoader;
 
    public String encryptString(String fileId, String encryptClassName, String fileContent) {
        try {
            Class> clazz = obtainEncryptClass(fileId, encryptClassName);
            Object obj = clazz.newInstance();
            Method method = clazz.getMethod("encrypt", String.class);
            String encryptStr = (String) method.invoke(obj, fileContent);
            log.info("原字串為:{},加密後的字串為:{}", fileContent, encryptStr);
            return encryptStr;
        } catch (Exception e) {
            log.error("自定義載入器載入加密類異常", e);
            return null;
        }
    }
 
    private Class> obtainEncryptClass(String fileId, String encryptClassName) {
        Class> clazz = classMameMap.get(encryptClassName);
        if (clazz != null) {
            return clazz;
        }
 
        String absoluteFilePath = null;
        try {
            String domain = VivoConfigManager.getString("vivofs.host");
            String fullPath = domain + "/" + fileId;
            File classFile = vivofsFileHelper.downloadFileByUrl(fullPath);
            absoluteFilePath = classFile.getAbsolutePath();
            EncryptClassInfo encryptClassInfo = new EncryptClassInfo(encryptClassName, absoluteFilePath);
            String info = JSON.toJSONString(encryptClassInfo);
            clazz = dynamicClassLoader.findClass(info);
            //設定快取
            Assert.notNull(clazz, "自定義類載入器載入加密類異常");
            classMameMap.put(encryptClassName, clazz);
            return clazz;
        } finally {
            if (absoluteFilePath != null) {
                FileUtils.deleteQuietly(new File(absoluteFilePath));
            }
        }
    }
}
```

透過上述程式碼的實現，我們可以透過在管理平臺新增編譯好的.class檔案，最後透過自定義的類載入器和反射呼叫方法，來實現具體方法的呼叫，避免了我們需要修改程式碼和重新發版來適應不斷新增加密方法的問題。

# 七、問題

上面的程式碼在本地測試時，沒有出現任何異常，但是部署到測試伺服器以後出現了JSON解析異常，看上去貌似是json字串的格式不對。

![](https://static001.geekbang.org/infoq/7e/7eac7f855a87ce8457ae3fce53c4ae36.png)

json解析邏輯主要存在於DynamicClassLoader#findClass方法入口處的將字串轉換為物件邏輯，為什麼這裡會報錯，我們在入口處列印了入參。

![](https://static001.geekbang.org/infoq/a0/a0cb0ffe4e9216cbedc8be9cf00683cf.png)

發現這裡除了我們需要的正確的入參(第一個入參資訊列印)外，還多了一個Base64的全路徑名cn.hutool.core.codec.Base64。出現這種情況，說明由於我們重寫了ClassLoader的findClass方法，而Base64載入的時候會呼叫原始的ClassLoader類的loadClass方法去載入，並且裡面呼叫了findClass方法，由於findClass已經被重寫，所以就會報上面的json解析錯誤。

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

但是這裡期望的是除了用於加密的.class檔案用自定義類載入器進行以外，不希望其他的類用自定義類載入器載入，透過對ClassLoader#loadClass方法分析，那麼我們就希望能否透過其父類載入器載入到Base64這個三方類。因為啟動類載入器Bootstrap Class Loader肯定不能載入到Base64，所以我們需要顯示的設定父類載入器，但是這個父類載入器究竟設定為哪一個類載入器，那麼就需要我們瞭解Tomcat類載入器結構。

為什麼Tomcat需要在JVM基礎之上做一套類載入結構，主要是為了解決如下問題:

-   部署在同一個伺服器上的兩個web應用程式所使用的Java類庫可以實現相互隔離；

-   部署在同一個伺服器上的兩個web應用程式所使用的Java類庫可以實現共享；

-   伺服器需要儘可能保證自身安全，伺服器所使用的類庫應該與應用程式的類庫相互獨立；

-   支援JSP應用的Web伺服器，大對數需要支援HotSwap功能。

為此，tomcat擴充套件出了Common類載入器(CommonClassLoader)、Catalina類載入器(CatalinaClassLoader)、Shared類載入器(SharedClassLoader)和WebApp類載入器(WebAppClassLoader)，他們分別載入/commons/_、/server/_、/shared/*和/WebApp/WEB-INF/*中的Java類庫的邏輯。

![](https://static001.geekbang.org/infoq/f0/f045c12cfe3dc400f13a4d4b4a324e71.png)

透過分析，我們知道WebAppClassLoader類載入器可以載入到/WEB-INF/*目錄下的依賴包，而我們所依賴的類cn.hutool.core.codec.Base64所在的包hutool-all-4.6.10-sources.jar就存在於/WEB-INF/*目錄下面，並且我們自定義類載入器所在的包 vivo-namelist-platform-service-1.0.6.jar也在/WEB-INF/*下，所以自定義類載入器DynamicClassLoader也是WebAppClassLoader載入的。

我們可以寫一個測試類測試一下:

```java
@Slf4j
@Component
public class Test implements ApplicationListener<contextrefreshedevent> {
 
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        log.info("classLoader DynamicClassLoader:" + DynamicClassLoader.class.getClassLoader().toString());
    }
}
```

測試結果:

![](https://static001.geekbang.org/infoq/3e/3e367be07cf40b445122c9d118ddbc62.png)

所以我們可以設定自定義類載入器DynamicClassLoader的父載入器為載入其本身的類載入器：

```java
public DynamicClassLoader() {
        super(DynamicClassLoader.class.getClassLoader());
}
```

我們再次執行檔案的加解密操作時，已經沒有發現報錯，並且透過新增日誌，我們可以看到載入類cn.hutool.core.codec.Base64對應的類載入器確實為載入DynamicClassLoader對應的類載入器WebAppClassLoader。

```java
public String encrypt(String rawString) {
        log.info("classLoader Base64:{}", Base64.class.getClassLoader().toString());
        String keyString = "R.string.0x7f050001";
        byte[] enByte = encryptField(keyString, rawString.getBytes());
        return Base64.encode(enByte);
    }
```

![](https://static001.geekbang.org/infoq/49/4957beba1538feb4b2e6290c168df834.png)

現在再來思考一下，為什麼在IDEA執行環境下不需要設定自定義類載入器的父類載入器就可以載入到cn.hutool.core.codec.Base64。

在IDEA執行環境下新增如下列印資訊:

```java
public String encrypt(String rawString) {
        System.out.println("類載入器詳情...");
        System.out.println("classLoader EncryptStrategyHandler:" + EncryptStrategyHandlerH.class.getClassLoader().toString());
        System.out.println("classLoader EncryptStrategyHandler:" + EncryptStrategyHandlerH.class.getClassLoader().getParent().toString());
        String classPath = System.getProperty("java.class.path");
        System.out.println("classPath:" + classPath);
        System.out.println("classLoader Base64:" + Base64.class.getClassLoader().toString());
        String keyString = "R.string.0x7f050001";
        byte[] enByte = encryptField(keyString, rawString.getBytes());
        return Base64.encode(enByte);
    }
```

![](https://static001.geekbang.org/infoq/1f/1fb95c0bb80997fb4d88d741e80fd32b.png)

發現載入.class檔案的類載入器為自定義類載入器DynamicClassLoader，並且.class載入器的父類載入器為應用類載入器AppClassLoader，載入cn.hutool.core.codec.Base64的類載入器也是AppClassLoader。

具體的載入流程如下:

1）先由自定義類載入器委託給AppClassLoader；

2）AppClassLoader委託給父類載入器ExtClassLoader；

3）ExtClassLoader再委託給BootStrapClassLoader，但是BootClassLoader無法載入到，於是ExtClassLoader自己進行載入，也無法載入到;

4）再由AppClassLoader進行載入；

AppClassLoader會呼叫其父類UrlClassLoader的findClass方法進行載入；

5）最終從使用者類路徑java.class.path中載入到cn.hutool.core.codec.Base64。

![](https://static001.geekbang.org/infoq/c0/c0751a3d203721f3e638ad6087bd288d.png)

![](https://static001.geekbang.org/infoq/6a/6a7977b7ff44762d7ba1890df31c8ab9.png)

由此，我們發現在IDEA環境下面，自定義的加密類.class檔案中依賴的三方cn.hutool.core.codec.Base64是可以透過AppClassLoader進行載入的。

而在linux環境下面，經過遠端除錯，發現初始時載入cn.hutool.core.codec.Base64的類載入器為DynamicClassLoader。然後委託給父類載入器AppClassLoader進行載入，根據雙親委派原理，後續會交由AppClassLoader自己進行處理。但是在使用者路徑下仍然沒有找到類cn.hutool.core.codec.Base64，最終交由DynamicClassLoader進行載入，最終出現了最開始的JSON解析錯誤。

![](https://static001.geekbang.org/infoq/ad/adb268d2cbf22bf720aa436c90b72be9.png)

![](https://static001.geekbang.org/infoq/d3/d356f8dcacf2805ad72e2c058d99988e.png)

![](https://static001.geekbang.org/infoq/7c/7ca7266e087c5ecf956cb27e76880c9b.png)

![](https://static001.geekbang.org/infoq/94/942ec7d5b2a6d32a1d561e9b9d5dcceb.png)

# 八、總結

由於類載入階段沒有嚴格限制如何獲取一個類的二進位制位元組流，因此給我們提供一個透過自定義類載入器來動態載入.class檔案實現程式碼可擴充套件性的可能。透過靈活自定義classloader，也可以在其他領域發揮重要作用,例如實現程式碼加密來避免核心程式碼洩漏、解決不同服務依賴同一個包的不同版本所引起的衝突問題以及實現程式熱部署來避免除錯時頻繁重啟應用。

# 九、參考資料

1、《深入理解Java虛擬機器：JVM高階特性與最佳實踐（第3版）》

2、[史上最強--Java類載入器的原理及應用](https://blog.csdn.net/u012921921/article/details/113988389)

> 作者：vivo網際網路伺服器團隊-Wang Fei</contextrefreshedevent></string>

JVM自定義類載入器在程式碼擴充套件性的實踐

相關文章