本篇文章已受權微信公衆號 guolin_blog (郭霖)獨家發佈html
ClassLoader翻譯過來就是類加載器,普通的Java開發者其實用到的很少,但對於某些框架開發者來講卻很是常見。理解ClassLoader的加載機制,也有利於咱們編寫出更高效的代碼。ClassLoader的具體做用就是將class文件加載到jvm虛擬機中去,程序就能夠正確運行了。可是,jvm啓動的時候,並不會一次性加載全部的class文件,而是根據須要去動態加載。想一想也是的,一次性加載那麼多jar包那麼多class,那內存不崩潰。本文的目的也是學習ClassLoader這種加載機制。java
備註:本文篇幅比較長,但內容簡單,你們不要恐慌,安靜地耐心翻閱就是python
咱們都知道在Java中程序是運行在虛擬機中,咱們日常用文本編輯器或者是IDE編寫的程序都是.java格式的文件,這是最基礎的源碼,但這類文件是不能直接運行的。如咱們編寫一個簡單的程序HelloWorld.javaandroid
public class HelloWorld{ public static void main(String[] args){ System.out.println("Hello world!"); } }
如圖:
而後,咱們須要在命令行中進行java文件的編譯編程
javac HelloWorld.java
能夠看到目錄下生成了.class文件bootstrap
咱們再從命令行中執行命令:api
java HelloWorld
上面是基本代碼示例,是全部入門JAVA語言時都學過的東西,這裏從新拿出來是想讓你們將焦點回到class文件上,class文件是字節碼格式文件,java虛擬機並不能直接識別咱們日常編寫的.java源文件,因此須要javac這個命令轉換成.class文件。另外,若是用C或者Python編寫的程序正確轉換成.class文件後,java虛擬機也是能夠識別運行的。更多信息你們能夠參考這篇。緩存
瞭解了.class文件後,咱們再來思考下,咱們日常在Eclipse中編寫的java程序是如何運行的,也就是咱們本身編寫的各類類是如何被加載到jvm(java虛擬機)中去的。安全
初學java的時候,最懼怕的就是下載JDK後要配置環境變量了,關鍵是當時不理解,因此戰戰兢兢地照着書籍上或者是網絡上的介紹進行操做。而後下次再弄的時候,又忘記了並且是必忘。當時,內心的想法很氣憤的,想着是–這東西一點也不人性化,爲何非要本身配置環境變量呢?太不照顧菜鳥和新手了,不少菜鳥就是由於卡在環境變量的配置上,遭受了太多的挫敗感。微信
由於我是在Windows下編程的,因此只講Window平臺上的環境變量,主要有3個:JAVA_HOME、PATH、CLASSPATH。
指的是你JDK安裝的位置,通常默認安裝在C盤,如
C:\Program Files\Java\jdk1.8.0_91
將程序路徑包含在PATH當中後,在命令行窗口就能夠直接鍵入它的名字了,而再也不須要鍵入它的全路徑,好比上面代碼中我用的到javac
和java
兩個命令。
通常的
PATH=%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;%PATH%;
也就是在原來的PATH路徑上添加JDK目錄下的bin目錄和jre目錄的bin.
CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar
一看就是指向jar包路徑。
須要注意的是前面的.;
,.
表明當前目錄。
設置能夠右擊個人電腦,而後點擊屬性,再點擊高級,而後點擊環境變量,具體不明白的自行查閱文檔。
查看的話能夠打開命令行窗口
echo %JAVA_HOME% echo %PATH% echo %CLASSPATH%
好了,扯遠了,知道了環境變量,特別是CLASSPATH時,咱們進入今天的主題Classloader.
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,它是一個java虛擬機的入口應用。
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); } /* * Returns the class loader used to launch the main application. */ public ClassLoader getClassLoader() { return loader; } /* * The class loader used for loading installed extensions. */ static class ExtClassLoader extends URLClassLoader {} /** * The class loader used for loading from java.class.path. * runs in a restricted security context. */ static class AppClassLoader extends URLClassLoader {}
源碼有精簡,咱們能夠獲得相關的信息。
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"));
獲得的結果是:
C:\Program Files\Java\jre1.8.0_91\lib\resources.jar; C:\Program Files\Java\jre1.8.0_91\lib\rt.jar; C:\Program Files\Java\jre1.8.0_91\lib\sunrsasign.jar; C:\Program Files\Java\jre1.8.0_91\lib\jsse.jar; C:\Program Files\Java\jre1.8.0_91\lib\jce.jar; C:\Program Files\Java\jre1.8.0_91\lib\charsets.jar; C:\Program Files\Java\jre1.8.0_91\lib\jfr.jar; C:\Program Files\Java\jre1.8.0_91\classes
能夠看到,這些全是JRE目錄下的jar包或者是class文件。
若是你有足夠的好奇心,你應該會對它的源碼感興趣
/* * The class loader used for loading installed extensions. */ static class ExtClassLoader extends URLClassLoader { static { ClassLoader.registerAsParallelCapable(); } /** * create an ExtClassLoader. The ExtClassLoader is created * within a context that limits which files it can read */ 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 Files\Java\jre1.8.0_91\lib\ext;C:\Windows\Sun\Java\lib\ext
/** * The class loader used for loading from java.class.path. * runs in a restricted security context. */ 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:\workspace\ClassLoaderDemo\bin
這個路徑其實就是當前java工程目錄bin,裏面存放的是編譯生成的class文件。
好了,自此咱們已經知道了BootstrapClassLoader、ExtClassLoader、AppClassLoader實際是查閱相應的環境屬性sun.boot.class.path
、java.ext.dirs
和java.class.path
來加載資源文件的。
接下來咱們探討它們的加載順序,咱們先用Eclipse創建一個java工程。
而後建立一個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提及,這個類又是什麼?
先上一張類的繼承關係圖
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對象的構造方法中,它有兩個狀況:
1. 由外部類建立ClassLoader時直接指定一個ClassLoader爲parent。
2. 由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 { /** * create an ExtClassLoader. The ExtClassLoader is created * within a context that limits which files it can read */ 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(); } } /* * Creates a new ExtClassLoader for the specified directories. */ 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/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()。
JDK文檔中是這樣寫的,經過指定的全限定類名加載class,它經過同名的loadClass(String,boolean)方法。
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
上面是方法原型,通常實現這個方法的步驟是
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對象。 咱們能夠從源代碼看出這個步驟。
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。
不知道你們有沒有發現,無論是Bootstrap ClassLoader仍是ExtClassLoader等,這些類加載器都只是加載指定的目錄下的jar包或者資源。若是在某種狀況下,咱們須要動態加載一些東西呢?好比從D盤某個文件夾加載一個class文件,或者從網絡上下載class主內容而後再進行加載,這樣能夠嗎?
若是要這樣作的話,須要咱們自定義一個classloader。
findClass()
方法。findClass()
方法中調用defineClass()
。這個方法在編寫自定義classloader的時候很是重要,它能將class二進制內容轉換成Class對象,若是不符合要求的會拋出各類異常。
一個ClassLoader建立時若是沒有指定parent,那麼它的parent默認就是AppClassLoader。
上面說的是,若是自定義一個ClassLoader,默認的parent父加載器是AppClassLoader,由於這樣就可以保證它能訪問系統內置加載器加載成功的class文件。
假設咱們須要一個自定義的classloader,默認加載路徑爲D:\lib
下的jar包和資源。
咱們寫編寫一個測試用的類文件,Test.java
package com.frank.test; public class Test { public void say(){ System.out.println("Say Hello"); } }
而後將它編譯過年class文件Test.class放到D:\lib
這個路徑下。
咱們編寫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(); } } }
咱們點擊運行按鈕,結果顯示。
能夠看到,Test類的say方法正確執行,也就是咱們寫的DiskClassLoader編寫成功。
講了這麼大的篇幅,自定義ClassLoader才姍姍來遲。 不少同窗可能以爲前面有些囉嗦,但我按照本身的思路,我以爲仍是有必要的。由於我是圍繞一個關鍵字進行講解的。
關鍵字是什麼?
它們的關聯部分就是路徑,也就是要加載的class或者是資源的路徑。
BootStrap ClassLoader、ExtClassLoader、AppClassLoader都是加載指定路徑下的jar包。若是咱們要突破這種限制,實現本身某些特殊的需求,咱們就得自定義ClassLoader,自已指定加載的路徑,能夠是磁盤、內存、網絡或者其它。
因此,你說路徑能不能成爲它們的關鍵字?
固然上面的只是我我的的見解,可能不正確,但現階段,這樣有利於本身的學習理解。
突破了JDK系統內置加載路徑的限制以後,咱們就能夠編寫自定義ClassLoader,而後剩下的就叫給開發者你本身了。你能夠按照本身的意願進行業務的定製,將ClassLoader玩出花樣來。
常見的用法是將Class文件按照某種加密手段進行加密,而後按照規則編寫自定義的ClassLoader進行解密,這樣咱們就能夠在程序中加載特定了類,而且這個類只能被咱們自定義的加載器進行加載,提升了程序的安全性。
下面,咱們編寫代碼。
加密和解密的協議有不少種,具體怎麼定看業務須要。在這裏,爲了便於演示,我簡單地將加密解密定義爲異或運算。當一個文件進行異或運算後,產生了加密文件,再進行一次異或後,就進行了解密。
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:\\lib\\Test.class");
而後能夠看見路徑D:\\lib\\Test.class
下Test.class生成了Test.classen文件。
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(); }
查看運行結果是:
能夠看到了,一樣成功了。如今,咱們有兩個自定義的ClassLoader:DiskClassLoader和DeClassLoader,咱們能夠嘗試一下,看看DiskClassLoader能不能加載Test.classen文件也就是Test.class加密後的文件。
咱們首先移除D:\\lib\\Test.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(); } }
運行結果:
咱們能夠看到。DeClassLoader運行正常,而DiskClassLoader卻找不到Test.class的類,而且它也沒法加載Test.classen文件。
前面講到過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:\\lib\\test
目錄下。
另外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:\\lib\\test
中的SpeakTest.class文件。
測試代碼:
DiskClassLoader1 diskLoader1 = new DiskClassLoader1("D:\\lib\\test"); 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();
結果以下:
咱們能夠獲得以下的信息:
1. DiskClassLoader1加載成功了SpeakTest.class文件並執行成功。
2. 子線程的ContextClassLoader是AppClassLoader。
3. AppClassLoader加載不了父線程當中已經加載的SpeakTest.class內容。
咱們修改一下代碼,在子線程開頭處加上這麼一句內容。
Thread.currentThread().setContextClassLoader(diskLoader1);
結果以下:
能夠看到子線程的ContextClassLoader變成了DiskClassLoader。
繼續改動代碼:
Thread.currentThread().setContextClassLoader(diskLoader);
結果:
能夠看到DiskClassLoader1和DiskClassLoader分別加載了本身路徑下的SpeakTest.class文件,而且它們的類名是同樣的com.frank.test.SpeakTest
,可是執行結果不同,由於它們的實際內容不同。
其實這個我也不是很清楚,個人主業是Android,研究ClassLoader也是爲了更好的研究android。網上的答案說是適應那些Web服務框架軟件如Tomcat等。主要爲了加載不一樣的APP,由於加載器不同,同一份class文件加載後生成的類是不相等的。若是有同窗想多瞭解更多的細節,請自行查閱相關資料。
我這篇文章寫了好幾天,修修改改,而後加上本身的理解。參考了下面的這些網站。
1. grepcode ClassLoader源碼
2. http://blog.csdn.net/xyang81/article/details/7292380
3. http://blog.csdn.net/irelandken/article/details/7048817
4. https://docs.oracle.com/javase/7/docs/api/java/net/URLClassLoader.html