類與類加載器

虛擬機(jī)設(shè)計(jì)團(tuán)隊(duì)把類加載階段張的"通過(guò)一個(gè)類的全限定名來(lái)獲取此類的二進(jìn)制字節(jié)流"這個(gè)動(dòng)作放到Java虛擬機(jī)外部去實(shí)現(xiàn)，以便讓應(yīng)用程序自己決定如何去獲取所需要的類。實(shí)現(xiàn)這個(gè)動(dòng)作的代碼模塊稱為"類加載器"。類加載器雖然只用于實(shí)現(xiàn)類的加載動(dòng)作，但它在Java程序中起到的作用卻遠(yuǎn)遠(yuǎn)不限定于類加載階段。對(duì)于任意一個(gè)類，都需要由加載它的類加載器和這個(gè)類本身一同確立其在Java虛擬機(jī)中的唯一性，每一個(gè)類加載器，都擁有一個(gè)獨(dú)立的類名稱空間。這句話表達(dá)地再簡(jiǎn)單一點(diǎn)就是：比較兩個(gè)類是否"相等"，只有在這兩個(gè)類是由同一個(gè)類加載器加載的前提下才有意義，否則即使這兩個(gè)類來(lái)源于同一個(gè).class文件，被同一個(gè)虛擬機(jī)加載，只要加載它們的類加載器不同，這兩個(gè)類必定不相等。

上面說(shuō)的"相等"，包括代表類的.class對(duì)象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回結(jié)果，也包括使用instanceof關(guān)鍵字做對(duì)象所屬關(guān)系判定等情況。

?

類加載器模型

從Java虛擬機(jī)的角度講，只有兩種不同的類加載器：啟動(dòng)類加載器Bootstrap ClassLoader，這個(gè)類加載器是由C++語(yǔ)言實(shí)現(xiàn)的，是虛擬機(jī)自身的一部分；其他類加載器，這些類加載器都由Java語(yǔ)言實(shí)現(xiàn)，獨(dú)立于虛擬機(jī)外部，并且全部繼承自java.lang.ClassLoader。從開發(fā)人員的角度講，類加載器還可以劃分地更加細(xì)致一些，一張圖就能說(shuō)明：

關(guān)于這張圖首先說(shuō)兩點(diǎn)：

1、這三個(gè)層次的類加載器并不是繼承關(guān)系，而只是層次上的定義

2、它并不是一個(gè)強(qiáng)制性的約束模型，而是Java設(shè)計(jì)者推薦給開發(fā)者的一種類加載器實(shí)現(xiàn)方式

OK，然后一個(gè)一個(gè)類加載器來(lái)看：

1、啟動(dòng)類加載器Bootstrap ClassLoader

之前說(shuō)過(guò)了這是一個(gè)嵌在JVM內(nèi)核中的加載器。它負(fù)責(zé)加載的是JAVA_HOME/lib下的類庫(kù)，系統(tǒng)類加載器無(wú)法被Java程序直接應(yīng)用

2、擴(kuò)展類加載器Extension ClassLoader

這個(gè)類加載器由sun.misc.Launcher$ExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)用于加載JAVA_HOME/lib/ext目錄中的，或者被java.ext.dirs系統(tǒng)變量指定所指定的路徑中所有類庫(kù)，開發(fā)者可以直接使用擴(kuò)展類加載器。java.ext.dirs系統(tǒng)變量所指定的路徑的可以通過(guò)程序來(lái)查看

public class TestMain {public static void main(String[] args){System.out.println(System.getProperty("java.ext.dirs"));} }

運(yùn)行結(jié)果

E:\MyEclipse10\Common\binary\com.sun.java.jdk.win32.x86_64_1.6.0.013\jre\lib\ext;C:\Windows\Sun\Java\lib\ext

3、應(yīng)用程序類加載器Application ClassLoader

這個(gè)類加載器由sun.misc.Launcher$AppClassLoader實(shí)現(xiàn)。這個(gè)類也一般被稱為系統(tǒng)類加載器，寫個(gè)小程序看下：

public class TestMain {public static void main(String[] args){System.out.println(ClassLoader.getSystemClassLoader());} }

運(yùn)行結(jié)果為：

sun.misc.Launcher$AppClassLoader@546b97fd

看到通過(guò)"ClassLoader.getSystemClassLoader"，得到的是sun.misc.Launcher$AppClassLoader，這也證明了JDK認(rèn)為Application ClassLoader是系統(tǒng)類加載器。順便根據(jù)類加載器模型，打印一下這個(gè)類的父加載器：

public class TestMain {public static void main(String[] args){System.out.println(ClassLoader.getSystemClassLoader().getParent());} }

運(yùn)行結(jié)果為：

