做Java開(kāi)發(fā)，對(duì)于ClassLoader的機(jī)制是必須要熟悉的基礎(chǔ)知識(shí)，本文針對(duì)Java ClassLoader的機(jī)制做一個(gè)簡(jiǎn)要的總結(jié)。因?yàn)椴煌腏VM的實(shí)現(xiàn)不同，本文所描述的內(nèi)容均只限于Hotspot Jvm.

本文將會(huì)從JDK默認(rèn)的提供的ClassLoader，雙親委托模型，如何自定義ClassLoader以及Java中打破雙親委托機(jī)制的場(chǎng)景四個(gè)方面入手去討論和總結(jié)一下。

JDK默認(rèn)ClassLoader

JDK 默認(rèn)提供了如下幾種ClassLoader

Bootstrp loader

Bootstrp加載器是用C++語(yǔ)言寫的，它是在Java虛擬機(jī)啟動(dòng)后初始化的，它主要負(fù)責(zé)加載%JAVA_HOME%/jre/lib,-Xbootclasspath參數(shù)指定的路徑以及%JAVA_HOME%/jre/classes中的類。

ExtClassLoader

Bootstrp loader加載ExtClassLoader,并且將ExtClassLoader的父加載器設(shè)置為Bootstrp loader.ExtClassLoader是用Java寫的，具體來(lái)說(shuō)就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加載%JAVA_HOME%/jre/lib/ext，此路徑下的所有classes目錄以及java.ext.dirs系統(tǒng)變量指定的路徑中類庫(kù)。

AppClassLoader

Bootstrp loader加載完ExtClassLoader后，就會(huì)加載AppClassLoader,并且將AppClassLoader的父加載器指定為 ExtClassLoader。AppClassLoader也是用Java寫成的，它的實(shí)現(xiàn)類是 sun.misc.Launcher$AppClassLoader，另外我們知道ClassLoader中有個(gè)getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要負(fù)責(zé)加載classpath所指定的位置的類或者是jar文檔，它也是Java程序默認(rèn)的類加載器。

雙親委托模型

Java中ClassLoader的加載采用了雙親委托機(jī)制，采用雙親委托機(jī)制加載類的時(shí)候采用如下的幾個(gè)步驟：

當(dāng)前ClassLoader首先從自己已經(jīng)加載的類中查詢是否此類已經(jīng)加載，如果已經(jīng)加載則直接返回原來(lái)已經(jīng)加載的類。

每個(gè)類加載器都有自己的加載緩存，當(dāng)一個(gè)類被加載了以后就會(huì)放入緩存，等下次加載的時(shí)候就可以直接返回了。

當(dāng)前classLoader的緩存中沒(méi)有找到被加載的類的時(shí)候，委托父類加載器去加載，父類加載器采用同樣的策略，首先查看自己的緩存，然后委托父類的父類去加載，一直到bootstrp ClassLoader.

當(dāng)所有的父類加載器都沒(méi)有加載的時(shí)候，再由當(dāng)前的類加載器加載，并將其放入它自己的緩存中，以便下次有加載請(qǐng)求的時(shí)候直接返回。

說(shuō)到這里大家可能會(huì)想，Java為什么要采用這樣的委托機(jī)制？理解這個(gè)問(wèn)題，我們引入另外一個(gè)關(guān)于Classloader的概念“命名空間”， 它是指要確定某一個(gè)類，需要類的全限定名以及加載此類的ClassLoader來(lái)共同確定。也就是說(shuō)即使兩個(gè)類的全限定名是相同的，但是因?yàn)椴煌?ClassLoader加載了此類，那么在JVM中它是不同的類。明白了命名空間以后，我們?cè)賮?lái)看看委托模型。采用了委托模型以后加大了不同的 ClassLoader的交互能力，比如上面說(shuō)的，我們JDK本生提供的類庫(kù)，比如hashmap,linkedlist等等，這些類由bootstrp 類加載器加載了以后，無(wú)論你程序中有多少個(gè)類加載器，那么這些類其實(shí)都是可以共享的，這樣就避免了不同的類加載器加載了同樣名字的不同類以后造成混亂。

如何自定義ClassLoader

Java除了上面所說(shuō)的默認(rèn)提供的classloader以外，它還容許應(yīng)用程序可以自定義classloader，那么要想自定義classloader我們需要通過(guò)繼承java.lang.ClassLoader來(lái)實(shí)現(xiàn),接下來(lái)我們就來(lái)看看在自定義Classloader的時(shí)候，我們需要注意的幾個(gè)重要的方法：

1.loadClass 方法

loadClass method declare

public Class<?> loadClass(String name) throws ClassNotFoundException

上面是loadClass方法的原型聲明，上面所說(shuō)的雙親委托機(jī)制的實(shí)現(xiàn)其實(shí)就是在此方法中實(shí)現(xiàn)的。下面我們就來(lái)看看此方法的代碼來(lái)看看它到底如何實(shí)現(xiàn)雙親委托的。

loadClass method implement

public Class<?> loadClass(String name) throws ClassNotFoundException
 { 
return loadClass(name, false);
}

從上面可以看出loadClass方法調(diào)用了loadcClass(name,false)方法，那么接下來(lái)我們?cè)賮?lái)看看另外一個(gè)loadClass方法的實(shí)現(xiàn)。

Class loadClass(String name, boolean resolve)

