糯米文學吧

位置:首頁 > IT認證 > JAVA認證

Java ClassLoader原理深入講解

JAVA認證1.03W

JAVA啟動後,是經過JVM各級ClassLoader來加載各個類到內存。為了更加了解加載過程,下面為大家深入講解Java ClassLoader原理,僅供參考!

Java ClassLoader原理深入講解

  當JVM(Java虛擬機)啟動時,會形成由三個類加載器組成的初始類加載器層次結構:

bootstrap classloader

|

extension classloader

|

system classloader

bootstrap classloader -引導(也稱為原始)類加載器,它負責加載Java的核心類。在Sun的JVM中,在執行java的命令中使用-Xbootclasspath選項或使用 - D選項指定系統屬性值可以指定附加的類。這個加載器的是非常特殊的,它實際上不是 sLoader的子類,而是由JVM自身實現的。大家可以通過執行以下代碼來獲得bootstrap classloader加載了那些核心類庫:

URL[] urls=ootstrapClassPath()RLs();

for (int i = 0; i < th; i++) {

tln(ternalform());

}

在我的計算機上的結果為:

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/lib/

文件:/C:/j2sdk1.4.1_01/jre/classes

這時大家知道了為什麼我們不需要在系統屬性CLASSPATH中指定這些類庫了吧,因為JVM在啟動的時候就自動加載它們了。

extension classloader -擴展類加載器,它負責加載JRE的擴展目錄(JAVA_HOME/jre/lib/ext或者由系統屬性指定的)中JAR的 類包。這為引入除Java核心類以外的新功能提供了一個標準機制。因為默認的擴展目錄對所有從同一個JRE中啟動的JVM都是通用的,所以放入這個目錄的 JAR類包對所有的JVM和system classloader都是可見的。在這個實例上調用方法getParent()總是返回空值null,因為引導加載器bootstrap classloader不是一個真正的ClassLoader實例。所以當大家執行以下代碼時:

tln(roperty(""));

ClassLoader extensionClassloader=ystemClassLoader()arent();

tln("the parent of extension classloader : "+arent());

  結果為:

C:/j2sdk1.4.1_01/jre/lib/ext

the parent of extension classloader : null

extension classloader是system classloader的parent,而bootstrap classloader是extension classloader的parent,但它不是一個實際的classloader,所以為null。

system classloader -系統(也稱為應用)類加載器,它負責在JVM被啟動時,加載來自在命令java中的-classpath或者系統屬性或 者 CLASSPATH操作系統屬性所指定的JAR類包和類路徑。總能通過靜態方法ystemClassLoader()找 到該類加載器。如果沒有特別指定,則用户自定義的任何類加載器都將該類加載器作為它的父加載器。執行以下代碼即可獲得:

tln(roperty(""));

輸出結果則為用户在系統屬性裏面設置的CLASSPATH。

classloader 加載類用的是全盤負責委託機制。所謂全盤負責,即是當一個classloader加載一個Class的時候,這個Class所依賴的和引用的所有 Class也由這個classloader負責載入,除非是顯式的使用另外一個classloader載入;委託機制則是先讓parent(父)類加載器 (而不是super,它與parent classloader類不是繼承關係)尋找,只有在parent找不到的時候才從自己的類路徑中去尋找。此外類加載還採用了cache機制,也就是如果 cache中保存了這個Class就直接返回它,如果沒有才從文件中讀取和轉換成Class,並存入cache,這就是為什麼我們修改了Class但是必 須重新啟動JVM才能生效的原因。

每個ClassLoader加載Class的過程是:

1.檢測此Class是否載入過(即在cache中是否有此Class),如果有到8,如果沒有到2

2.如果parent classloader不存在(沒有parent,那parent一定是bootstrap classloader了),到4

3.請求parent classloader載入,如果成功到8,不成功到5

4.請求jvm從bootstrap classloader中載入,如果成功到8

5.尋找Class文件(從與此classloader相關的類路徑中尋找)。如果找不到則到7.

6.從文件中載入Class,到8.

7.拋出ClassNotFoundException.

8.返回Class.

其中5.6步我們可以通過覆蓋ClassLoader的findClass方法來實現自己的載入策略。甚至覆蓋loadClass方法來實現自己的載入過程。

類加載器的順序是:

