作者簡介 原創微信公眾號郭霖 WeChat ID： guolin_blog
本篇是fank909的第四篇投稿，詳細地介紹了Java中的ClassLoader。由于篇幅較長，我這里只推出了基礎部分，如果讀完感興趣，大家可以點擊文末閱讀原文查看進階部分。
frank909的博客地址：
http://blog.csdn.net/briblue
前言
ClassLoader 翻譯過來就是 類加載器，普通的Java開發者其實用到的不多，但對于某些框架開發者來說卻非常常見。理解 ClassLoader 的加載機制，也有利于我們編寫出更高效的代碼。
ClassLoader 的具體作用就是將 class文件 加載到 jvm虛擬機 中去，程序就可以正確運行了。但是，jvm 啟動的時候，并不會一次性加載所有的class文件，而是根據需要去動態加載。想想也是的，一次性加載那么多jar包那么多class，那內存不崩潰。本文的目的也是學習 ClassLoader 這種加載機制。
備注：本文篇幅比較長，但內容簡單，大家不要恐慌，安靜地耐心翻閱就是
Class文件的認識
我們都知道在Java中程序是運行在虛擬機中，我們平常用文本編輯器或者是IDE編寫的程序都是.java格式的文件，這是最基礎的源碼，但這類文件是不能直接運行的。如我們編寫一個簡單的程序 HelloWorld.java
如圖：
然后，我們需要在命令行中進行java文件的編譯:
javacHelloWorld.java
可以看到目錄下生成了.class文件。我們再從命令行中執行命令：
javaHelloWorld
上面是基本代碼示例，是所有入門JAVA語言時都學過的東西，這里重新拿出來是想讓大家將焦點回到 class文件 上，class文件 是字節碼格式文件，java虛擬機并不能直接識別我們平常編寫的 .java源文件，所以需要javac這個命令轉換成 .class文件。另外，如果用 C 或者?Python?編寫的程序正確轉換成 .class文件后，java虛擬機也是可以識別運行的。更多信息大家可以參考這篇：
http://blog.csdn.net/zhangjg_blog/article/details/21486985
了解了 .class文件后，我們再來思考下，我們平常在 Eclipse 中編寫的 java程序 是如何運行的，也就是我們自己編寫的各種類是如何被加載到 jvm(java虛擬機) 中去的。
你還記得Java環境變量嗎
初學java的時候，最害怕的就是下載 JDK 后要配置環境變量了，關鍵是當時不理解，所以戰戰兢兢地照著書籍上或者是網絡上的介紹進行操作。然后下次再弄的時候，又忘記了而且是必忘。當時，心里的想法很氣憤的，想著是–這東西一點也不人性化，為什么非要自己配置環境變量呢？太不照顧菜鳥和新手了，很多菜鳥就是因為卡在環境變量的配置上，遭受了太多的挫敗感。
因為我是在Windows下編程的，所以只講Window平臺上的環境變量，主要有3個：JAVA_HOME、PATH、CLASSPATH。
JAVA_HOME
指的是你JDK安裝的位置，一般默認安裝在C盤，如：
C:\ProgramFiles\Java\jdk1.8.0_91
PATH
將程序路徑包含在 PATH 當中后，在命令行窗口就可以直接鍵入它的名字了，而不再需要鍵入它的全路徑,比如上面代碼中我用的到javac和java兩個命令。一般的：
PATH=%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;%PATH%;
也就是在原來的PATH路徑上添加JDK目錄下的bin目錄和jre目錄的bin.
CLASSPATH
CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.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%\lib\ext 目錄下的jar包和class文件。還可以加載?-D java.ext.dirs?選項指定的目錄。
Appclass Loader也稱為 SystemAppClass?加載當前應用的classpath的所有類。
我們上面簡單介紹了 3個ClassLoader。說明了它們加載的路徑。并且還提到了-Xbootclasspath和-D java.ext.dirs這兩個虛擬機參數選項。
加載順序
我們看到了系統的3個類加載器，但我們可能不知道具體哪個先行呢？我可以先告訴你答案
1. Bootstrap CLassloder
2. Extention ClassLoader
3. AppClassLoader
為了更好的理解，我們可以查看源碼，sun.misc.Launcher：
http://www.grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/misc/Launcher.java
它是一個 java虛擬機 的入口應用：
源碼有精簡，我們可以得到相關的信息。
1.Launcher 初始化了 ExtClassLoader 和 AppClassLoader。
2.Launcher 中并沒有看見 BootstrapClassLoader，但通過?System.getProperty("sun.boot.class.path")?得到了字符串?bootClassPath,這個應該就是 BootstrapClassLoader 加載的jar包路徑。
我們可以先代碼測試一下sun.boot.class.path是什么內容。
System.out.println(System.getProperty("sun.boot.class.path"));
得到的結果是：
可以看到，這些全是JRE目錄下的jar包或者是class文件。
ExtClassLoader源碼
如果你有足夠的好奇心，你應該會對它的源碼感興趣：
我們先前的內容有說過，可以指定-D java.ext.dirs參數來添加和改變 ExtClassLoader 的加載路徑。這里我們通過可以編寫測試代碼：
System.out.println(System.getProperty("java.ext.dirs"));
結果如下：
C:\ProgramFiles\Java\jre1.8.0_91\lib\ext;C:\Windows\Sun\Java\lib\ext
AppClassLoader源碼
可以看到?AppClassLoader 加載的就是java.class.path下的路徑。我們同樣打印它的值：
System.out.println(System.getProperty("java.class.path"));
結果：
D:\workspace\ClassLoaderDemo\bin
這個路徑其實就是當前 java工程目錄bin，里面存放的是編譯生成的class文件。
好了，自此我們已經知道了 BootstrapClassLoader、ExtClassLoader、AppClassLoader 實際是查閱相應的環境屬性?sun.boot.class.path、java.ext.dirs?和?java.class.path?來加載資源文件的。
接下來我們探討它們的加載順序，我們先用 Eclipse 建立一個java工程：
然后創建一個Test.java文件：
publicclassTest{}
然后，編寫一個?ClassLoaderTest.java 文件：
我們獲取到了 Test.class 文件的類加載器，然后打印出來。結果是：
ClassLoaderis:sun.misc.Launcher$AppClassLoader@73d16e93
也就是說明 Test.class文件 是由 AppClassLoader 加載的。
這個 Test類 是我們自己編寫的，那么 int.class 或者是 String.class 的加載是由誰完成的呢？我們可以在代碼中嘗試：
運行一下，卻報錯了：
提示的是空指針，意思是 int.class 這類基礎類沒有類加載器加載？
當然不是！int.class 是由 Bootstrap ClassLoader 加載的。要想弄明白這些，我們首先得知道一個前提。
每個類加載器都有一個父加載器
每個類加載器都有一個父加載器，比如加載 Test.class 是由 AppClassLoader 完成，那么 AppClassLoader 也有一個父加載器，怎么樣獲取呢？很簡單，通過 getParent 方法。比如代碼可以這樣編寫：
運行結果如下：
這個說明，AppClassLoader 的父加載器是 ExtClassLoader。那么 ExtClassLoader 的父加載器又是誰呢？
運行結果：
又是一個空指針異常，這表明 ExtClassLoader 也沒有父加載器。那么，為什么標題又是每一個加載器都有一個父加載器呢？這不矛盾嗎？為了解釋這一點，我們還需要看下面的一個基礎前提。
父加載器不是父類
我們先前已經粘貼了 ExtClassLoader 和 AppClassLoader 的代碼：
可以看見 ExtClassLoader 和 AppClassLoader 同樣繼承自 URLClassLoader，但上面一小節代碼中，為什么調用 AppClassLoader的getParent()?代碼會得到 ExtClassLoader 的實例呢？先從 URLClassLoader 說起，這個類又是什么？先上一張類的繼承關系圖：
URLClassLoader 的源碼中并沒有找到?getParent()?方法。這個方法在 ClassLoader.java 中：
我們可以看到?getParent()?實際上返回的就是一個 ClassLoader 對象 parent，parent 的賦值是在 ClassLoader 對象的構造方法中，它有兩個情況：
1.由外部類創建 ClassLoader 時直接指定一個 ClassLoader 為 parent。
2.由?getSystemClassLoader()?方法生成，也就是在 sun.misc.Laucher 通過?getClassLoader()?獲取，也就是 AppClassLoader。直白的說，一個 ClassLoader 創建時如果沒有指定 parent，那么它的 parent 默認就是 AppClassLoader。
我們主要研究的是 ExtClassLoader 與 AppClassLoader 的 parent 的來源，正好它們與 Launcher類 有關，我們上面已經粘貼過 Launcher 的部分代碼。
我們需要注意的是:
代碼已經說明了問題 AppClassLoader 的 paren t是一個 ExtClassLoader 實例。
ExtClassLoader 并沒有直接找到對 parent 的賦值。它調用了它的父類也就是 URLClassLoder 的構造方法并傳遞了3個參數。
對應的代碼:
答案已經很明了了，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 找到了，直接返回，如果沒有找到，則一級一級返回，最后到達自身去查找這些對象。這種機制就叫做雙親委托。
整個流程可以如下圖所示：
這張圖是用時序圖畫出來的，不過畫出來的結果我卻自己都覺得不理想。
大家可以看到2根箭頭，藍色的代表類加載器向上委托的方向，如果當前的類加載器沒有查詢到這個 class對象 已經加載就請求父加載器（不一定是父類）進行操作，然后以此類推。直到 Bootstrap ClassLoader。如果 Bootstrap ClassLoader 也沒有加載過此class實例，那么它就會從它指定的路徑中去查找，如果查找成功則返回，如果沒有查找成功則交給子類加載器，也就是ExtClassLoader,這樣類似操作直到終點，也就是我上圖中的紅色箭頭示例。用序列描述一下：
1.一個 AppClassLoader 查找資源時，先看看緩存是否有，緩存有從緩存中獲取，否則委托給父加載器。
2.遞歸，重復第1部的操作。
3.如果 ExtClassLoader 也沒有加載過，則由 Bootstrap ClassLoader 出面，它首先查找緩存，如果沒有找到的話，就去找自己的規定的路徑下，也就是?sun.mic.boot.class?下面的路徑。找到就返回，沒有找到，讓子加載器自己去找。
4.Bootstrap ClassLoader 如果沒有查找成功，則 ExtClassLoader 自己在?java.ext.dirs?路徑中去查找，查找成功就返回，查找不成功，再向下讓子加載器找。
5.ExtClassLoader 查找不成功，AppClassLoader 就自己查找，在?java.class.path?路徑下查找。找到就返回。如果沒有找到就讓子類找，如果沒有子類會怎么樣？拋出各種異常。
上面的序列，詳細說明了雙親委托的加載流程。我們可以發現委托是從下向上，然后具體查找過程卻是自上至下。
我說過上面用時序圖畫的讓自己不滿意，現在用框圖，最原始的方法再畫一次：
上面已經詳細介紹了加載過程，但具體為什么是這樣加載，我們還需要了解幾個個重要的方法 loadClass()、findLoadedClass()、findClass()、defineClass()。
重要方法
loadClass()
JDK文檔中是這樣寫的，通過指定的全限定類名加載 class，它通過同名的 loadClass(String,boolean) 方法：
protectedClassloadClass(Stringname,booleanresolve) throwsClassNotFoundException
上面是方法原型，一般實現這個方法的步驟是
1.執行?findLoadedClass(String)?去檢測這個class是不是已經加載過了。
2.執行父加載器的?loadClass方法。如果父加載器為null，則jvm內置的加載器去替代，也就是 Bootstrap ClassLoader。這也解釋了 ExtClassLoader 的 parent 為 null,但仍然說 Bootstrap ClassLoader 是它的父加載器。
3.如果向上委托父加載器沒有加載成功，則通過 findClass(String) 查找。
如果class在上面的步驟中找到了，參數 resolve 又是true的話，那么 loadClass() 又會調用?resolveClass(Class)?這個方法來生成最終的Class對象。 我們可以從源代碼看出這個步驟：
代碼解釋了雙親委托。要注意的是如果要編寫一個 classLoader 的子類，也就是自定義一個 classloader，建議覆蓋?findClass()方法，而不要直接改寫?loadClass()方法。另外：
前面說過 ExtClassLoader 的 parent 為 null，所以它向上委托時，系統會為它指定 Bootstrap ClassLoader。
自定義ClassLoader
不知道大家有沒有發現，不管是 Bootstrap ClassLoader 還是 ExtClassLoader等，這些類加載器都只是加載指定的目錄下的jar包或者資源。如果在某種情況下，我們需要動態加載一些東西呢？比如從D盤某個文件夾加載一個class文件，或者從網絡上下載class主內容然后再進行加載，這樣可以嗎？
如果要這樣做的話，需要我們自定義一個 classloader。
自定義步驟
1.編寫一個類繼承自 ClassLoader 抽象類。
2.復寫它的?findClass()?方法。
3.在?findClass()?方法中調用?defineClass()
defineClass()
這個方法在編寫自定義 classloader 的時候非常重要，它能將 class 二進制內容轉換成 Class對象，如果不符合要求的會拋出各種異常。
注意點
一個 ClassLoader 創建時如果沒有指定 parent，那么它的 parent 默認就是 AppClassLoader。
上面說的是，如果自定義一個 ClassLoader，默認的 parent 父加載器是 AppClassLoader，因為這樣就能夠保證它能訪問系統內置加載器加載成功的class文件。
自定義ClassLoader示例之DiskClassLoader
假設我們需要一個自定義的classloader,默認加載路徑為?D:\lib?下的jar包和資源。
我們寫編寫一個測試用的類文件，Test.java：
然后將它編譯過年class文件Test.class放到D:\lib這個路徑下。
我們編寫DiskClassLoader的代碼：
我們在?findClass()?方法中定義了查找class的方法，然后數據通過?defineClass()?生成了Class對象。
現在我們要編寫測試代碼。我們知道如果調用一個 Test對象 的 say方法，它會輸出”Say Hello”這條字符串。但現在是我們把 Test.class 放置在應用工程所有的目錄之外，我們需要加載它，然后執行它的方法。具體效果如何呢？我們編寫的 DiskClassLoader 能不能順利完成任務呢？我們拭目以待。
我們點擊運行按鈕，結果顯示：
可以看到，Test類的say方法正確執行，也就是我們寫的 DiskClassLoader 編寫成功。
回首
講了這么大的篇幅，自定義ClassLoader才姍姍來遲。 很多同學可能覺得前面有些啰嗦，但我按照自己的思路，我覺得還是有必要的。因為我是圍繞一個關鍵字進行講解的。
關鍵字是什么？關鍵字路徑
從開篇的環境變量
到3個主要的JDK自帶的類加載器
到自定義的ClassLoader
它們的關聯部分就是路徑，也就是要加載的class或者是資源的路徑。
BootStrap ClassLoader、ExtClassLoader、AppClassLoader 都是加載指定路徑下的jar包。如果我們要突破這種限制，實現自己某些特殊的需求，我們就得自定義ClassLoader，自已指定加載的路徑，可以是磁盤、內存、網絡或者其它。
完。。。。。。。。。。。。。。。。。。。。。
文章原創作者GuoLin 書籍推薦
郭林大神原創android 書籍：《第一行代碼 android》