protected synchronized Class<?> loadClass(String name, Boolean resolve) throws ClassNotFoundException  
 {
	// First, check if the class has already been loaded 
	Class c = findLoadedClass(name);
	//檢查class是否已經(jīng)被加載過(guò)了 
	if (c == null)
	{
		try {
			if (parent != null) {
				c = parent.loadClass(name, false);
				//如果沒(méi)有被加載，且指定了父類加載器，則委托父加載器加載。
			} else {
				c = findBootstrapClass0(name);
				//如果沒(méi)有父類加載器，則委托bootstrap加載器加載   }
			}
			catch (ClassNotFoundException e) {
				// If still not found, then invoke findClass in order     
				// to find the class.     
				c = findClass(name);
				//如果父類加載沒(méi)有加載到，則通過(guò)自己的findClass來(lái)加載。   }
			}
			if (resolve) 
			{
				resolveClass(c);
			}
			return c;
		}

上面的代碼，我加了注釋通過(guò)注釋可以清晰看出loadClass的雙親委托機(jī)制是如何工作的。 這里我們需要注意一點(diǎn)就是public Class<?> loadClass(String name) throws ClassNotFoundException沒(méi)有被標(biāo)記為final，也就意味著我們是可以override這個(gè)方法的，也就是說(shuō)雙親委托機(jī)制是可以打破的。另外上面注意到有個(gè)findClass方法，接下來(lái)我們就來(lái)說(shuō)說(shuō)這個(gè)方法到底是搞末子的。

2.findClass

我們查看java.lang.ClassLoader的源代碼，我們發(fā)現(xiàn)findClass的實(shí)現(xiàn)如下：

 protected Class<?> findClass(String name) throws ClassNotFoundException
 { 
throw new ClassNotFoundException(name);
}

我們可以看出此方法默認(rèn)的實(shí)現(xiàn)是直接拋出異常，其實(shí)這個(gè)方法就是留給我們應(yīng)用程序來(lái)override的。那么具體的實(shí)現(xiàn)就看你的實(shí)現(xiàn)邏輯了，你可以從磁盤讀取，也可以從網(wǎng)絡(luò)上獲取class文件的字節(jié)流，獲取class二進(jìn)制了以后就可以交給defineClass來(lái)實(shí)現(xiàn)進(jìn)一步的加載。defineClass我們?cè)傧旅嬖賮?lái)描述。 ok，通過(guò)上面的分析，我們可以得出如下結(jié)論：

我們?cè)趯懽约旱腃lassLoader的時(shí)候，如果想遵循雙親委托機(jī)制，則只需要override findClass.

3.defineClass

我們首先還是來(lái)看看defineClass的源碼：

defineClass

protected final Class<?> defineClass(String name, byte[] b, int off, int len) 
throws ClassFormatError
{   
 return defineClass(name, b, off, len, null);
}

從上面的代碼我們看出此方法被定義為了final，這也就意味著此方法不能被Override，其實(shí)這也是jvm留給我們的唯一的入口，通過(guò)這個(gè)唯一的入口，jvm保證了類文件必須符合Java虛擬機(jī)規(guī)范規(guī)定的類的定義。此方法最后會(huì)調(diào)用native的方法來(lái)實(shí)現(xiàn)真正的類的加載工作。

Ok,通過(guò)上面的描述，我們來(lái)思考下面一個(gè)問(wèn)題：

假如我們自己寫了一個(gè)java.lang.String的類，我們是否可以替換調(diào)JDK本身的類？

答案是否定的。我們不能實(shí)現(xiàn)。為什么呢？我看很多網(wǎng)上解釋是說(shuō)雙親委托機(jī)制解決這個(gè)問(wèn)題，其實(shí)不是非常的準(zhǔn)確。因?yàn)殡p親委托機(jī)制是可以打破的，你完全可以自己寫一個(gè)classLoader來(lái)加載自己寫的java.lang.String類，但是你會(huì)發(fā)現(xiàn)也不會(huì)加載成功，具體就是因?yàn)獒槍?duì)java.*開(kāi)頭的類，jvm的實(shí)現(xiàn)中已經(jīng)保證了必須由bootstrp來(lái)加載。

不遵循“雙親委托機(jī)制”的場(chǎng)景

上面說(shuō)了雙親委托機(jī)制主要是為了實(shí)現(xiàn)不同的ClassLoader之間加載的類的交互問(wèn)題，被大家公用的類就交由父加載器去加載，但是Java中確實(shí)也存在父類加載器加載的類需要用到子加載器加載的類的情況。下面我們就來(lái)說(shuō)說(shuō)這種情況的發(fā)生。

Java中有一個(gè)SPI(ServiceProviderInterface)標(biāo)準(zhǔn),使用了SPI的庫(kù)，比如JDBC，JNDI等，我們都知道JDBC需要第三方提供的驅(qū)動(dòng)才可以，而驅(qū)動(dòng)的jar包是放在我們應(yīng)用程序本身的classpath的，而jdbc本身的api是jdk提供的一部分，它已經(jīng)被bootstrp加載了，那第三方廠商提供的實(shí)現(xiàn)類怎么加載呢？這里面JAVA引入了線程上下文類加載的概念，線程類加載器默認(rèn)會(huì)從父線程繼承，如果沒(méi)有指定的話，默認(rèn)就是系統(tǒng)類加載器（AppClassLoader）,這樣的話當(dāng)加載第三方驅(qū)動(dòng)的時(shí)候，就可以通過(guò)線程的上下文類加載器來(lái)加載。

另外為了實(shí)現(xiàn)更靈活的類加載器OSGI以及一些Javaappserver也打破了雙親委托機(jī)制。

總結(jié)

以上就是本文關(guān)于Java Classloader機(jī)制用法代碼解析的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其他相關(guān)專題，如有不足之處，歡迎留言指出。感謝朋友們對(duì)本站的支持！

最新評(píng)論