ClassLoader翻譯過來就是類載入器，普通的java開發者其實用到的不多，但對於某些框架開發者來說卻非常常見。理解ClassLoader的載入機制，也有利於我們編寫出更高效的程式碼。ClassLoader的具體作用就是將class檔案載入到jvm虛擬機器中去，程式就可以正確執行了。但是，jvm啟動的時候，並不會一次性載入所有的class檔案，而是根據需要去動態載入。想想也是的，一次性載入那麼多jar包那麼多class，那記憶體不崩潰。本文的目的也是學習ClassLoader這種載入機制。

備註：本文篇幅比較長，但內容簡單，大家不要恐慌，安靜地耐心翻閱就是

Class檔案的認識

我們都知道在Java中程式是執行在虛擬機器中，我們平常用文字編輯器或者是IDE編寫的程式都是.java格式的檔案，這是最基礎的原始碼，但這類檔案是不能直接執行的。如我們編寫一個簡單的程式HelloWorld.java

public class HelloWorld{

public static void main(String[] args){

System.out.println("Hello world!");

}

一看你就懂，超詳細 java 中的 ClassLoader 詳解

然後，我們需要在命令列中進行java檔案的編譯

javac HelloWorld.java

一看你就懂，超詳細 java 中的 ClassLoader 詳解

可以看到目錄下生成了.class檔案

我們再從命令列中執行命令：

java HelloWorld

一看你就懂，超詳細 java 中的 ClassLoader 詳解

上面是基本程式碼示例，是所有入門JAVA語言時都學過的東西，這裡重新拿出來是想讓大家將焦點回到class檔案上，class檔案是位元組碼格式檔案，java虛擬機器並不能直接識別我們平常編寫的.java原始檔，所以需要javac這個命令轉換成.class檔案。另外，如果用C或者Python編寫的程式正確轉換成.class檔案後，java虛擬機器也是可以識別執行的

瞭解了.class檔案後，我們再來思考下，我們平常在Eclipse中編寫的java程式是如何執行的，也就是我們自己編寫的各種類是如何被載入到jvm(java虛擬機器)中去的。

你還記得java環境變數嗎？

初學java的時候，最害怕的就是下載JDK後要配置環境變數了，關鍵是當時不理解，所以戰戰兢兢地照著書籍上或者是網路上的介紹進行操作。然後下次再弄的時候，又忘記了而且是必忘。當時，心裡的想法很氣憤的，想著是–這東西一點也不人性化，為什麼非要自己配置環境變數呢？太不照顧菜鳥和新手了，很多菜鳥就是因為卡在環境變數的配置上，遭受了太多的挫敗感。

因為我是在Windows下程式設計的，所以只講Window平臺上的環境變數，主要有3個：JAVA_HOME、PATH、CLASSPATH。

JAVA_HOME

指的是你JDK安裝的位置，一般預設安裝在C盤，如

C:Program FilesJavajdk1.8.0_91

PATH

將程式路徑包含在PATH當中後，在命令列視窗就可以直接鍵入它的名字了，而不再需要鍵入它的全路徑,比如上面程式碼中我用的到javac和java兩個命令。

一般的

PATH=%JAVA_HOME%bin;%JAVA_HOME%jrebin;%PATH%;

也就是在原來的PATH路徑上新增JDK目錄下的bin目錄和jre目錄的bin.

CLASSPATH

CLASSPATH=.;%JAVA_HOME%lib;%JAVA_HOME%libtools.jar

一看就是指向jar包路徑。

需要注意的是前面的.;，.代表當前目錄。

環境變數的設定與檢視

設定可以右擊我的電腦，然後點選屬性，再點選高階，然後點選環境變數，具體不明白的自行查閱文件。

檢視的話可以開啟命令列視窗

echo %JAVA_HOME%

echo %PATH%

echo %CLASSPATH%

好了，扯遠了，知道了環境變數，特別是CLASSPATH時，我們進入今天的主題Classloader.

JAVA類載入流程

Java語言系統自帶有三個類載入器:

Bootstrap ClassLoader 最頂層的載入類，主要載入核心類庫，%JRE_HOME%lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以透過啟動jvm時指定-Xbootclasspath和路徑來改變Bootstrap ClassLoader的載入目錄。比如java -Xbootclasspath/a:path被指定的檔案追加到預設的bootstrap路徑中。我們可以開啟我的電腦，在上面的目錄下檢視，看看這些jar包是不是存在於這個目錄。

Extention ClassLoader 擴充套件的類載入器，載入目錄%JRE_HOME%libext目錄下的jar包和class檔案。還可以載入-D java.ext.dirs選項指定的目錄。

Appclass Loader也稱為SystemAppClass 載入當前應用的classpath的所有類。

我們上面簡單介紹了3個ClassLoader。說明了它們載入的路徑。並且還提到了-Xbootclasspath和-D java.ext.dirs這兩個虛擬機器引數選項。

載入順序？

我們看到了系統的3個類載入器，但我們可能不知道具體哪個先行呢？

我可以先告訴你答案

Bootstrap CLassloder

Extention ClassLoader

AppClassLoader

public class Launcher {

private static Launcher launcher = new Launcher();

private static String bootClassPath =

System.getProperty("sun.boot.class.path");

public static Launcher getLauncher() {

return launcher;

}

private ClassLoader loader;

public Launcher() {

// Create the extension class loader

ClassLoader extcl;

try {

extcl = ExtClassLoader.getExtClassLoader();

} catch (IOException e) {

throw new InternalError(

"Could not create extension class loader", e);

}

// Now create the class loader to use to launch the application

try {

loader = AppClassLoader.getAppClassLoader(extcl);

} catch (IOException e) {

throw new InternalError(

"Could not create application class loader", e);

}

//設定AppClassLoader為執行緒上下文類載入器，這個文章後面部分講解

Thread.currentThread().setContextClassLoader(loader);

}

public ClassLoader getClassLoader() {

return loader;

}

static class ExtClassLoader extends URLClassLoader {}

static class AppClassLoader extends URLClassLoader {}

原始碼有精簡，我們可以得到相關的資訊。

Launcher初始化了ExtClassLoader和AppClassLoader。

Launcher中並沒有看見BootstrapClassLoader，但透過System.getProperty("sun.boot.class.path")得到了字串bootClassPath,這個應該就是BootstrapClassLoader載入的jar包路徑。

我們可以先程式碼測試一下sun.boot.class.path是什麼內容。

System.out.println(System.getProperty("sun.boot.class.path"));

得到的結果是：

C:Program FilesJavajre1.8.0_91libresources.jar;

C:Program FilesJavajre1.8.0_91librt.jar;

C:Program FilesJavajre1.8.0_91libsunrsasign.jar;

C:Program FilesJavajre1.8.0_91libjsse.jar;

C:Program FilesJavajre1.8.0_91libjce.jar;

C:Program FilesJavajre1.8.0_91libcharsets.jar;

C:Program FilesJavajre1.8.0_91libjfr.jar;

C:Program FilesJavajre1.8.0_91classes

可以看到，這些全是JRE目錄下的jar包或者是class檔案。

ExtClassLoader原始碼

如果你有足夠的好奇心，你應該會對它的原始碼感興趣

static class ExtClassLoader extends URLClassLoader {

static {

ClassLoader.registerAsParallelCapable();

}

public static ExtClassLoader getExtClassLoader() throws IOException

{

final File[] dirs = getExtDirs();

try {

// Prior implementations of this doPrivileged() block supplied

// aa synthesized ACC via a call to the private method

// ExtClassLoader.getContext().

return AccessController.doPrivileged(

new PrivilegedExceptionAction<ExtClassLoader>() {

public ExtClassLoader run() throws IOException {

int len = dirs.length;

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

MetaIndex.registerDirectory(dirs[i]);

}

return new ExtClassLoader(dirs);

}

});

} catch (java.security.PrivilegedActionException e) {

throw (IOException) e.getException();

}

private static File[] getExtDirs() {

String s = System.getProperty("java.ext.dirs");

File[] dirs;

if (s != null) {

StringTokenizer st =

new StringTokenizer(s, File.pathSeparator);

int count = st.countTokens();

dirs = new File[count];

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

dirs[i] = new File(st.nextToken());

}

} else {

dirs = new File[0];

}

return dirs;

}

......

}

我們先前的內容有說過，可以指定-D java.ext.dirs引數來新增和改變ExtClassLoader的載入路徑。這裡我們透過可以編寫測試程式碼。

System.out.println(System.getProperty("java.ext.dirs"));

結果如下：

C:Program FilesJavajre1.8.0_91libext;C:WindowsSunJavalibext

AppClassLoader原始碼

static class AppClassLoader extends URLClassLoader {

public static ClassLoader getAppClassLoader(final ClassLoader extcl)

throws IOException

{

final String s = System.getProperty("java.class.path");

final File[] path = (s == null) ? new File[0] : getClassPath(s);

return AccessController.doPrivileged(

new PrivilegedAction<AppClassLoader>() {

public AppClassLoader run() {

URL[] urls =

(s == null) ? new URL[0] : pathToURLs(path);

return new AppClassLoader(urls, extcl);

}

});

}

......

}

可以看到AppClassLoader載入的就是java.class.path下的路徑。我們同樣列印它的值。

System.out.println(System.getProperty("java.class.path"));

結果：

D:workspaceClassLoaderDemobin

這個路徑其實就是當前java工程目錄bin，裡面存放的是編譯生成的class檔案。

好了，自此我們已經知道了BootstrapClassLoader、ExtClassLoader、AppClassLoader實際是查閱相應的環境屬性sun.boot.class.path、java.ext.dirs和java.class.path來載入資原始檔的。

接下來我們探討它們的載入順序，我們先用Eclipse建立一個java工程。

一看你就懂，超詳細 java 中的 ClassLoader 詳解

然後建立一個Test.java檔案。

public class Test{}

然後，編寫一個ClassLoaderTest.java檔案。

public class ClassLoaderTest {

public static void main(String[] args) {

// TODO Auto-generated method stub

ClassLoader cl = Test.class.getClassLoader();

System.out.println("ClassLoader is:"+cl.toString());

}

我們獲取到了Test.class檔案的類載入器，然後列印出來。結果是：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93

也就是說明Test.class檔案是由AppClassLoader載入的。

這個Test類是我們自己編寫的，那麼int.class或者是String.class的載入是由誰完成的呢？

我們可以在程式碼中嘗試

public class ClassLoaderTest {

public static void main(String[] args) {

// TODO Auto-generated method stub

ClassLoader cl = Test.class.getClassLoader();

System.out.println("ClassLoader is:"+cl.toString());

cl = int.class.getClassLoader();

System.out.println("ClassLoader is:"+cl.toString());

}

執行一下，卻報錯了

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93

Exception in thread "main" java.lang.NullPointerException

at ClassLoaderTest.main(ClassLoaderTest.java:15)

提示的是空指標，意思是int.class這類基礎類沒有類載入器載入？

當然不是

int.class是由Bootstrap ClassLoader載入的。要想弄明白這些，我們首先得知道一個前提。

每個類載入器都有一個父載入器

每個類載入器都有一個父載入器，比如載入Test.class是由AppClassLoader完成，那麼AppClassLoader也有一個父載入器，怎麼樣獲取呢？很簡單，透過getParent方法。比如程式碼可以這樣編寫：

ClassLoader cl = Test.class.getClassLoader();

System.out.println("ClassLoader is:"+cl.toString());

System.out.println("ClassLoader's parent is:"+cl.getParent().toString());

執行結果如下：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93

ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742

這個說明，AppClassLoader的父載入器是ExtClassLoader。那麼ExtClassLoader的父載入器又是誰呢？

System.out.println("ClassLoader is:"+cl.toString());

System.out.println("ClassLoader's parent is:"+cl.getParent().toString());

System.out.println("ClassLoader's grand father is:"+cl.getParent().getParent().toString());

執行如果：

ClassLoader is:sun.misc.Launcher$AppClassLoader@73d16e93

Exception in thread "main" ClassLoader's parent is:sun.misc.Launcher$ExtClassLoader@15db9742

java.lang.NullPointerException

at ClassLoaderTest.main(ClassLoaderTest.java:13)

又是一個空指標異常，這表明ExtClassLoader也沒有父載入器。那麼，為什麼標題又是每一個載入器都有一個父載入器呢？這不矛盾嗎？為了解釋這一點，我們還需要看下面的一個基礎前提。

父載入器不是父類

我們先前已經貼上了ExtClassLoader和AppClassLoader的程式碼。

static class ExtClassLoader extends URLClassLoader {}

static class AppClassLoader extends URLClassLoader {}

可以看見ExtClassLoader和AppClassLoader同樣繼承自URLClassLoader，但上面一小節程式碼中，為什麼呼叫AppClassLoader的getParent()程式碼會得到ExtClassLoader的例項呢？先從URLClassLoader說起，這個類又是什麼？

先上一張類的繼承關係圖

一看你就懂，超詳細 java 中的 ClassLoader 詳解

URLClassLoader的原始碼中並沒有找到getParent()方法。這個方法在ClassLoader.java中。

public abstract class ClassLoader {

// The parent class loader for delegation

// Note: VM hardcoded the offset of this field, thus all new fields

// must be added after it.

private final ClassLoader parent;

// The class loader for the system

// @GuardedBy("ClassLoader.class")

private static ClassLoader scl;

private ClassLoader(Void unused, ClassLoader parent) {

this.parent = parent;

...

}

protected ClassLoader(ClassLoader parent) {

this(checkCreateClassLoader(), parent);

}

protected ClassLoader() {

this(checkCreateClassLoader(), getSystemClassLoader());

}

public final ClassLoader getParent() {

if (parent == null)

return null;

return parent;

}

public static ClassLoader getSystemClassLoader() {

initSystemClassLoader();

if (scl == null) {

return null;

}

return scl;

}

private static synchronized void initSystemClassLoader() {

if (!sclSet) {

if (scl != null)

throw new IllegalStateException("recursive invocation");

sun.misc.Launcher l = sun.misc.Launcher.getLauncher();

if (l != null) {

Throwable oops = null;

//透過Launcher獲取ClassLoader

scl = l.getClassLoader();

try {

scl = AccessController.doPrivileged(

new SystemClassLoaderAction(scl));

} catch (PrivilegedActionException pae) {

oops = pae.getCause();

if (oops instanceof InvocationTargetException) {

oops = oops.getCause();

}

if (oops != null) {

if (oops instanceof Error) {

throw (Error) oops;

} else {

// wrap the exception

throw new Error(oops);

}

sclSet = true;

}

我們可以看到getParent()實際上返回的就是一個ClassLoader物件parent，parent的賦值是在ClassLoader物件的構造方法中，它有兩個情況：

由外部類建立ClassLoader時直接指定一個ClassLoader為parent。

由getSystemClassLoader()方法生成，也就是在sun.misc.Laucher透過getClassLoader()獲取，也就是AppClassLoader。直白的說，一個ClassLoader建立時如果沒有指定parent，那麼它的parent預設就是AppClassLoader。

我們主要研究的是ExtClassLoader與AppClassLoader的parent的來源，正好它們與Launcher類有關，我們上面已經貼上過Launcher的部分程式碼。

public class Launcher {

private static URLStreamHandlerFactory factory = new Factory();

private static Launcher launcher = new Launcher();

private static String bootClassPath =

System.getProperty("sun.boot.class.path");

public static Launcher getLauncher() {

return launcher;

}

private ClassLoader loader;

public Launcher() {

// Create the extension class loader

ClassLoader extcl;

try {

extcl = ExtClassLoader.getExtClassLoader();

} catch (IOException e) {

throw new InternalError(

"Could not create extension class loader", e);

}

// Now create the class loader to use to launch the application

try {

//將ExtClassLoader物件例項傳遞進去

loader = AppClassLoader.getAppClassLoader(extcl);

} catch (IOException e) {

throw new InternalError(

"Could not create application class loader", e);

}

public ClassLoader getClassLoader() {

return loader;

}

static class ExtClassLoader extends URLClassLoader {

public static ExtClassLoader getExtClassLoader() throws IOException

{

final File[] dirs = getExtDirs();

try {

// Prior implementations of this doPrivileged() block supplied

// aa synthesized ACC via a call to the private method

// ExtClassLoader.getContext().

return AccessController.doPrivileged(

new PrivilegedExceptionAction<ExtClassLoader>() {

public ExtClassLoader run() throws IOException {

//ExtClassLoader在這裡建立

return new ExtClassLoader(dirs);

}

});

} catch (java.security.PrivilegedActionException e) {

throw (IOException) e.getException();

}

public ExtClassLoader(File[] dirs) throws IOException {

super(getExtURLs(dirs), null, factory);

}

我們需要注意的是

ClassLoader extcl;

extcl = ExtClassLoader.getExtClassLoader();

loader = AppClassLoader.getAppClassLoader(extcl);

程式碼已經說明了問題AppClassLoader的parent是一個ExtClassLoader例項。

ExtClassLoader並沒有直接找到對parent的賦值。它呼叫了它的父類也就是URLClassLoder的構造方法並傳遞了3個引數。

public ExtClassLoader(File[] dirs) throws IOException {

super(getExtURLs(dirs), null, factory);

}

對應的程式碼

public URLClassLoader(URL[] urls, ClassLoader parent,

URLStreamHandlerFactory factory) {

super(parent);

}

答案已經很明瞭了，ExtClassLoader的parent為null。

上面張貼這麼多程式碼也是為了說明AppClassLoader的parent是ExtClassLoader，ExtClassLoader的parent是null。這符合我們之前編寫的測試程式碼。

不過，細心的同學發現，還是有疑問的我們只看到ExtClassLoader和AppClassLoader的建立，那麼BootstrapClassLoader呢？

還有，ExtClassLoader的父載入器為null,但是Bootstrap CLassLoader卻可以當成它的父載入器這又是為何呢？

我們繼續往下進行。

Bootstrap ClassLoader是由C++編寫的。

Bootstrap ClassLoader是由C/C++編寫的，它本身是虛擬機器的一部分，所以它並不是一個JAVA類，也就是無法在java程式碼中獲取它的引用，JVM啟動時透過Bootstrap類載入器載入rt.jar等核心jar包中的class檔案，之前的int.class,String.class都是由它載入。然後呢，我們前面已經分析了，JVM初始化sun.misc.Launcher並建立Extension ClassLoader和AppClassLoader例項。並將ExtClassLoader設定為AppClassLoader的父載入器。Bootstrap沒有父載入器，但是它卻可以作用一個ClassLoader的父載入器。比如ExtClassLoader。這也可以解釋之前透過ExtClassLoader的getParent方法獲取為Null的現象。具體是什麼原因，很快就知道答案了。

雙親委託

雙親委託。

我們終於來到了這一步了。

一個類載入器查詢class和resource時，是透過“委託模式”進行的，它首先判斷這個class是不是已經載入成功，如果沒有的話它並不是自己進行查詢，而是先透過父載入器，然後遞迴下去，直到Bootstrap ClassLoader，如果Bootstrap classloader找到了，直接返回，如果沒有找到，則一級一級返回，最後到達自身去查詢這些物件。這種機制就叫做雙親委託。

整個流程可以如下圖所示：

一看你就懂，超詳細 java 中的 ClassLoader 詳解

這張圖是用時序圖畫出來的，不過畫出來的結果我卻自己都覺得不理想。

大家可以看到2根箭頭，藍色的代表類載入器向上委託的方向，如果當前的類載入器沒有查詢到這個class物件已經載入就請求父載入器（不一定是父類）進行操作，然後以此類推。直到Bootstrap ClassLoader。如果Bootstrap ClassLoader也沒有載入過此class例項，那麼它就會從它指定的路徑中去查詢，如果查詢成功則返回，如果沒有查詢成功則交給子類載入器，也就是ExtClassLoader,這樣類似操作直到終點，也就是我上圖中的紅色箭頭示例。

用序列描述一下：

一個AppClassLoader查詢資源時，先看看快取是否有，快取有從快取中獲取，否則委託給父載入器。

遞迴，重複第1部的操作。

如果ExtClassLoader也沒有載入過，則由Bootstrap ClassLoader出面，它首先查詢快取，如果沒有找到的話，就去找自己的規定的路徑下，也就是sun.mic.boot.class下面的路徑。找到就返回，沒有找到，讓子載入器自己去找。

Bootstrap ClassLoader如果沒有查詢成功，則ExtClassLoader自己在java.ext.dirs路徑中去查詢，查詢成功就返回，查詢不成功，再向下讓子載入器找。

ExtClassLoader查詢不成功，AppClassLoader就自己查詢，在java.class.path路徑下查詢。找到就返回。如果沒有找到就讓子類找，如果沒有子類會怎麼樣？丟擲各種異常。

上面的序列，詳細說明了雙親委託的載入流程。我們可以發現委託是從下向上，然後具體查詢過程卻是自上至下。

我說過上面用時序圖畫的讓自己不滿意，現在用框圖，最原始的方法再畫一次。

一看你就懂，超詳細 java 中的 ClassLoader 詳解

上面已經詳細介紹了載入過程，但具體為什麼是這樣載入，我們還需要了解幾個個重要的方法loadClass()、findLoadedClass()、findClass()、defineClass()。

重要方法

loadClass()

JDK文件中是這樣寫的，透過指定的全限定類名載入class，它透過同名的loadClass(String,boolean)方法。

protected Class<?> loadClass(String name,

boolean resolve)

throws ClassNotFoundException

上面是方法原型，一般實現這個方法的步驟是

執行findLoadedClass(String)去檢測這個class是不是已經載入過了。

執行父載入器的loadClass方法。如果父載入器為null，則jvm內建的載入器去替代，也就是Bootstrap ClassLoader。這也解釋了ExtClassLoader的parent為null,但仍然說Bootstrap ClassLoader是它的父載入器。

如果向上委託父載入器沒有載入成功，則透過findClass(String)查詢。

如果class在上面的步驟中找到了，引數resolve又是true的話，那麼loadClass()又會呼叫resolveClass(Class)這個方法來生成最終的Class物件。我們可以從原始碼看出這個步驟。

protected Class<?> loadClass(String name, boolean resolve)

throws ClassNotFoundException

{

synchronized (getClassLoadingLock(name)) {

// 首先，檢測是否已經載入

Class<?> c = findLoadedClass(name);

if (c == null) {

long t0 = System.nanoTime();

try {

if (parent != null) {

//父載入器不為空則呼叫父載入器的loadClass

c = parent.loadClass(name, false);

} else {

//父載入器為空則呼叫Bootstrap Classloader

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

// ClassNotFoundException thrown if class not found

// from the non-null parent class loader

}

if (c == null) {

// If still not found, then invoke findClass in order

// to find the class.

long t1 = System.nanoTime();

//父載入器沒有找到，則呼叫findclass

c = findClass(name);

// this is the defining class loader; record the stats

sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);

sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

sun.misc.PerfCounter.getFindClasses().increment();

}

if (resolve) {

//呼叫resolveClass()

resolveClass(c);

}

return c;

}

程式碼解釋了雙親委託。

另外，要注意的是如果要編寫一個classLoader的子類，也就是自定義一個classloader，建議覆蓋findClass()方法，而不要直接改寫loadClass()方法。

另外

if (parent != null) {

//父載入器不為空則呼叫父載入器的loadClass

c = parent.loadClass(name, false);

} else {

//父載入器為空則呼叫Bootstrap Classloader

c = findBootstrapClassOrNull(name);

> }

前面說過ExtClassLoader的parent為null，所以它向上委託時，系統會為它指定Bootstrap ClassLoader。

自定義ClassLoader

不知道大家有沒有發現，不管是Bootstrap ClassLoader還是ExtClassLoader等，這些類載入器都只是載入指定的目錄下的jar包或者資源。如果在某種情況下，我們需要動態載入一些東西呢？比如從D盤某個資料夾載入一個class檔案，或者從網路上下載class主內容然後再進行載入，這樣可以嗎？

如果要這樣做的話，需要我們自定義一個classloader。

自定義步驟

編寫一個類繼承自ClassLoader抽象類。

複寫它的findClass()方法。

在findClass()方法中呼叫defineClass()。

defineClass()

這個方法在編寫自定義classloader的時候非常重要，它能將class二進位制內容轉換成Class物件，如果不符合要求的會丟擲各種異常。

注意點：

一個ClassLoader建立時如果沒有指定parent，那麼它的parent預設就是AppClassLoader。

上面說的是，如果自定義一個ClassLoader，預設的parent父載入器是AppClassLoader，因為這樣就能夠保證它能訪問系統內建載入器載入成功的class檔案。

自定義ClassLoader示例之DiskClassLoader。

假設我們需要一個自定義的classloader,預設載入路徑為D:lib下的jar包和資源。

我們寫編寫一個測試用的類檔案，Test.java

Test.java

package com.frank.test;

public class Test {

public void say(){

System.out.println("Say Hello");

}

然後將它編譯過年class檔案Test.class放到D:lib這個路徑下。

DiskClassLoader

我們編寫DiskClassLoader的程式碼。

import java.io.ByteArrayOutputStream;

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.IOException;

public class DiskClassLoader extends ClassLoader {

private String mLibPath;

public DiskClassLoader(String path) {

// TODO Auto-generated constructor stub

mLibPath = path;

}

@Override

protected Class<?> findClass(String name) throws ClassNotFoundException {

// TODO Auto-generated method stub

String fileName = getFileName(name);

File file = new File(mLibPath,fileName);

try {

FileInputStream is = new FileInputStream(file);

ByteArrayOutputStream bos = new ByteArrayOutputStream();

int len = 0;

try {

while ((len = is.read()) != -1) {

bos.write(len);

}

} catch (IOException e) {

e.printStackTrace();

}

byte[] data = bos.toByteArray();

is.close();

bos.close();

return defineClass(name,data,0,data.length);

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

return super.findClass(name);

}

//獲取要載入的class檔名

private String getFileName(String name) {

// TODO Auto-generated method stub

int index = name.lastIndexOf('.');

if(index == -1){

return name+".class";

}else{

return name.substring(index)+".class";

}

我們在findClass()方法中定義了查詢class的方法，然後資料透過defineClass()生成了Class物件。

測試

現在我們要編寫測試程式碼。我們知道如果呼叫一個Test物件的say方法，它會輸出”Say Hello”這條字串。但現在是我們把Test.class放置在應用工程所有的目錄之外，我們需要載入它，然後執行它的方法。具體效果如何呢？我們編寫的DiskClassLoader能不能順利完成任務呢？我們拭目以待。

import java.lang.reflect.InvocationTargetException;

import java.lang.reflect.Method;

public class ClassLoaderTest {

public static void main(String[] args) {

// TODO Auto-generated method stub

//建立自定義classloader物件。

DiskClassLoader diskLoader = new DiskClassLoader("D:\lib");

try {

//載入class檔案

Class c = diskLoader.loadClass("com.frank.test.Test");

if(c != null){

try {

Object obj = c.newInstance();

Method method = c.getDeclaredMethod("say",null);

//透過反射呼叫Test類的say方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

我們點選執行按鈕，結果顯示。

一看你就懂，超詳細 java 中的 ClassLoader 詳解

可以看到，Test類的say方法正確執行，也就是我們寫的DiskClassLoader編寫成功。

> 回首關鍵字路徑

從開篇的環境變數

到3個主要的JDK自帶的類載入器

到自定義的ClassLoader

它們的關聯部分就是路徑，也就是要載入的class或者是資源的路徑。

BootStrap ClassLoader、ExtClassLoader、AppClassLoader都是載入指定路徑下的jar包。如果我們要突破這種限制，實現自己某些特殊的需求，我們就得自定義ClassLoader，自已指定載入的路徑，可以是磁碟、記憶體、網路或者其它。

所以，你說路徑能不能成為它們的關鍵字？

當然上面的只是我個人的看法，可能不正確，但現階段，這樣有利於自己的學習理解

講了這麼大的篇幅，自定義ClassLoader才姍姍來遲。很多同學可能覺得前面有些囉嗦，但我按照自己的思路，我覺得還是有必要的。因為我是圍繞一個關鍵字進行講解的。

關鍵字是什麼？

關鍵字路徑

從開篇的環境變數

到3個主要的JDK自帶的類載入器

到自定義的ClassLoader

它們的關聯部分就是路徑，也就是要載入的class或者是資源的路徑。

BootStrap ClassLoader、ExtClassLoader、AppClassLoader都是載入指定路徑下的jar包。如果我們要突破這種限制，實現自己某些特殊的需求，我們就得自定義ClassLoader，自已指定載入的路徑，可以是磁碟、記憶體、網路或者其它。

所以，你說路徑能不能成為它們的關鍵字？

當然上面的只是我個人的看法，可能不正確，但現階段，這樣有利於自己的學習理解

自定義ClassLoader還能做什麼？

突破了JDK系統內建載入路徑的限制之後，我們就可以編寫自定義ClassLoader，然後剩下的就叫給開發者你自己了。你可以按照自己的意願進行業務的定製，將ClassLoader玩出花樣來。

玩出花之Class解密類載入器

常見的用法是將Class檔案按照某種加密手段進行加密，然後按照規則編寫自定義的ClassLoader進行解密，這樣我們就可以在程式中載入特定了類，並且這個類只能被我們自定義的載入器進行載入，提高了程式的安全性。

下面，我們編寫程式碼。

1.定義加密解密協議

加密和解密的協議有很多種，具體怎麼定看業務需要。在這裡，為了便於演示，我簡單地將加密解密定義為異或運算。當一個檔案進行異或運算後，產生了加密檔案，再進行一次異或後，就進行了解密。

2.編寫加密工具類

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

public class FileUtils {

public static void test(String path){

File file = new File(path);

try {

FileInputStream fis = new FileInputStream(file);

FileOutputStream fos = new FileOutputStream(path+"en");

int b = 0;

int b1 = 0;

try {

while((b = fis.read()) != -1){

//每一個byte異或一個數字2

fos.write(b ^ 2);

}

fos.close();

fis.close();

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (FileNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

我們再寫測試程式碼

FileUtils.test("D:libTest.class");

一看你就懂，超詳細 java 中的 ClassLoader 詳解

然後可以看見路徑D:libTest.class下Test.class生成了Test.classen檔案。

編寫自定義classloader，DeClassLoader

import java.io.ByteArrayOutputStream;

import java.io.File;

import java.io.FileInputStream;

import java.io.IOException;

public class DeClassLoader extends ClassLoader {

private String mLibPath;

public DeClassLoader(String path) {

// TODO Auto-generated constructor stub

mLibPath = path;

}

@Override

protected Class<?> findClass(String name) throws ClassNotFoundException {

// TODO Auto-generated method stub

String fileName = getFileName(name);

File file = new File(mLibPath,fileName);

try {

FileInputStream is = new FileInputStream(file);

ByteArrayOutputStream bos = new ByteArrayOutputStream();

int len = 0;

byte b = 0;

try {

while ((len = is.read()) != -1) {

//將資料異或一個數字2進行解密

b = (byte) (len ^ 2);

bos.write(b);

}

} catch (IOException e) {

e.printStackTrace();

}

byte[] data = bos.toByteArray();

is.close();

bos.close();

return defineClass(name,data,0,data.length);

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

return super.findClass(name);

}

//獲取要載入的class檔名

private String getFileName(String name) {

// TODO Auto-generated method stub

int index = name.lastIndexOf('.');

if(index == -1){

return name+".classen";

}else{

return name.substring(index+1)+".classen";

}

測試

我們可以在ClassLoaderTest.java中的main方法中如下編碼：

DeClassLoader diskLoader = new DeClassLoader("D:lib");

try {

//載入class檔案

Class c = diskLoader.loadClass("com.frank.test.Test");

if(c != null){

try {

Object obj = c.newInstance();

Method method = c.getDeclaredMethod("say",null);

//透過反射呼叫Test類的say方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

檢視執行結果是：

一看你就懂，超詳細 java 中的 ClassLoader 詳解

可以看到了，同樣成功了。現在，我們有兩個自定義的ClassLoader:DiskClassLoader和DeClassLoader，我們可以嘗試一下，看看DiskClassLoader能不能載入Test.classen檔案也就是Test.class加密後的檔案。

我們首先移除D:libTest.class檔案，只剩下一下Test.classen檔案，然後進行程式碼的測試。

DeClassLoader diskLoader1 = new DeClassLoader("D:lib");

try {

//載入class檔案

Class c = diskLoader1.loadClass("com.frank.test.Test");

if(c != null){

try {

Object obj = c.newInstance();

Method method = c.getDeclaredMethod("say",null);

//透過反射呼叫Test類的say方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

DiskClassLoader diskLoader = new DiskClassLoader("D:\lib");

try {

//載入class檔案

Class c = diskLoader.loadClass("com.frank.test.Test");

if(c != null){

try {

Object obj = c.newInstance();

Method method = c.getDeclaredMethod("say",null);

//透過反射呼叫Test類的say方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

一看你就懂，超詳細 java 中的 ClassLoader 詳解

我們可以看到。DeClassLoader執行正常，而DiskClassLoader卻找不到Test.class的類,並且它也無法載入Test.classen檔案。

Context ClassLoader 執行緒上下文類載入器

前面講到過Bootstrap ClassLoader、ExtClassLoader、AppClassLoader，現在又出來這麼一個類載入器，這是為什麼？

前面三個之所以放在前面講，是因為它們是真實存在的類，而且遵從”雙親委託“的機制。而ContextClassLoader其實只是一個概念。

檢視Thread.java原始碼可以發現

public class Thread implements Runnable {

/ The context ClassLoader for this thread /

private ClassLoader contextClassLoader;

public void setContextClassLoader(ClassLoader cl) {

SecurityManager sm = System.getSecurityManager();

if (sm != null) {

sm.checkPermission(new RuntimePermission("setContextClassLoader"));

}

contextClassLoader = cl;

}

public ClassLoader getContextClassLoader() {

if (contextClassLoader == null)

return null;

SecurityManager sm = System.getSecurityManager();

if (sm != null) {

ClassLoader.checkClassLoaderPermission(contextClassLoader,

Reflection.getCallerClass());

}

return contextClassLoader;

}

contextClassLoader只是一個成員變數，透過setContextClassLoader()方法設定，透過getContextClassLoader()設定。

每個Thread都有一個相關聯的ClassLoader，預設是AppClassLoader。並且子執行緒預設使用父執行緒的ClassLoader除非子執行緒特別設定。

我們同樣可以編寫程式碼來加深理解。

現在有2個SpeakTest.class檔案，一個原始碼是

package com.frank.test;

public class SpeakTest implements ISpeak {

@Override

public void speak() {

// TODO Auto-generated method stub

System.out.println("Test");

}

> }

它生成的SpeakTest.class檔案放置在D:libtest目錄下。

另外ISpeak.java程式碼

package com.frank.test;

public interface ISpeak {

public void speak();

}

然後，我們在這裡還實現了一個SpeakTest.java

package com.frank.test;

public class SpeakTest implements ISpeak {

@Override

public void speak() {

// TODO Auto-generated method stub

System.out.println("I' frank");

}

>}

它生成的SpeakTest.class檔案放置在D:lib目錄下。

然後我們還要編寫另外一個ClassLoader，DiskClassLoader1.java這個ClassLoader的程式碼和DiskClassLoader.java程式碼一致，我們要在DiskClassLoader1中載入位置於D:libtest中的SpeakTest.class檔案。

測試程式碼：

DiskClassLoader1 diskLoader1 = new DiskClassLoader1("D:libtest");

Class cls1 = null;

try {

//載入class檔案

cls1 = diskLoader1.loadClass("com.frank.test.SpeakTest");

System.out.println(cls1.getClassLoader().toString());

if(cls1 != null){

try {

Object obj = cls1.newInstance();

//SpeakTest1 speak = (SpeakTest1) obj;

//speak.speak();

Method method = cls1.getDeclaredMethod("speak",null);

//透過反射呼叫Test類的speak方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

DiskClassLoader diskLoader = new DiskClassLoader("D:lib");

System.out.println("Thread "+Thread.currentThread().getName()+" classloader: "+Thread.currentThread().getContextClassLoader().toString());

new Thread(new Runnable() {

@Override

public void run() {

System.out.println("Thread "+Thread.currentThread().getName()+" classloader: "+Thread.currentThread().getContextClassLoader().toString());

// TODO Auto-generated method stub

try {

//載入class檔案

// Thread.currentThread().setContextClassLoader(diskLoader);

//Class c = diskLoader.loadClass("com.frank.test.SpeakTest");

ClassLoader cl = Thread.currentThread().getContextClassLoader();

Class c = cl.loadClass("com.frank.test.SpeakTest");

// Class c = Class.forName("com.frank.test.SpeakTest");

System.out.println(c.getClassLoader().toString());

if(c != null){

try {

Object obj = c.newInstance();

//SpeakTest1 speak = (SpeakTest1) obj;

//speak.speak();

Method method = c.getDeclaredMethod("speak",null);

//透過反射呼叫Test類的say方法

method.invoke(obj, null);

} catch (InstantiationException | IllegalAccessException

| NoSuchMethodException

| SecurityException |

IllegalArgumentException |

InvocationTargetException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

} catch (ClassNotFoundException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}).start();

結果如下：

一看你就懂，超詳細 java 中的 ClassLoader 詳解

我們可以得到如下的資訊：

DiskClassLoader1載入成功了SpeakTest.class檔案並執行成功。

子執行緒的ContextClassLoader是AppClassLoader。

AppClassLoader載入不了父執行緒當中已經載入的SpeakTest.class內容。

我們修改一下程式碼，在子執行緒開頭處加上這麼一句內容。

Thread.currentThread().setContextClassLoader(diskLoader1);

結果如下：

一看你就懂，超詳細 java 中的 ClassLoader 詳解

可以看到子執行緒的ContextClassLoader變成了DiskClassLoader。

繼續改動程式碼：

Thread.currentThread().setContextClassLoader(diskLoader);

結果：

一看你就懂，超詳細 java 中的 ClassLoader 詳解

可以看到DiskClassLoader1和DiskClassLoader分別載入了自己路徑下的SpeakTest.class檔案，並且它們的類名是一樣的com.frank.test.SpeakTest，但是執行結果不一樣，因為它們的實際內容不一樣。

Context ClassLoader的運用時機

其實這個我也不是很清楚，我的主業是Android，研究ClassLoader也是為了更好的研究Android。網上的答案說是適應那些Web服務框架軟體如Tomcat等。主要為了載入不同的APP，因為載入器不一樣，同一份class檔案載入後生成的類是不相等的。如果有同學想多瞭解更多的細節，請自行查閱相關資料。

總結

ClassLoader用來載入class檔案的。

系統內建的ClassLoader透過雙親委託來載入指定路徑下的class和資源。

可以自定義ClassLoader一般覆蓋findClass()方法。

ContextClassLoader與執行緒相關，可以獲取和設定，可以繞過雙親委託的機制。

一看你就懂，超詳細 java 中的 ClassLoader 詳解

相關文章