類加載器 – 命名空間

本博客將沿用中展示的自定義類加載器代碼

複雜類加載情況分析

測試代碼一

首先,新建一個類Test14,重寫默認的構造方法,打印加載該類的類加載器

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());
    }
}

然後,在新建一個類Test15,同樣重寫默認的構造方法,打印加載該類的類加載器,在構造方法中new出Test14的實例

public class Test15 {
    public Test15() {
        System.out.println("Test15 is loaded by:" + this.getClass().getClassLoader());

        new Test14();
    }
}

測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test01();
    }

    private static void test01 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

猜測一下,首先自定義類加載器classLoader通過反射獲取Test15的Class對象,屬於主動使用,會加載Test15,classLoader委託它的父加載器AppClassLoader加載Test15;然後我們通過clazz.newInstance();代碼獲取Test15的實例,調用Test15的構造方法,在Test15的構造方法中創建了Test14的實例,所以同樣加載了Test14,並調用了Test14的構造方法。加上-XX:+TraceClassLoading指令執行代碼,發現運行結果和我們想的是一樣的。

......
[Loaded classloader.Test15 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
[Loaded classloader.Test14 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
......

測試代碼二

在上篇博客中,自定義類加載器ClassLoaderTest是有一個path屬性可以自定義類的加載路徑的,我們同樣測試一下,我們將Test14和Test15的class文件放到桌面的classloader文件夾下,然後刪除工程路徑下的class文件,執行一下的測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test02();
    }
    private static void test02 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        classLoader.setPath("/home/fanxuan/桌面/");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

按照上節的結果,應該都是ClassLoaderTest加載器加載了Test14和Test15類

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:classloader.ClassLoaderTest@6d6f6e28

接下來,我們重新編譯項目,刪除掉工程目錄下的Test14的calss文件,再次執行代碼

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test14
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test14
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 8 more

我們發現結果報錯了,按照我們正常的思維,自定義記載器classLoader委託父加載器AppClassLoader加載Test15,從打印結果可以看出Test15加載成功了,然後創建Test15的實例,加載Test14,因為工程目錄下缺少Test14的class文件,所以AppClassLoader無法加載到Test14,由自定義加載器classLoader自身從桌面加載Test14。但是我們發現加載Test14的報了ClassNotFoundException的錯誤,這是因為在Test15中記載Test14的時候,是以Test15的類加載器AppClassLoader來加載的,AppClassLoader加載不到Test14,它的父加載器擴展類加載器同樣加載不到,擴展類加載器的父加載器啟動類加載器也加載不到,所以報錯ClassNotFoundException

然後,再重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。根據前文分析的代碼,我們可以很清晰的得出結論:由自定義記載器classLoader加載了Test15,由系統類記載器AppClassLoader加載了Test14。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2

測試代碼三

簡單修改下Test14類,在Test14的構造方法中引用Test15的Class對象。

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());

        System.out.println("Test14:" + Test15.class);
    }
}

執行測試代碼二中的測試代碼Test16,結果如下,沒有任何問題。

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14:class classloader.Test15

我們同樣重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test15
    at classloader.Test14.<init>(Test14.java:11)
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test15
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 9 more

我們發現加載已經完成了,但是程序還是報錯了,是我們剛剛加的System.out.println("Test14:" + Test15.class);代碼報的錯,依然是ClassNotFoundException錯誤。

分析:
Test15由自定義記載器classLoader加載,Test14由系統類記載器AppClassLoader加載。導致程序報錯的是因為命名空間的問題,我們在上一篇博客的結尾簡單介紹了命名空間:每個類加載器都有自己的命名空間,命名空間由該加載器及所有的父加載器所加載的類組成。子加載器所加載的類可以看見父加載器加載的類,但是父加載器所加載的類無法看見子加載器加載的類。Test14是由AppClassLoader加載的,在AppClassLoader的命名空間中沒有Test15的,所以程序報錯了。

命名空間實例分析

測試代碼

新建Entity類用於測試

public class Entity {
    private Entity entity;

    public void setEntity(Object entity) {
        this.entity = (Entity)entity;
    }
}

編寫測試代碼

public class Test17 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

運行程序,System.out.println(clazz1 == clazz2);返回結果為true,都是AppClassLoader加載的,classLoader1加載之後會在AppClassLoader的命名空間中形成緩存,classLoader2加載的時候直接返回命名空間已經存在的Class對象,所以clazz1與clazz2相同。

改造下代碼,將Entity類的class文件copy到桌面文件夾下,刪除工程下的class文件,執行如下代碼

public class Test18 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        classLoader1.setPath("/home/fanxuan/桌面/");
        classLoader2.setPath("/home/fanxuan/桌面/");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

根據前文的介紹,不難推斷System.out.println(clazz1 == clazz2);的運行結果為falseclassLoader1和classLoader2分別加載了Entity類,就是其自身加載的(定義類加載器),在jvm的內存中形成了完全獨立的兩個命名空間,所以clazz1與clazz2不同。而且因為clazz1和clazz2相互不可見,調用了classLoader1命名空間中的方法,傳入了classLoader2命名空間的對象,導致程序拋出了異常。

false
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at classloader.Test18.main(Test18.java:26)
Caused by: java.lang.ClassCastException: classloader.Entity cannot be cast to classloader.Entity
    at classloader.Entity.setEntity(Entity.java:11)
    ... 5 more

不同類加載器的命名空間關係

  • 同一命名空間內的類是相互可見的
  • 子加載器的命名空間包含所有父加載器的命名空間,由子加載器所加載的類可以看見父加載器加載的類
  • 由父加載器所加載的類無法看見子加載器加載的類
  • 如果兩個加載器之間沒有任何直接或間接的父子關係,那麼它們各自加載的類相互不可見

父親委託機制的好處

在的2.1章節簡單介紹了一下類加載器的父親委託機制,這裏面來總結一下好處

  • 確保Java核心類庫的安全:所有的Java應用都至少會引用java.lang.Object類,也就是說在運行期,java.lang.Object類會被記載到Java虛擬機當中;如果這個加載過程是由Java應用自己的類加載器所完成的,那麼可能會在JVM中存在多個版本的java.lang.Object類,而且這些類還是不兼容的、相互不可見的(因為命名空間的原因)。藉助父親委託機制,Java核心類庫中的類的加載工作都是由啟動類加載器來統一完成的,從而確保了Java應用所使用的都是同一個版本的Java核心類庫,他們之間是互相兼容的。
  • 確保Java核心類庫提供的類不會被自定義的類所替代。
  • 不同的類加載器可以為相同名稱(binary name)的類創建額外的命名空間。相同名稱的類可以並存在Java虛擬機中,只需要用不同的類加載器來加他們即可,不同類加載器所加載的類是不兼容的,這就相當於在Java虛擬機內部創建了一個又一個相互隔離的Java類空間。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享