你們都知道,當咱們寫好一個Java程序以後,不是管是CS仍是BS應用,都是由若干個.class文件組織而成的一個完整的Java應用程序,當程序在運行時,即會調用該程序的一個入口函數來調用系統的相關功能,而這些功能都被封裝在不一樣的class文件當中,因此常常要從這個class文件中要調用另一個class文件中的方法,若是另一個文件不存在的,則會引起系統異常。而程序在啓動的時候,並不會一次性加載程序所要用的全部class文件,而是根據程序的須要,經過Java的類加載機制(ClassLoader)來動態加載某個class文件到內存當中的,從而只有class文件被載入到了內存以後,才能被其它class所引用。因此ClassLoader就是用來動態加載class文件到內存當中用的。html
2、Java默認提供的三個ClassLoaderjava
1:BootStrap ClassLoader:稱爲啓動類加載器,是Java類加載層次中最頂層的類加載器,負責加載JDK中的核心類庫,如:rt.jar、resources.jar、charsets.jar等.算法
2:Extension ClassLoader:稱爲擴展類加載器,負責加載Java的擴展類庫,默認加載JAVA_HOME/jre/lib/ext/目下的全部jar。api
3:App ClassLoader:稱爲系統類加載器,負責加載應用程序classpath目錄下的全部jar和class文件。安全
注意: 除了Java默認提供的三個ClassLoader以外,用戶還能夠根據須要定義自已的ClassLoader,而這些自定義的ClassLoader都必須繼承自java.lang.ClassLoader類,也包括Java提供的另外二個ClassLoader(Extension ClassLoader和App ClassLoader)在內,可是Bootstrap ClassLoader不繼承自ClassLoader,由於它不是一個普通的Java類,底層由C++編寫,已嵌入到了JVM內核當中,當JVM啓動後,Bootstrap ClassLoader也隨着啓動,負責加載完核心類庫後,並構造Extension ClassLoader和App ClassLoader類加載器。網絡
ClassLoader使用的是雙親委託模型來搜索類的,每一個ClassLoader實例都有一個父類加載器的引用(不是繼承的關係,是一個包含的關係),虛擬機內置的類加載器(Bootstrap ClassLoader)自己沒有父類加載器,但能夠用做其它ClassLoader實例的的父類加載器。當一個ClassLoader實例須要加載某個類時,它會試圖親自搜索某個類以前,先把這個任務委託給它的父類加載器,這個過程是由上至下依次檢查的,首先由最頂層的類加載器Bootstrap ClassLoader試圖加載,若是沒加載到,則把任務轉交給Extension ClassLoader試圖加載,若是也沒加載到,則轉交給App ClassLoader 進行加載,若是它也沒有加載獲得的話,則返回給委託的發起者,由它到指定的文件系統或網絡等URL中加載該類。若是它們都沒有加載到這個類時,則拋出ClassNotFoundException異常。不然將這個找到的類生成一個類的定義,並將它加載到內存當中,最後返回這個類在內存中的Class實例對象。架構
二、爲何要使用雙親委託這種模型呢?函數
由於這樣能夠避免重複加載,當父親已經加載了該類的時候,就沒有必要子ClassLoader再加載一次。考慮到安全因素,咱們試想一下,若是不使用這種委託模式,那咱們就能夠隨時使用自定義的String來動態替代java核心api中定義的類型,這樣會存在很是大的安全隱患,而雙親委託的方式,就能夠避免這種狀況,由於String已經在啓動時就被引導類加載器(Bootstrcp ClassLoader)加載,因此用戶自定義的ClassLoader永遠也沒法加載一個本身寫的String,除非你改變JDK中ClassLoader搜索類的默認算法。spa
三、 可是JVM在搜索類的時候,又是如何斷定兩個class是相同的呢?htm
JVM在斷定兩個class是否相同時,不只要判斷兩個類名是否相同,並且要判斷是否由同一個類加載器實例加載的。只有二者同時知足的狀況下,JVM才認爲這兩個class是相同的。就算兩個class是同一份class字節碼,若是被兩個不一樣的ClassLoader實例所加載,JVM也會認爲它們是兩個不一樣class。好比網絡上的一個Java類org.classloader.simple.NetClassLoaderSimple,javac編譯以後生成字節碼文件NetClassLoaderSimple.class,ClassLoaderA和ClassLoaderB這兩個類加載器並讀取了NetClassLoaderSimple.class文件,並分別定義出了java.lang.Class實例來表示這個類,對於JVM來講,它們是兩個不一樣的實例對象,但它們確實是同一份字節碼文件,若是試圖將這個Class實例生成具體的對象進行轉換時,就會拋運行時異常java.lang.ClassCaseException,提示這是兩個不一樣的類型。
四、ClassLoader的體系架構:
//得到加載ClassLoaderTest.class這個類的類加載器 ClassLoader loader = ClassLoaderTest.class.getClassLoader(); while(loader != null) { System.out.println(loader); loader = loader.getParent(); //得到父類加載器的引用 } System.out.println(loader);
控制檯打印出:
sun.misc.Launcher$AppClassLoader@8391b0c
sun.misc.Launcher$ExtClassLoader@5d1eb50b
null
第一行結果說明:ClassLoaderTest的類加載器是AppClassLoader。
第二行結果說明:AppClassLoader的類加器是ExtClassLoader,即parent=ExtClassLoader。
第三行結果說明:ExtClassLoader的類加器是Bootstrap ClassLoader,由於Bootstrap ClassLoader不是一個普通的Java類,因此ExtClassLoader的parent=null,因此第三行的打印結果爲null就是這個緣由。
4、定義自已的ClassLoader
既然JVM已經提供了默認的類加載器,爲何還要定義自已的類加載器呢?
由於Java中提供的默認ClassLoader,只加載指定目錄下的jar和class,若是咱們想加載其它位置的類或jar時,好比:我要加載網絡上的一個class文件,經過動態加載到內存以後,要調用這個類中的方法實現個人業務邏輯。在這樣的狀況下,默認的ClassLoader就不能知足咱們的需求了,因此須要定義本身的ClassLoader。
定義自已的類加載器分爲兩步:
一、繼承java.lang.ClassLoader
二、重寫父類的findClass方法
讀者可能在這裏有疑問,父類有那麼多方法,爲何恰恰只重寫findClass方法?
由於JDK已經在loadClass方法中幫咱們實現了ClassLoader搜索類的算法,當在loadClass方法中搜索不到類時,loadClass方法就會調用findClass方法來搜索類,因此咱們只需重寫該方法便可。如沒有特殊的要求,通常不建議重寫loadClass搜索類的算法。
來源:http://www.importnew.com/15362.html