ClassLoader翻譯過來就是類加載器,普通的Java開發者其實用到的不多,但對於某些框架開發者來說卻非常常見。理解ClassLoader的加載機制,也有利於我們編寫出更高效的代碼。ClassLoader的具體作用就是將class文件加載到jvm虛擬機中去,程序就可以正確運行了。但是,jvm啓動的時候,並不會一次性加載所有的class文件,而是根據需要去動態加載。想想也是的,一次性加載那麼多jar包那麼多class,那內存不崩潰。本文的目的也是學習ClassLoader這種加載機制。
備註:本文篇幅比較長,但內容簡單,大家不要恐慌,安靜地耐心翻閱就是
Class文件的認識
我們都知道在Java中程序是運行在虛擬機中,我們平常用文本編輯器或者是IDE編寫的程序都是.java格式的文件,這是最基礎的源碼,但這類文件是不能直接運行的。如我們編寫一個簡單的程序HelloWorld.java
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
如圖:
然後,我們需要在命令行中進行java文件的編譯
- 1
- 1
可以看到目錄下生成了.class文件
我們再從命令行中執行命令:
- 1
- 1
上面是基本代碼示例,是所有入門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盤,如
- 1
- 1
PATH
將程序路徑包含在PATH當中後,在命令行窗口就可以直接鍵入它的名字了,而不再需要鍵入它的全路徑,比如上面代碼中我用的到javac
和java
兩個命令。
一般的
- 1
- 1
也就是在原來的PATH路徑上添加JDK目錄下的bin目錄和jre目錄的bin.
CLASSPATH
- 1
- 1
一看就是指向jar包路徑。
需要注意的是前面的.;
,.
代表當前目錄。
環境變量的設置與查看
設置可以右擊我的電腦,然後點擊屬性,再點擊高級,然後點擊環境變量,具體不明白的自行查閱文檔。
查看的話可以打開命令行窗口
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
好了,扯遠了,知道了環境變量,特別是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,它是一個java虛擬機的入口應用。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
源碼有精簡,我們可以得到相關的信息。
1. Launcher初始化了ExtClassLoader和AppClassLoader。
2. Launcher中並沒有看見BootstrapClassLoader,但通過System.getProperty("sun.boot.class.path")
得到了字符串bootClassPath
,這個應該就是BootstrapClassLoader加載的jar包路徑。
我們可以先代碼測試一下sun.boot.class.path
是什麼內容。
- 1
- 1
得到的結果是:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
可以看到,這些全是JRE目錄下的jar包或者是class文件。
ExtClassLoader源碼
如果你有足夠的好奇心,你應該會對它的源碼感興趣
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
我們先前的內容有說過,可以指定-D java.ext.dirs
參數來添加和改變ExtClassLoader的加載路徑。這裏我們通過可以編寫測試代碼。
- 1
- 1
結果如下:
- 1
- 1
AppClassLoader源碼
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
可以看到AppClassLoader加載的就是java.class.path
下的路徑。我們同樣打印它的值。
- 1
- 1
結果:
- 1
- 1
這個路徑其實就是當前java工程目錄bin,裏面存放的是編譯生成的class文件。
好了,自此我們已經知道了BootstrapClassLoader、ExtClassLoader、AppClassLoader實際是查閱相應的環境屬性sun.boot.class.path
、java.ext.dirs
和java.class.path
來加載資源文件的。
接下來我們探討它們的加載順序,我們先用Eclipse建立一個java工程。
然後創建一個Test.java
文件。
- 1
- 1
然後,編寫一個ClassLoaderTest.java文件。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
我們獲取到了Test.class文件的類加載器,然後打印出來。結果是:
- 1
- 1
也就是說明Test.class文件是由AppClassLoader加載的。
這個Test類是我們自己編寫的,那麼int.class或者是String.class的加載是由誰完成的呢?
我們可以在代碼中嘗試
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
運行一下,卻報錯了
- 1
- 2
- 3
- 1
- 2
- 3
提示的是空指針,意思是int.class這類基礎類沒有類加載器加載?
當然不是!
int.class是由Bootstrap ClassLoader加載的。要想弄明白這些,我們首先得知道一個前提。
每個類加載器都有一個父加載器
每個類加載器都有一個父加載器,比如加載Test.class是由AppClassLoader完成,那麼AppClassLoader也有一個父加載器,怎麼樣獲取呢?很簡單,通過getParent方法。比如代碼可以這樣編寫:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
運行結果如下:
- 1
- 2
- 1
- 2
這個說明,AppClassLoader的父加載器是ExtClassLoader。那麼ExtClassLoader的父加載器又是誰呢?
- 1
- 2
- 3
- 1
- 2
- 3
運行如果:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
又是一個空指針異常,這表明ExtClassLoader也沒有父加載器。那麼,爲什麼標題又是每一個加載器都有一個父加載器呢?這不矛盾嗎?爲了解釋這一點,我們還需要看下面的一個基礎前提。
父加載器不是父類
我們先前已經粘貼了ExtClassLoader和AppClassLoader的代碼。
- 1
- 2
- 1
- 2
可以看見ExtClassLoader和AppClassLoader同樣繼承自URLClassLoader,但上面一小節代碼中,爲什麼調用AppClassLoader的getParent()
代碼會得到ExtClassLoader的實例呢?先從URLClassLoader說起,這個類又是什麼?
先上一張類的繼承關係圖
URLClassLoader的源碼中並沒有找到getParent()
方法。這個方法在ClassLoader.java中。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
我們可以看到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的部分代碼。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
我們需要注意的是
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
代碼已經說明了問題AppClassLoader的parent是一個ExtClassLoader實例。
ExtClassLoader並沒有直接找到對parent的賦值。它調用了它的父類也就是URLClassLoder的構造方法並傳遞了3個參數。
- 1
- 2
- 3
- 1
- 2
- 3
對應的代碼
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
答案已經很明瞭了,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)方法。
- 1
- 2
- 3
- 1
- 2
- 3
上面是方法原型,一般實現這個方法的步驟是
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對象。
我們可以從源代碼看出這個步驟。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
代碼解釋了雙親委託。
另外,要注意的是如果要編寫一個classLoader的子類,也就是自定義一個classloader,建議覆蓋findClass()
方法,而不要直接改寫loadClass()
方法。
另外
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
前面說過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
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
然後將它編譯過年class文件Test.class放到D:\lib
這個路徑下。
DiskClassLoader
我們編寫DiskClassLoader的代碼。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
我們在findClass()
方法中定義了查找class的方法,然後數據通過defineClass()
生成了Class對象。
測試
現在我們要編寫測試代碼。我們知道如果調用一個Test對象的say方法,它會輸出”Say Hello”這條字符串。但現在是我們把Test.class放置在應用工程所有的目錄之外,我們需要加載它,然後執行它的方法。具體效果如何呢?我們編寫的DiskClassLoader能不能順利完成任務呢?我們拭目以待。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
我們點擊運行按鈕,結果顯示。
可以看到,Test類的say方法正確執行,也就是我們寫的DiskClassLoader編寫成功。
回首
講了這麼大的篇幅,自定義ClassLoader才姍姍來遲。 很多同學可能覺得前面有些囉嗦,但我按照自己的思路,我覺得還是有必要的。因爲我是圍繞一個關鍵字進行講解的。
關鍵字是什麼?
關鍵字 路徑
- 從開篇的環境變量
- 到3個主要的JDK自帶的類加載器
- 到自定義的ClassLoader
它們的關聯部分就是路徑,也就是要加載的class或者是資源的路徑。
BootStrap ClassLoader、ExtClassLoader、AppClassLoader都是加載指定路徑下的jar包。如果我們要突破這種限制,實現自己某些特殊的需求,我們就得自定義ClassLoader,自已指定加載的路徑,可以是磁盤、內存、網絡或者其它。
所以,你說路徑能不能成爲它們的關鍵字?
當然上面的只是我個人的看法,可能不正確,但現階段,這樣有利於自己的學習理解。
自定義ClassLoader還能做什麼?
突破了JDK系統內置加載路徑的限制之後,我們就可以編寫自定義ClassLoader,然後剩下的就叫給開發者你自己了。你可以按照自己的意願進行業務的定製,將ClassLoader玩出花樣來。
玩出花之Class解密類加載器
常見的用法是將Class文件按照某種加密手段進行加密,然後按照規則編寫自定義的ClassLoader進行解密,這樣我們就可以在程序中加載特定了類,並且這個類只能被我們自定義的加載器進行加載,提高了程序的安全性。
下面,我們編寫代碼。
1.定義加密解密協議
加密和解密的協議有很多種,具體怎麼定看業務需要。在這裏,爲了便於演示,我簡單地將加密解密定義爲異或運算。當一個文件進行異或運算後,產生了加密文件,再進行一次異或後,就進行了解密。
2.編寫加密工具類
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
我們再寫測試代碼
- 1
- 1
然後可以看見路徑D:\\lib\\Test.class
下Test.class生成了Test.classen文件。
編寫自定義classloader,DeClassLoader
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
測試
我們可以在ClassLoaderTest.java中的main方法中如下編碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
查看運行結果是:
可以看到了,同樣成功了。現在,我們有兩個自定義的ClassLoader:DiskClassLoader和DeClassLoader,我們可以嘗試一下,看看DiskClassLoader能不能加載Test.classen文件也就是Test.class加密後的文件。
我們首先移除D:\\lib\\Test.class
文件,只剩下一下Test.classen文件,然後進行代碼的測試。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
運行結果:
我們可以看到。DeClassLoader運行正常,而DiskClassLoader卻找不到Test.class的類,並且它也無法加載Test.classen文件。
Context ClassLoader 線程上下文類加載器
前面講到過Bootstrap ClassLoader、ExtClassLoader、AppClassLoader,現在又出來這麼一個類加載器,這是爲什麼?
前面三個之所以放在前面講,是因爲它們是真實存在的類,而且遵從”雙親委託“的機制。而ContextClassLoader其實只是一個概念。
查看Thread.java源碼可以發現
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
contextClassLoader只是一個成員變量,通過setContextClassLoader()
方法設置,通過getContextClassLoader()
設置。
每個Thread都有一個相關聯的ClassLoader,默認是AppClassLoader。並且子線程默認使用父線程的ClassLoader除非子線程特別設置。
我們同樣可以編寫代碼來加深理解。
現在有2個SpeakTest.class文件,一個源碼是
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
它生成的SpeakTest.class文件放置在D:\\lib\\test
目錄下。
另外ISpeak.java代碼
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
然後,我們在這裏還實現了一個SpeakTest.java
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
它生成的SpeakTest.class文件放置在D:\\lib
目錄下。
然後我們還要編寫另外一個ClassLoader,DiskClassLoader1.java這個ClassLoader的代碼和DiskClassLoader.java代碼一致,我們要在DiskClassLoader1中加載位置於D:\\lib\\test
中的SpeakTest.class文件。
測試代碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
結果如下:
我們可以得到如下的信息:
1. DiskClassLoader1加載成功了SpeakTest.class文件並執行成功。
2. 子線程的ContextClassLoader是AppClassLoader。
3. AppClassLoader加載不了父線程當中已經加載的SpeakTest.class內容。
我們修改一下代碼,在子線程開頭處加上這麼一句內容。
- 1
- 1
結果如下:
可以看到子線程的ContextClassLoader變成了DiskClassLoader。
繼續改動代碼:
- 1
- 2
- 1
- 2
結果:
可以看到DiskClassLoader1和DiskClassLoader分別加載了自己路徑下的SpeakTest.class文件,並且它們的類名是一樣的com.frank.test.SpeakTest
,但是執行結果不一樣,因爲它們的實際內容不一樣。
Context ClassLoader的運用時機
其實這個我也不是很清楚,我的主業是Android,研究ClassLoader也是爲了更好的研究Android。網上的答案說是適應那些Web服務框架軟件如Tomcat等。主要爲了加載不同的APP,因爲加載器不一樣,同一份class文件加載後生成的類是不相等的。如果有同學想多瞭解更多的細節,請自行查閱相關資料。
總結
- ClassLoader用來加載class文件的。
- 系統內置的ClassLoader通過雙親委託來加載指定路徑下的class和資源。
- 可以自定義ClassLoader一般覆蓋findClass()方法。
- ContextClassLoader與線程相關,可以獲取和設置,可以繞過雙親委託的機制。
下一步
- 你可以研究ClassLoader在Web容器內的應用了,如Tomcat。
- 可以嘗試以這個爲基礎,繼續學習Android中的ClassLoader機制。
引用
我這篇文章寫了好幾天,修修改改,然後加上自己的理解。參考了下面的這些網站。
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