轉載地址：http://my.oschina.net/aminqiao/blog/262601
做Java開發，對於ClassLoader的機制是必須要熟悉的基礎知識，本文針對Java ClassLoader的機制做一個簡要的總結。因爲不同的JVM的實現不同，本文所描述的內容均只限於Hotspot Jvm.
本文將會從JDK默認的提供的ClassLoader，雙親委託模型，如何自定義ClassLoader以及Java中打破雙親委託機制的場景四個方面入手去討論和總結一下。
JDK默認ClassLoader
JDK 默認提供瞭如下幾種ClassLoader
-
Bootstrp loader
Bootstrp加載器是用C++語言寫的，它是在Java虛擬機啓動後初始化的，它主要負責加載%JAVA_HOME%/jre/lib,-Xbootclasspath參數指定的路徑以及%JAVA_HOME%/jre/classes中的類。
-
ExtClassLoader
Bootstrp loader加載ExtClassLoader,並且將ExtClassLoader的父加載器設置爲Bootstrp loader.ExtClassLoader是用Java寫的，具體來說就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加載%JAVA_HOME%/jre/lib/ext，此路徑下的所有classes目錄以及java.ext.dirs系統變量指定的路徑中類庫。 -
AppClassLoader
Bootstrp loader加載完ExtClassLoader後，就會加載AppClassLoader,並且將AppClassLoader的父加載器指定爲 ExtClassLoader。AppClassLoader也是用Java寫成的，它的實現類是 sun.misc.Launcher$AppClassLoader，另外我們知道ClassLoader中有個getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要負責加載classpath所指定的位置的類或者是jar文檔，它也是Java程序默認的類加載器。
雙親委託模型
Java中ClassLoader的加載採用了雙親委託機制，採用雙親委託機制加載類的時候採用如下的幾個步驟：
-
當前ClassLoader首先從自己已經加載的類中查詢是否此類已經加載，如果已經加載則直接返回原來已經加載的類。
每個類加載器都有自己的加載緩存，當一個類被加載了以後就會放入緩存，等下次加載的時候就可以直接返回了。
-
當前classLoader的緩存中沒有找到被加載的類的時候，委託父類加載器去加載，父類加載器採用同樣的策略，首先查看自己的緩存，然後委託父類的父類去加載，一直到bootstrp ClassLoader.
-
當所有的父類加載器都沒有加載的時候，再由當前的類加載器加載，並將其放入它自己的緩存中，以便下次有加載請求的時候直接返回。
說到這裏大家可能會想，Java爲什麼要採用這樣的委託機制？理解這個問題，我們引入另外一個關於Classloader的概念“命名空間”， 它是指要確定某一個類，需要類的全限定名以及加載此類的ClassLoader來共同確定。也就是說即使兩個類的全限定名是相同的，但是因爲不同的 ClassLoader加載了此類，那麼在JVM中它是不同的類。明白了命名空間以後，我們再來看看委託模型。採用了委託模型以後加大了不同的 ClassLoader的交互能力，比如上面說的，我們JDK本生提供的類庫，比如hashmap,linkedlist等等，這些類由bootstrp 類加載器加載了以後，無論你程序中有多少個類加載器，那麼這些類其實都是可以共享的，這樣就避免了不同的類加載器加載了同樣名字的不同類以後造成混亂。
如何自定義ClassLoader
Java除了上面所說的默認提供的classloader以外，它還容許應用程序可以自定義classloader，那麼要想自定義classloader我們需要通過繼承java.lang.ClassLoader來實現,接下來我們就來看看再自定義Classloader的時候，我們需要注意的幾個重要的方法：
1.loadClass 方法
loadClass method declare
|
|
public Class<?> loadClass(String name) throws ClassNotFoundException |
上面是loadClass方法的原型聲明，上面所說的雙親委託機制的實現其實就實在此方法中實現的。下面我們就來看看此方法的代碼來看看它到底如何實現雙親委託的。
loadClass method implement
|
|
public Class<?> loadClass(String name) throws ClassNotFoundException
{
return loadClass(name, false);
}
|
從上面可以看出loadClass方法調用了loadcClass(name,false)方法，那麼接下來我們再來看看另外一個loadClass方法的實現。
Class loadClass(String name, boolean resolve)
|
|
|
上面的代碼，我加了註釋通過註釋可以清晰看出loadClass的雙親委託機制是如何工作的。 這裏我們需要注意一點就是public
Class<?> loadClass(String name) throws ClassNotFoundException沒有被標記爲final，也就意味着我們是可以override這個方法的，也就是說雙親委託機制是可以打破的。另外上面注意到有個findClass方法，接下來我們就來說說這個方法到底是搞末子的。
2.findClass
我們查看java.lang.ClassLoader的源代碼，我們發現findClass的實現如下：
|
|
protected Class<?> findClass(String name) throws ClassNotFoundException
{
throw new ClassNotFoundException(name);
}
|
我們可以看出此方法默認的實現是直接拋出異常，其實這個方法就是留給我們應用程序來override的。那麼具體的實現就看你的實現邏輯了，你可以從磁盤讀取，也可以從網絡上獲取class文件的字節流，獲取class二進制了以後就可以交給defineClass來實現進一步的加載。defineClass我們再下面再來描述。
ok，通過上面的分析，我們可以得出如下結論：
我們在寫自己的ClassLoader的時候，如果想遵循雙親委託機制，則只需要override
findClass.
3.defineClass
我們首先還是來看看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，其實這也是jvm留給我們的唯一的入口，通過這個唯 一的入口，jvm保證了類文件必須符合Java虛擬機規範規定的類的定義。此方法最後會調用native的方法來實現真正的類的加載工作。
Ok,通過上面的描述，我們來思考下面一個問題：
假如我們自己寫了一個java.lang.String的類，我們是否可以替換調JDK本身的類？答案是否定的。我們不能實現。爲什麼呢？我看很多網上解釋是說雙親委託機制解決這個問題，其實不是非常的準確。因爲雙親委託機制是可以打破的，你完全可以自己寫一個classLoader來加載自己寫的
java.lang.String類，但是你會發現也不會加載成功，具體就是因爲針對java.*開頭的類，jvm的實現中已經保證了必須由bootstrp來加載。
不遵循“雙親委託機制”的場景
上面說了雙親委託機制主要是爲了實現不同的ClassLoader之間加載的類的交互問題，被大家公用的類就交由父加載器去加載，但是Java中確實也存在父類加載器加載的類需要用到子加載器加載的類的情況。下面我們就來說說這種情況的發生。
Java中有一個SPI(Service Provider Interface)標準,使用了SPI的庫，比如JDBC，JNDI等，我們都知道JDBC需要第三方提供的驅動纔可以，而驅動的jar包是放在我們應 用程序本身的classpath的，而jdbc 本身的api是jdk提供的一部分，它已經被bootstrp加載了，那第三方廠商提供的實現類怎麼加載呢？這裏面JAVA引入了線程上下文類加載的概 念，線程類加載器默認會從父線程繼承，如果沒有指定的話，默認就是系統類加載器（AppClassLoader）,這樣的話當加載第三方驅動的時候，就可
以通過線程的上下文類加載器來加載。
另外爲了實現更靈活的類加載器OSGI以及一些Java app server也打破了雙親委託機制。