先 是bootstrap classloader,然後是extension classloader,最後才是system classloader。大家會發現加載的Class越是重要的越在靠前面。這樣做的原因是出於安全性的考慮,試想如果system classloader“親自”加載了一個具有破壞性的“em”類的後果吧。這種委託機制保證了用户即使具有一個這樣的類, 也把它加入到了類路徑中,但是它永遠不會被載入,因為這個類總是由bootstrap classloader來加載的。大家可以執行一下以下的代碼:

tln(lassLoader());

將會看到結果是null,這就表明em是由bootstrap classloader加載的,因為bootstrap classloader不是一個真正的ClassLoader實例,而是由JVM實現的,正如前面已經説過的。

下面就讓我們來看看JVM是如何來為我們來建立類加載器的結構的:

cher,顧名思義,當你執行java命令的時候,JVM會先使用bootstrap classloader載入並初始化一個Launcher,執行下來代碼:

tln("the Launcher's classloader is "+auncher()lass()lassLoader());

結果為:

the Launcher's classloader is null (因為是用bootstrap classloader加載,所以class loader為null)

Launcher 會根據系統和命令設定初始化好class loader結構,JVM就用它來獲得extension classloader和system classloader,並載入所有的需要載入的Class,最後執行java命令指定的帶有靜態的main方法的Class。extension classloader實際上是cher$ExtClassLoader類的一個實例,system classloader實際上是cher$AppClassLoader類的一個實例。並且都是 lassLoader的子類。

讓我們來看看Launcher初試化的過程的部分代碼。

Launcher的部分代碼:

public class Launcher {

public Launcher() {

ExtClassLoader extclassloader;

try {

//初始化extension classloader

extclassloader = xtClassLoader();

} catch(IOException ioexception) {

throw new InternalError("Could not create extension class loader");

}

try {

//初始化system classloader,parent是extension classloader

loader = ppClassLoader(extclassloader);

} catch(IOException ioexception1) {

throw new InternalError("Could not create application class loader");

}

//將system classloader設置成當前線程的context classloader(將在後面加以介紹)

entThread()ontextClassLoader(loader);

......

}

public ClassLoader getClassLoader() {

//返回system classloader

return loader;

}

}

extension classloader的部分代碼:

static class Launcher$ExtClassLoader extends URLClassLoader {

public static Launcher$ExtClassLoader getExtClassLoader()

throws IOException

{

File afile[] = getExtDirs();

return (Launcher$ExtClassLoader)ivileged(new Launcher$1(afile));

}

private static File[] getExtDirs() {

//獲得系統屬性“”

String s = roperty("");

File afile[];

if(s != null) {

StringTokenizer stringtokenizer = new StringTokenizer(s, Separator);

int i = tTokens();

afile = new File;

for(int j = 0; j < i; j++)

afile[j] = new File(Token());

} else {

afile = new File[0];

}

return afile;

}

}

system classloader的部分代碼:

static class Launcher$AppClassLoader extends URLClassLoader

{

public static ClassLoader getAppClassLoader(ClassLoader classloader)

throws IOException

{

//獲得系統屬性“”

String s = roperty("");

File afile[] = s != null ? ss$200(s) : new File[0];

return (Launcher$AppClassLoader)ivileged(new Launcher$2(s, afile, classloader));

}

}

看 了源代碼大家就清楚了吧,extension classloader是使用系統屬性“”設置類搜索路徑的,並且沒有parent。system classloader是使用系統屬性“”設置類搜索路徑的,並且有一個parent classloader。Launcher初始化extension classloader,system classloader,並將system classloader設置成為context classloader,但是僅僅返回system classloader給JVM。

這裏怎麼又出來一個context classloader呢?它有什麼用呢?我們在建立一個線程Thread的時候,可以為這個線程通過setContextClassLoader方法來 指定一個合適的classloader作為這個線程的context classloader,當此線程運行的時候,我們可以通過getContextClassLoader方法來獲得此context classloader,就可以用它來載入我們所需要的Class。默認的是system classloader。利用這個特性,我們可以“打破”classloader委託機制了,父classloader可以獲得當前線程的context classloader,而這個context classloader可以是它的子classloader或者其他的classloader,那麼父classloader就可以從其獲得所需的 Class,這就打破了只能向父classloader請求的限制了。這個機制可以滿足當我們的classpath是在運行時才確定,並由定製的 classloader加載的時候,由system classloader(即在jvm classpath中)加載的class可以通過context classloader獲得定製的classloader並加載入特定的class(通常是抽象類和接口,定製的classloader中是其實現),例 如web應用中的servlet就是用這種機制加載的.

