疑惑
以前在看源碼的時候，總是會遇到框架里的代碼使用thread.currentthread.getcontextclassloader()獲取當前線程的context類加載器，通過這個context類加載器去加載類。
我們平時在程序中寫代碼的時候，遇到要動態加載類的時候，一般使用class.forname()的方式加載我們需要的類。比如最常見的，當我們進行jdbc編程的時候，我們通過class.forname()去加載jdbc的驅動。
|
1
2
3
4
5
|
try { return class.forname("oracle.jdbc.driver.oracledriver");} catch (classnotfoundexception e) { // skip} |
那么為什么當我們使用class.forname()的方式去加載類的時候，如果類找不到，我們還要嘗試用thread.currentthread.getcontextloader()獲取的類加載器去加載類呢？比如我們可能會碰到下面這種代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
try { return class.forname(classname);} catch (classnotfoundexception e) { // skip}classloader ctxclassloader = thread.currentthread().getcontextclassloader();if (ctxclassloader != null) { try { clazz = ctxclassloader.loadclass(classname); } catch (classnotfoundexception e) { // skip }} |
這里加粗的部分，就是使用了thread.currentthread.getcontextloader()獲取的加載器去加載類。顯然，class.forname()加載類的時候使用的類加載器可能和thread.currentthread.getcontextloader()獲取的類加載器是不同的。那么為什么會出現不同呢？
java的類加載器
要理解為什么會用到thread.currentthread.getcontextloader()獲取的這個類加載器之前，我們先來了解下jvm里使用的類加載器（classloader）。
jvm默認有三種類加載器：
- bootstrap class loader
- extension class loader
- system class loader
bootstrap class loader
bootstrap class loader類加載器是jdk自帶的一款類加載器，用于加載jdk內部的類。bootstrap類加載器用于加載jdk中$java_home/jre/lib下面的那些類，比如rt.jar包里面的類。bootstrap類加載器是jvm的一部分，一般采用native代碼編寫。
extension class loader
extension class loader類加載器主要用于加載jdk擴展包里的類。一般$java_home/lib/ext下面的包都是通過這個類加載器加載的，這個包下面的類基本上是以javax開頭的。
system class loader
system class loader類加載器也叫應用程序類加載器(appclassloader)。顧名思義，這個類加載器就是用來加載開發人員自己平時寫的應用代碼的類的。system類加載器是用于加載存放在classpath路徑下的那些應用程序級別的類的。
下面的代碼列舉出了這三個類加載器：
|
1
2
3
4
5
6
7
|
public class mainclass { public static void main(string[] args) { system.out.println(integer.class.getclassloader()); system.out.println(logging.class.getclassloader()); system.out.println(mainclass.class.getclassloader()); }} |
其中獲取bootstrap類加載器永遠返回null值
|
1
2
3
|
null # bootstrap類加載器sun.misc.launcher$extclassloader@5e2de80c # extension類加載器sun.misc.launcher$appclassloader@18b4aac2 # system類加載器 |
雙親委派模型
上面介紹的三種類加載器，并不是孤立的，他們之間有一個層次關系：
三個類加載器之間通過這個層次關系協同工作，一起負責類的加載工作。上面的這種層次模型稱為類加載器的“雙親委派”模型。雙親委派模型要求，除了最頂層的bootstrap類加載器之外，所有的類加載器都必須有一個parent加載器。當類加載器加載類的時候，首先檢查緩存中是否有已經被加載的類。如果沒有，則優先委托它的父加載器去加載這個類，父加載器執行和前面子加載器一樣的工作，直到請求達到頂層的bootstrap類加載器。如果父加載器不能加載需要的類，那么這個時候才會讓子加載器自己去嘗試加載這個類。工作原理類似于下面這種方式：
我們可以通過jdk里classloader里面的代碼一窺雙親委派機制的實現方式，代碼實現在classloader.loadclass()里面
|
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
|
rotected class<?> loadclass(string name, boolean resolve) throws classnotfoundexception synchronized (getclassloadinglock(name)) { // first, check if the class has already been loaded class<?> c = findloadedclass(name); if (c == null) { long t0 = system.nanotime(); try { if (parent != null) { c = parent.loadclass(name, false); } else { 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(); 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(c); } return c; } |
采用雙親委派的方式組織類加載器，一個好處是為了安全。如果我們自己定義了一個string類，希望將這個string類替換掉默認java中的java.lang.string的實現。
我們將自己實現的string類的class文件放到classpath路徑下，當我們使用類加載器去加載我們實現的string類的時候，首先，類加載器會將請求委托給父加載器，通過層層委派，最終由bootstrap類加載器加載rt.jar包里的string類型，然后一路返回給我們。在這個過程中，我們的類加載器忽略掉了我們放在classpath中自定義的string類。
如果沒有采用雙親委派機制，那么system類加載器可以在classpath路徑中找到string的class文件并加載到程序中，導致jdk中的string實現被覆蓋。所以類加載器的這種工作方式，在一定程度上保證了java程序可以安全穩定的運行。
線程上下文類加載器
上面講了那么多類加載器相關的內容，可還是沒有講到今天的主題，線程上下文類加載器。
到這里，我們已經知道java提供了三種類加載器，并且按照嚴格的雙親委派機制協同工作。表面上，似乎很完美，但正是這種嚴格的雙親委派機制導致在加載類的時候，存在一些局限性。
當我們更加基礎的框架需要用到應用層面的類的時候，只有當這個類是在我們當前框架使用的類加載器可以加載的情況下我們才能用到這些類。換句話說，我們不能使用當前類加載器的子加載器加載的類。這個限制就是雙親委派機制導致的，因為類加載請求的委派是單向的。
雖然這種情況不多，但是還是會有這種需求。比較典型的，jndi服務。jndi提供了查詢資源的接口，但是具體實現由不同的廠商實現。這個時候，jndi的代碼是由jvm的bootstrap類加載器加載，但是具體的實現是用戶提供的jdk之外的代碼，所以只能由system類加載器或者其他用戶自定義的類加載器去加載，在雙親委派的機制下，jndi獲取不到jndi的spi的實現。
為了解決這個問題，引入了線程上下文類加載器。通過java.lang.thread類的setcontextclassloader()設置當前線程的上下文類加載器（如果沒有設置，默認會從父線程中繼承，如果程序沒有設置過，則默認是system類加載器）。有了線程上下文類加載器，應用程序就可以通過java.lang.thread.setcontextclassloader()將應用程序使用的類加載器傳遞給使用更頂層類加載器的代碼。比如上面的jndi服務，就可以利用這種方式獲取到可以加載spi實現的類加載器，獲取需要的spi實現類。
可以看到，引入線程類加載器實際是對雙親委派機制的破壞，但是卻提供了類加載的靈活性。
解惑
回到開頭，框架的代碼為了加載框架之外用戶實現的類，由于這些類可能沒法通過框架使用的類加載器進行加載，為了繞過類加載器的雙親委派模型，采用thread.getcontextclassloader()的方式去加載這些類。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：http://www.cnblogs.com/duke2016/p/9164058.html
