本博客將沿用中展示的自定義類加載器代碼
複雜類加載情況分析
測試代碼一
首先，新建一個類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);的運行結果為false，classLoader1和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地圖已可更新顯示潭子電動車充電站設置地點!!
※帶您來看台北網站建置，台北網頁設計，各種案例分享
新能源汽車試點專項按照動力電池與電池管理系統、電機驅動與電力電子、電動汽車智慧化、燃料電池動力系統、插電/增程式混合動力系統和純電動力系統6個創新鏈，共部署38個重點研究任務，專項實施週期為5年。其中，對於插電式混合動力系統的考核標準已經逐步完善，對新型高性價比乘用車混合動力總成開發與整車集成的考核標準為：整車加速時間0-100km/h≤5s，0-50km/h≤2.5s；綜合工況純電續駛里程≥70km；燃油消耗量較第四階段油耗限值降低比例≥40%；整車實現銷售≥5000台。 純電動汽車未來的百公里加速要在6S以內，專項對純電動力系統的其中一項考核標準是，在工況下，最大爬坡度≥30%，純電續駛里程≥300km，0-100km/h加速時間≤6s，30分鐘最高車速≥120km/h；電制動降低電能消耗率≥25%；整車具備安全穩定的轉向功能，並實現小批量試驗運行。 電動汽車目前的關鍵技術在於動力電池，專項對與新能源汽車的動力電池和電池管理系統的考核標準是：提交高比能鋰離子電池的安全風險識別方法與評測報告；建立電池的安全評測體系，形成相關安全標準；電池單體能量密度≥300Wh/kg，迴圈壽命≥1500次，成本≤0.8元/Wh，安全性達到國標要求，年生產能力≥1億瓦時。 文章來源：EV世紀