好了,現在我們瞭解了classloader的結構和工作原理,那麼我們 如何實現在運行時的動態載入和更新呢?只要我們能夠動態改變類搜索路徑和清除classloader的cache中已經載入的Class就行了,有兩個方 案,一是我們繼承一個classloader,覆蓋loadclass方法,動態的尋找Class文件並使用defineClass方法來;另一個則非常 簡單實用,只要重新使用一個新的類搜索路徑來new一個classloader就行了,這樣即更新了類搜索路徑以便來載入新的Class,也重新生成了一 個空白的cache(當然,類搜索路徑不一定必須更改)。噢,太好了,我們幾乎不用做什麼工作,RLClassLoader正是一個符 合我們要求的classloader!我們可以直接使用或者繼承它就可以了!

這是j2se1.4 API的doc中URLClassLoader的兩個構造器的描述:

URLClassLoader(URL[] urls)

Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader.

URLClassLoader(URL[] urls, ClassLoader parent)

Constructs a new URLClassLoader for the given URLs.

其中URL[] urls就是我們要設置的類搜索路徑,parent就是這個classloader的parent classloader,默認的是system classloader。

好,現在我們能夠動態的載入Class了,這樣我們就可以利用newInstance方法來獲得一個Object。但我們如何將此Object造型呢?可以將此Object造型成它本身的Class嗎?

首先讓我們來分析一下java源文件的編譯,運行吧!javac命令是調用“JAVA_HOME/lib/”中的“”的compile方法來編譯:

public static int compile(String as[]);

public static int compile(String as[], PrintWriter printwriter);

返回0表示編譯成功,字符串數組as則是我們用javac命令編譯時的參數,以空格劃分。例如:

javac -classpath c:/foo/;. -d c:/ c:/

則 字符串數組as為{"-classpath","c://foo//;.","-d","c://","c://"}, 如果帶有PrintWriter參數,則會把編譯信息出到這個指定的printWriter中。默認的輸出是。

其中 Main是由JVM使用Launcher初始化的system classloader載入的,根據全盤負責原則,編譯器在解析這個java源文件時所發現的它所依賴和引用的所有Class也將由system classloader載入,如果system classloader不能載入某個Class時,編譯器將拋出一個“cannot resolve symbol”錯誤。

所以首先編譯就通不過,也就是編譯器無法編譯一個引用了不在CLASSPATH中的未知Class的java源文件,而由於拼寫錯誤或者沒有把所需類庫放到CLASSPATH中,大家一定經常看到這個“cannot resolve symbol”這個編譯錯誤吧!

其 次,就是我們把這個Class放到編譯路徑中,成功的進行了編譯,然後在運行的時候不把它放入到CLASSPATH中而利用我們自己的. classloader來動態載入這個Class,這時候也會出現“assDefFoundError”的違例,為什麼呢?

我 們再來分析一下,首先調用這個造型語句的可執行的Class一定是由JVM使用Launcher初始化的system classloader載入的,根據全盤負責原則,當我們進行造型的時候,JVM也會使用system classloader來嘗試載入這個Class來對實例進行造型,自然在system classloader尋找不到這個Class時就會拋出“assDefFoundError”的違例。

OK, 現在讓我們來總結一下,java文件的編譯和Class的載入執行,都是使用Launcher初始化的system classloader作為類載入器的,我們無法動態的改變system classloader,更無法讓JVM使用我們自己的classloader來替換system classloader,根據全盤負責原則,就限制了編譯和運行時,我們無法直接顯式的使用一個system classloader尋找不到的Class,即我們只能使用Java核心類庫,擴展類庫和CLASSPATH中的類庫中的Class。

還 不死心!再嘗試一下這種情況,我們把這個Class也放入到CLASSPATH中,讓system classloader能夠識別和載入。然後我們通過自己的classloader來從指定的class文件中載入這個Class(不能夠委託 parent載入,因為這樣會被system classloader從CLASSPATH中將其載入),然後實例化一個Object,並造型成這個Class,這樣JVM也識別這個Class(因為 system classloader能夠定位和載入這個Class從CLASSPATH中),載入的也不是CLASSPATH中的這個Class,而是從 CLASSPATH外動態載入的,這樣總行了吧!十分不幸的是,這時會出現“sCastException”違例。

