Java 8之前的類加載器

啟動(dòng)類加載器（Bootstrap Class-Loader），加載jre/lib下面的jar文件，如rt.jar。它是個(gè)超級(jí)公民，即使是在開啟了Security Manager的時(shí)候，JDK仍賦予了它加載的程序AllPermission。

對(duì)于做底層開發(fā)的工程師，有的時(shí)候可能不得不去試圖修改JDK的基礎(chǔ)代碼，也就是通常意義上的核心類庫，我們可以使用下面的命令行參數(shù)。

# 指定新的 bootclasspath，替換 java.* 包的內(nèi)部實(shí)現(xiàn)
java -Xbootclasspath:<your_boot_classpath> your_App

# a 意味著 append，將指定目錄添加到 bootclasspath 后面
java -Xbootclasspath/a:<your_dir> your_App

# p 意味著 prepend，將指定目錄添加到 bootclasspath 前面
java -Xbootclasspath/p:<your_dir> your_App

用法其實(shí)很易懂，例如，使用最常見的“/p”，既然是前置，就有機(jī)會(huì)替換個(gè)別基礎(chǔ)類的實(shí)現(xiàn)。

我們一般可以使用下面方法獲取父加載器，但是在通常的JDK/JRE實(shí)現(xiàn)中，擴(kuò)展類加載器getParent()都只能返回null。

public final ClassLoader getParent()

擴(kuò)展類加載器（Extension or Ext Class-Loader），負(fù)責(zé)加載我們放到j(luò)re/lib/ext目錄下面的jar包，這就是所謂的extension機(jī)制。該目錄也可以通過設(shè)置“java.ext.dirs”來覆蓋

java -Djava.ext.dirs=your_ext_dir HelloWorld

應(yīng)用類加載器（Application or App Class-Loader），就是加載我們最熟悉的classpath的內(nèi)容。這里有一個(gè)容易混淆的概念，系統(tǒng)（System）類加載器，通常來說，其默認(rèn)就是JDK內(nèi)建的應(yīng)用類加載器，但是它同樣是可能修改的，比如：

java -Djava.system.class.loader=com.yourcorp.YourClassLoader HelloWorld

如果我們指定了這個(gè)參數(shù)，JDK內(nèi)建的應(yīng)用類加載器就會(huì)成為定制加載器的父親，這種方式通常用在類似需要改變雙親委派模式的場(chǎng)景。

具體參考下圖：

雙親委派模型

談到類加載一個(gè)躲不開的話題就是“雙親委派模型”，簡(jiǎn)單說就是當(dāng)類加載器（Class-Loader）試圖加載某個(gè)類型的時(shí)候，除非父加載器找不到相應(yīng)的類型，否則盡量將這個(gè)任務(wù)代理給當(dāng)前加載器的父加載器去做。

參考上面這個(gè)結(jié)構(gòu)圖就很容易理解了。試想，如果不同類加載器都自己加載需要的某個(gè)類型，那么就會(huì)出現(xiàn)多次重復(fù)加載，完全是種浪費(fèi)。

通常類加載器機(jī)制有三個(gè)基本特征：

• 雙親委派模型。但不是所有類加載都遵守這個(gè)模型，有的時(shí)候，啟動(dòng)類加載器所加載的類型，是可能要加載用戶代碼的。比如JDK內(nèi)部的ServiceProvider/ServiceLoader機(jī)制，用戶可以在標(biāo)準(zhǔn)API框架上，提供自己的實(shí)現(xiàn)，JDK也需要提供些默認(rèn)的參考實(shí)現(xiàn)。例如，Java中JNDI、JDBC、文件系統(tǒng)、Cipher等很多方面，都是利用的這種機(jī)制，這種情況就不會(huì)用雙親委派模型去加載，而是利用所謂的上下文加載器。

• 可見性。子加載器可以訪問父加載器加載的類型，但是反過來是不允許的。不然，因?yàn)槿鄙俦匾母綦x，我們就沒有辦法利用類加載器去實(shí)現(xiàn)容器的邏輯。

• 單一性。由于父加載器的類型對(duì)于子加載器是可見的，所以父加載器中加載過的類型，就不會(huì)在子加載器中重復(fù)加載。但是注意，類加載器“鄰居”間，同一類型仍然可以被加載多次，因?yàn)榛ハ嗖豢梢姟?/p>