自定義ClassLoader-有解無憂

簡單地純粹地記錄下如何進行自定義一個自己的ClassLoader

什么雙親委派模型啊，雙親委派模型的破壞啊，好處啊，缺點啊什么的，一概不說，

自定義ClassLoader的博客啥的，看過不少，但是就是沒自己親手寫一下，今天嘗試寫一下，發現古人誠不欺我！

紙上得來終覺淺，絕知此事要躬行

失敗版本

最開始是這么寫的

public class MyClassLoader extends ClassLoader {

    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/");
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

這里錯誤比較多，不過還是記住了一個，我是重寫了findClass方法，而不是重寫了loadClass方法，推薦也是通過重寫findClass方法，以前是重寫loadClass方法的方式，

即使是錯誤的，但是寫之前還是絞盡腦汁的想了好久，試圖把記憶中那點破碎的，分崩離析而又即將消失的關于自定義ClassLoader的記憶，給重新恢復了，可惜的是，我并不具體這個能力，憑著那點僅存的記憶，寫下我的第一個自定義ClassLoader，很遺憾它是錯誤的，

寫完后，就去測驗跑了下，發現并沒有出現我期許的結果，

這里說下期許的結果是什么

加載class檔案后生成的Class物件，呼叫其getClassLoader方法，應該是輸出MyClassLoader的
此Class物件和使用系統類加載器加載的同一個class代表的Class物件，并不相等，==會回傳false
自定義類加載器加載的物件，是沒辦法強轉成系統類加載器加載的Class型別，

然后，沒有一個結果符合預期的，

看到輸出的ClassLoader還是AppClassLoader，很奇怪，我明明自定義了類加載還去加載了啊！

最終發現，直接繼承ClassLoader時，使用默認的無參構造

protected ClassLoader() {
    this(checkCreateClassLoader(), getSystemClassLoader());
}

默認情況下，繼承自ClassLoader的子類，會擁有一個父類加載，就是 AppClassLoader，而要加載的類，發現已經被父類加載器加載過了，所以實際上并沒有子類的findClass方法

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    // 同步，保證加載的安全性
    synchronized (getClassLoadingLock(name)) {
        // 檢查是否已經被加載了
        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) {
            }
	    // 如果以上都找不到，就使用下面的邏輯去查找 
            if (c == null) {
                long t1 = System.nanoTime();
                // 這個就是各個子類來實作的了
                c = findClass(name);

                // 一些資訊記錄，記錄到虛擬機里
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
      	// 上面僅僅完成了一個加載class的動作，但是整個類的加載并沒有完成
        // 如果需要決議，則會對Class物件進行決議，這個名字有誤導性，其實這是類加載階段的鏈接階段 
        // 也就是 驗證 準備 決議三個階段
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

所以問題就很明了了，

第一次修改后的版本

public class MyClassLoader extends ClassLoader {
    public MyClassLoader () {
      // 不使用系統類加載器作為此類加載的父加載器
      // 這樣它的父加載器就是啟動類加載器
      super(null);
    }
    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/");
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

這個一跑，也是完蛋，不過好解決，

一般呼叫loadClass方法時，傳的都是包名，這里是要去加載位元組碼的，也就是找class檔案，所以要轉換成具體的路徑，這里的路徑使用的是相對路徑，類位于classpath目錄下，所以直接使用ClassLoader#getResourceAsStream就可以獲取class檔案的位元組流`了，

這里實作的位元組碼來源是從檔案系統加載的class檔案，實際上任何符合Java虛擬機規范的Class結構的位元組陣列，都可以被加載進來，動態代理就是在運行時生成位元組碼，然后直接加載的，

可運行版本

public class MyClassLoader extends ClassLoader {

    public MyClassLoader () {
        super(null);

    }

    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/")+".class";
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

這就是一個麻雀雖小五臟俱全的自定義類加載器了，

兩個重要知識點

就想到這倆，肯定不止倆

同一個類的Class物件在同一個虛擬機行程中，可以存在多個實體，在虛擬機中，是根據Class所屬的類加載器，來確定唯一一個Class，

Hotspot虛擬機在進行類加載時，采用了類似的TLAB的方式，會給每個類加載器分配一塊記憶體，這樣這個類加載器加載的類，直接在這里分配，提高效率，也便于管理，不過遇到有很多類加載的話，會出現OOM的可能，原因就是每個類加載器分配一塊，多整一些，空間不夠了，OOM吧

TLAB（Thread Local Allocate Buffer），目的是提升性能的，每一個執行緒在新生代的Eden區都有一個自己的一畝三分地，這樣在分配記憶體時，不需要加鎖做同步，提升分配的效率，

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

標籤：Java

上一篇：Spring07_純注解實戰及Spring整合Junit

下一篇：python reduce函式