為 什麼呢?我們也來分析一下,不錯,我們雖然從CLASSPATH外使用我們自己的classloader動態載入了這個Class,但將它的實例造型的時 候是JVM會使用system classloader來再次載入這個Class,並嘗試將使用我們的自己的classloader載入的Class的一個實例造型為system classloader載入的這個Class(另外的一個)。大家發現什麼問題了嗎?也就是我們嘗試將從一個classloader載入的Class的一 個實例造型為另外一個classloader載入的Class,雖然這兩個Class的名字一樣,甚至是從同一個class文件中載入。但不幸的是JVM 卻認為這個兩個Class是不同的,即JVM認為不同的classloader載入的相同的名字的Class(即使是從同一個class文件中載入的)是 不同的!這樣做的原因我想大概也是主要出於安全性考慮,這樣就保證所有的核心Java類都是system classloader載入的,我們無法用自己的classloader載入的相同名字的Class的實例來替換它們的實例。

看到這裏,聰明的讀者一定想到了該如何動態載入我們的Class,實例化,造型並調用了吧!

那 就是利用面向對象的基本特性之一的多形性。我們把我們動態載入的Class的實例造型成它的一個system classloader所能識別的父類就行了!這是為什麼呢?我們還是要再來分析一次。當我們用我們自己的classloader來動態載入這我們只要把 這個Class的時候,發現它有一個父類Class,在載入它之前JVM先會載入這個父類Class,這個父類Class是system classloader所能識別的,根據委託機制,它將由system classloader載入,然後我們的classloader再載入這個Class,創建一個實例,造型為這個父類Class,注意了,造型成這個父類 Class的時候(也就是上溯)是面向對象的java語言所允許的並且JVM也支持的,JVM就使用system classloader再次載入這個父類Class,然後將此實例造型為這個父類Class。大家可以從這個過程發現這個父類Class都是由 system classloader載入的,也就是同一個class loader載入的同一個Class,所以造型的時候不會出現任何異常。而根據多形性,調用這個父類的方法時,真正執行的是這個Class(非父類 Class)的覆蓋了父類方法的方法。這些方法中也可以引用system classloader不能識別的Class,因為根據全盤負責原則,只要載入這個Class的classloader即我們自己定義的 classloader能夠定位和載入這些Class就行了。

這樣我們就可以事先定義好一組接口或者基類並放入CLASSPATH中,然 後在執行的時候動態的載入實現或者繼承了這些接口或基類的子類。還不明白嗎?讓我們來想一想Servlet吧,web application server能夠載入任何繼承了Servlet的Class並正確的執行它們,不管它實際的Class是什麼,就是都把它們實例化成為一個Servlet Class,然後執行Servlet的init,doPost,doGet和destroy等方法的,而不管這個Servlet是從web- inf/lib和web-inf/classes下由system classloader的子classloader(即定製的classloader)動態載入。説了這麼多希望大家都明白了。在applet,ejb等 容器中,都是採用了這種機制.

對於以上各種情況,希望大家實際編寫一些example來實驗一下。

最後我再説點別的, classloader雖然稱為類加載器,但並不意味着只能用來加載Class,我們還可以利用它也獲得圖片,音頻文件等資源的URL,當然,這些資源必 須在CLASSPATH中的jar類庫中或目錄下。我們來看API的doc中關於ClassLoader的兩個尋找資源和Class的方法描述吧:

public URL getResource(String name)

用指定的名字來查找資源,一個資源是一些能夠被class代碼訪問的在某種程度上依賴於代碼位置的數據(圖片,音頻,文本等等)。

一個資源的名字是以'/'號分隔確定資源的路徑名的。

這個方法將先請求parent classloader搜索資源,如果沒有parent,則會在內置在虛擬機中的classloader(即bootstrap classloader)的路徑中搜索。如果失敗,這個方法將調用findResource(String)來尋找資源。

public static URL getSystemResource(String name)

從用來載入類的搜索路徑中查找一個指定名字的資源。這個方法使用system class loader來定位資源。即相當於ystemClassLoader()esource(name)。

例如:

tln(ystemResource("java/lang/s"));

的結果為:

jar:文件:/C:/j2sdk1.4.1_01/jre/lib/!/java/lang/s

表明s文件在的java/lang目錄中。

因此我們可以將圖片等資源隨同Class一同打包到jar類庫中(當然,也可單獨打包這些資源)並添加它們到class loader的搜索路徑中,我們就可以無需關心這些資源的具體位置,讓class loader來幫我們尋找了!