類加載器在加載階段，會將class文件加載進方法區。有關類加載的全過程，可以先參考我的另外一篇文章類的奇幻漂流——類加載機制探秘
類加載器的類型
類加載器有以下種類：
- 啟動類加載器(Bootstrap ClassLoader)
- 擴展類加載器(Extension ClassLoader)
- 應用類加載器(Application ClassLoader)
啟動類加載器
內嵌在JVM內核中的加載器，由C++語言編寫(因此也不會繼承ClassLoader)，是類加載器層次中最頂層的加載器。用于加載java的核心類庫，即加載jre/lib/rt.jar里所有的class。由于啟動類加載器涉及到虛擬機本地實現細節，我們無法獲取啟動類加載器的引用。
擴展類加載器
它負責加載JRE的擴展目錄，jre/lib/ext或者由java.ext.dirs系統屬性指定的目錄中jar包的類。父類加載器為啟動類加載器，但使用擴展類加載器調用getParent依然為null。
應用類加載器
又稱系統類加載器，可用通過 java.lang.ClassLoader.getSystemClassLoader()方法獲得此類加載器的實例，系統類加載器也因此得名。應用類加載器主要加載classpath下的class，即用戶自己編寫的應用編譯得來的class，調用getParent返回擴展類加載器。
擴展類加載器與應用類加載器繼承結構如圖所示：
可以看到除了啟動類加載器，其余的兩個類加載器都繼承于ClassLoader，我們自定義的類加載，也需要繼承ClassLoader。
雙親委派機制
當一個類加載器收到了一個類加載請求時，它自己不會先去嘗試加載這個類，而是把這個請求轉交給父類加載器，每一個層的類加載器都是如此，因此所有的類加載請求都應該傳遞到最頂層的啟動類加載器中。只有當父類加載器在自己的加載范圍內沒有搜尋到該類時，并向子類反饋自己無法加載后，子類加載器才會嘗試自己去加載。
ClassLoader內的loadClass方法，就很好的解釋了雙親委派的加載模式：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
//檢查該class是否已經被當前類加載器加載過
Class<?> c = findLoadedClass(name);
if (c == null) {
//此時該class還沒有被加載
try {
if (parent != null) {
//如果父加載器不為null,則委托給父類加載
c = parent.loadClass(name, false);
} else {
//如果父加載器為null,說明當前類加載器已經是啟動類加載器，直接時候用啟動類加載器去加載該class
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
}
if (c == null) {
//此時父類加載器都無法加載該class,則使用當前類加載器進行加載
long t1 = System.nanoTime();
c = findClass(name);
...
}
}
//是否需要連接該類
if (resolve) {
resolveClass(c);
}
return c;
}
}
為什么要使用雙親委派機制，就使用當前的類加載器去加載不就行了嗎?為啥搞得這么復雜呢?
假設現在并沒有雙親委派機制，有這樣的一個場景：
用戶寫了一個Student類，點擊運行，此時編譯完成后，虛擬機開始加載class，該class會由應用加載器進行加載，由于Object類是Student的父類，且雙親委派機制不存在的情況下，應用加載器就會自己嘗試加載Object類，但是用戶壓根沒定義Object，即應用加載器無法在加載范圍搜尋到該類，所以此時Object類無法被加載，用戶寫的代碼無法運行。
假設該用戶自己定義了一個Object類，此時再次運行后，應用類加載器則會正常加載用戶定義的Object與Student類。Student類中會調用System.out.print()輸出Student對象，此時會由啟動類加載器加載System類，在此之前同樣也會加載Object類。
此時，方法區中有了兩份Object的元數據，Object類被重復加載了!
倘若用戶定義的Object類不安全，可能直接造成虛擬機崩潰或者引起重大安全問題。
如果現在使用雙親委派機制，用戶雖然自己定義了Object類，可以通過編譯，但是永遠不會被記載進方法區。
雙親委派機制避免了重復加載，也保證了虛擬機的安全。
自定義類加載器
我們整理ClassLoader里面的流程
loadclass：判斷是否已加載，使用雙親委派模型，請求父加載器，父加載器反饋無法加載，因此使用findclass，讓當前類加載器查找
findclass：當前類加載器根據路徑以及class文件名稱加載字節碼，從class文件中讀取字節數組，然后使用defineClass
defineclass：根據字節數組，返回Class對象
我們在ClassLoader里面找到findClass方法，發現該方法直接拋出異常，應該是留給子類實現的。
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
到這里，我們應該明白，loadClass方法使用了模版方法模式，主線邏輯是雙親委派，但如何將class文件轉化為Class對象的步驟，已經交由子類去實現。對模版方法模式不熟悉的同學，可以先參考我的另外一篇文章模版方法模式
其實源碼中，已經有一個自定義類加載的樣例代碼，在注釋中：
class NetworkClassLoader extends ClassLoader {
String host;
int port;
public Class findClass(String name) {
byte[] b = loadClassData(name);
return defineClass(name, b, 0, b.length);
}
private byte[] loadClassData(String name) {
// load the class data from the connection
}
}
看得出來，如果我們需要自定義類加載器，只需要繼承ClassLoader，并且重寫findClass方法即可。
現在有一個簡單的樣例，class文件依然在文件目錄中：
package com.yang.testClassLoader;
import sun.misc.Launcher;
import java.io.*;
public class MyClassLoader extends ClassLoader {
/**
* 類加載路徑,不包含文件名
*/
private String path;
public MyClassLoader(String path) {
super();
this.path = path;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] bytes = getBytesFromClass(name);
assert bytes != null;
//讀取字節數組，轉化為Class對象
return defineClass(name, bytes, 0, bytes.length);
}
//讀取class文件，轉化為字節數組
private byte[] getBytesFromClass(String name) {
String absolutePath = path + "/" + name + ".class";
FileInputStream fis = null;
ByteArrayOutputStream bos = null;
try {
fis = new FileInputStream(new File(absolutePath));
bos = new ByteArrayOutputStream();
byte[] temp = new byte[1024];
int len;
while ((len = fis.read(temp)) != -1) {
bos.write(temp, 0, len);
}
return bos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
} finally {
if (null != fis) {
try {
fis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
if (null != bos) {
try {
bos.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
return null;
}
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
MyClassLoader classLoader = new MyClassLoader("C://develop");
Class test = classLoader.loadClass("Student");
test.newInstance();
}
}
Student類：
public class Student {
public Student() {
System.out.println("student classloader is" + this.getClass().getClassLoader().toString());
}
}
注意，這個Student類千萬不要加包名，idea報錯不管他即可，然后使用javac Student.java編譯該類，將生成的class文件復制到c://develop下即可。
運行MyClassLoader的main方法后，可以看到輸出：
看得出來，Student.class確實是被我們自定義的類加載器給加載了。
破壞雙親委派
從上面的自定義類加載器的內容中，我們應該可以猜到了，破壞雙親委派直接重寫loadClass方法就完事了。事實上，我們確實可以重寫loadClass方法，畢竟這個方法沒有被final修飾。雙親委派既然有好處，為什么jdk對loadClass開放重寫呢?這要從雙親委派引入的時間來看：
- 雙親委派模型是在JDK1.2之后才被引入的，而類加載器和抽象類java.lang.ClassLoader則在JDK1.0時代就已經存在，面對已經存在的用戶自定義類加載器的實現代碼，Java設計者引入雙親委派模型時不得不做出一些妥協。在此之前，用戶去繼承java.lang.ClassLoader的唯一目的就是為了重寫loadClass()方法，jdk為了向前兼容，不得已開放對loadClass的重寫操作。
當然，也不止這一次對雙親委派模型的破壞，詳細的文章可以參考破壞雙親委派模型，里面提到了一個“線程上下文類加載器”，對這個不熟悉的同學可以參考真正理解線程上下文類加載器(多案例分析)(無法放鏈接，百度搜索)
我們經常用的Tomcat與jdbc，就破壞了雙親委派，礙于文章的篇幅與博主的水平，暫時不在這里討論破壞的原因，有興趣的同學可以參考這一篇文章JDBC、Tomcat為什么要破壞雙親委派模型?(無法放鏈接，百度搜索)
原文地址：https://www.toutiao.com/i6909260818903368195/