sun.misc.Launcher$ExtClassLoader@535ff48b

看出Application ClassLoader的父加載器確實(shí)是Extension ClassLoader，符合圖中的模型。那么再打印父加載器呢？按照我們的想法應(yīng)該是Bootstrap ClassLoader了，看下是不是：

public class TestMain {public static void main(String[] args){System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());} }

運(yùn)行結(jié)果為：

null

這會(huì)打印出來(lái)的是null了。其實(shí)也很好理解，Bootstrap ClassLoader以外的ClassLoader都是Java實(shí)現(xiàn)的，因此這些ClassLoader勢(shì)必在Java堆中有一份實(shí)例在，所以Extension ClassLoader和Application ClassLoader都能打印出內(nèi)容來(lái)。但是Bootstrap ClassLoader是JVM的一部分，是用C/C++寫的，不屬于Java，自然在Java堆中也沒有自己的空間，所以就返回null了。所以，如果ClassLoader得到的是null，那么表示的ClassLoader就是Bootstrap ClassLoader。

另外要說(shuō)很重要的一點(diǎn)，反編譯一下rt.jar，找到sun.misc.Launcher看一下Application ClassLoader的實(shí)現(xiàn)：

1 static class AppClassLoader extends URLClassLoader 2 { 3 public static ClassLoader getAppClassLoader(final ClassLoader paramClassLoader) 4 throws IOException 5 { 6 String str = System.getProperty("java.class.path"); 7 final File[] arrayOfFile = str == null ? new File[0] : Launcher.getClassPath(str); 8 return (ClassLoader)AccessController.doPrivileged(new PrivilegedAction() 9 { 10 public Launcher.AppClassLoader run() 11 { 12 URL[] arrayOfURL = this.val$s == null ? new URL[0] : Launcher.pathToURLs(arrayOfFile); 13 return new Launcher.AppClassLoader(arrayOfURL, paramClassLoader); 14 } 15 }); 16 }

重點(diǎn)就在第6行，Application ClassLoader只會(huì)加載java.class.path下的.class文件，java.class.path代表的是什么路徑？打印一下：

public class TestMain {public static void main(String[] args){System.out.println(System.getProperty("java.class.path"));} }

運(yùn)行結(jié)果為：

F:\代碼\MyEclipse\TestArticle\bin;F:\學(xué)習(xí)\第三方j(luò)ar包\XStream\xstream-1.4.jar;F:\學(xué)習(xí)\第三方j(luò)ar包\XStream\kxml2.jar

我這里有添加兩個(gè).jar到CLASSPATH下。那也可以下一個(gè)重要的結(jié)論了：

Application ClassLoader只能加載項(xiàng)目bin目錄下的.class文件。

?

雙親委派模型

最后講一下雙親委派模型，其實(shí)上面的類加載器模型圖就是一個(gè)雙親委派模式的圖，這里把它再講清楚一點(diǎn)。

雙親委派模型是在JDK1.2期間被引入的，其工作過(guò)程可以分為兩步：

1、如果一個(gè)類加載器收到了類加載的請(qǐng)求，它首先不會(huì)自己去嘗試加載這個(gè)類，而是把這個(gè)請(qǐng)求委派給父類加載器去完成，每一個(gè)層次的類加載器都是如此。

2、只有當(dāng)父加載器反饋?zhàn)约簾o(wú)法完成這這個(gè)加載請(qǐng)求（它的搜索范圍中沒有找到所需的類）時(shí)，子加載器才會(huì)嘗試自己去加載

所以，其實(shí)所有的加載請(qǐng)求最終都應(yīng)該傳送到頂層的啟動(dòng)類加載器中。雙親委派模型對(duì)于Java程序的穩(wěn)定運(yùn)作很重要，因?yàn)镴ava類隨著它的加載器一起具備了一種帶有優(yōu)先級(jí)的層次關(guān)系。例如java.lang.Object，存放于rt.jar中，無(wú)論哪一個(gè)類加載器要去加載這個(gè)類，最終都是由Bootstrap ClassLoader去加載，因此Object類在程序的各種類加載器環(huán)境中都是一個(gè)類。相反，如果沒有雙親委派模型，由各個(gè)類自己去加載的話，如果用戶自己編寫了一個(gè)java.lang.Object，并放在CLASSPATH下，那系統(tǒng)中將會(huì)出現(xiàn)多個(gè)不同的Object類，Java體系中最基礎(chǔ)的行為也將無(wú)法保證，應(yīng)用程序也將會(huì)變得一片混亂。

轉(zhuǎn)載于:https://www.cnblogs.com/xrq730/p/4845144.html

總結(jié)

以上是生活随笔為你收集整理的Java虚拟机10：类加载器的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。