作為Java開發(fā)者，無論是日常開發(fā)中的類加載問題，雙親委派機制都是繞不開的核心知識點。很多人初學的時候，會把它和類的繼承關系搞混，也分不清loadClass和findClass的區(qū)別，今天就結合我的學習心得，用最直白的話，把雙親委派機制講透，從原理、分工、易混點到打破方式，一站式搞懂，助力大家扎實掌握Java底層知識。
一、先理清：雙親委派到底是什么？
其實雙親委派機制很簡單，核心就一句話：類加載時，先找“父加載器”，父加載器加載不了，自己再嘗試加載。這里的“雙親”并不是指兩個父加載器，而是一種邏輯上的層級委派關系，并非Java中的繼承關系，這也是很多人容易混淆的點之一。
它的本質是JVM類加載器的一種協(xié)作策略，不是JVM強制規(guī)范，而是java.lang.ClassLoader默認實現(xiàn)的“委派優(yōu)先”規(guī)則，核心目的就是保證類加載的安全性和唯一性，避免核心類被篡改、類被重復加載。
二、三大核心類加載器：分工明確，各司其職
雙親委派的核心載體是三個層級的類加載器，自上而下分工清晰，很多人容易記反順序，這里結合我的理解，用最好記的方式梳理清楚（從頂層到底層，委派時從底層往頂層找）：
1. 啟動類加載器（Bootstrap ClassLoader）：最頂層的“守護者”
它是最頂層的類加載器，由C++實現(xiàn)（JDK1.8及之前），沒有對應的Java類，調用getParent()會返回null。它的核心職責只有一個：加載JDK核心類庫，比如rt.jar、resources.jar里的類，像我們每天用的java.lang.String、java.util.List，都是由它加載的。
它的加載范圍很嚴格，只識別包名以java.、javax.開頭的類，目的就是守護Java核心API，不讓其被篡改。
2. 擴展類加載器（ExtClassLoader）：中間的“補充者”
它是啟動類加載器的“子加載器”（邏輯上），負責加載JDK自帶的擴展類庫，這些類是JDK官方提供的擴展功能類，不屬于核心類，但也是JDK的一部分，無需我們手動引入，由JVM自動識別加載。
這里要注意：它加載的是JDK自帶的擴展包，不是我們自己引入的第三方jar包，很多人會把它和應用類加載器的職責搞混，記準這一點就不會錯。
3. 應用類加載器（AppClassLoader）：我們最熟悉的“執(zhí)行者”
它是擴展類加載器的“子加載器”，也是我們日常開發(fā)中最常用的類加載器，默認是系統(tǒng)類加載器。它的職責很明確：加載我們自己寫的類、項目classpath下的類，以及我們引入的第三方jar包（比如Spring、MyBatis等框架的類）。
簡單說，我們寫的每一個Java類，默認都是由它來加載的，除非我們自定義了類加載器。
三、雙親委派的完整流程：“先找爹，爹不行自己上”
結合三個類加載器，我們用一個通俗的例子，把加載流程講明白（以加載我們自己寫的Son類為例，Son繼承自Father）：
當JVM要加載Son類時，首先會交給應用類加載器；
應用類加載器不會直接加載，而是向上委派給它的“父加載器”——擴展類加載器；
擴展類加載器也不直接加載，繼續(xù)向上委派給最頂層的啟動類加載器；
啟動類加載器檢查自己的加載范圍（核心類庫），如果Son類是核心類，就直接加載；如果不是（比如我們自己寫的Son類），就加載失敗，把請求回退給擴展類加載器；
擴展類加載器檢查自己的加載范圍（擴展類庫），如果找不到Son類，就繼續(xù)回退給應用類加載器；
應用類加載器在自己的加載范圍（classpath）里找到Son類，開始加載；
加載Son類時，發(fā)現(xiàn)它繼承自Father類，此時會先加載Father類（這是類的繼承機制，和雙親委派無關！），F(xiàn)ather類的加載流程，同樣遵循上面的雙親委派規(guī)則；
如果所有父加載器都加載失敗，應用類加載器會調用findClass方法兜底加載，若還是找不到，就拋出ClassNotFoundException異常。
一句話總結流程：應用→擴展→啟動（委派），啟動→擴展→應用（回退），父加載器能加載就用父的，都加載不了自己來，findClass兜底。
四、最易混點：雙親委派 ≠ 類的繼承關系
這是90%的人都會踩的坑，包括我剛開始學習的時候，也經常把兩者搞混。這里用最直白的話，把兩者徹底區(qū)分開，記死這兩點，永遠不混淆：
1. 雙親委派：管“誰來加載類”
核心是類加載器之間的層級委派關系，比如應用類加載器找擴展類加載器，擴展類加載器找啟動類加載器，本質是“加載器找爹”，目的是安全和去重。
2. 類的繼承關系：管“類加載的先后順序”
核心是類與類之間的extends關系，比如Son繼承Father，加載Son時必須先加載Father，本質是“類找爹”，目的是保證子類能使用父類的屬性和方法，和雙親委派沒有任何關系。
舉個例子：加載Son類時，“先加載Father類”是繼承機制決定的；而“加載Father類時，先找啟動類加載器”是雙親委派機制決定的——兩個完全獨立的規(guī)則，只是都帶“父”字，才容易讓人混淆。
五、雙親委派的核心好處：為什么需要它？
理解了流程，就很容易明白它的好處，核心就兩點，掌握這兩點，就能徹底理解雙親委派的價值：
1. 保護核心類，防止被篡改
這是最核心的好處。比如我們自己寫一個java.lang.String類，重寫equals方法，按照雙親委派流程，加載這個類時，會先委派給啟動類加載器，而啟動類加載器已經加載了JDK核心的String類，所以我們自己寫的String類永遠不會被加載，從根本上保證了核心類庫的安全，避免Java運行環(huán)境被破壞。
2. 避免類重復加載，保證類的唯一性
JVM判斷兩個類是否相同，是由“類加載器+類的全限定名”共同決定的。如果沒有雙親委派，多個類加載器可能會重復加載同一個類，導致內存中出現(xiàn)多個相同的Class對象，引發(fā)ClassCastException（類轉換異常）等問題。雙親委派讓同一個類的加載請求最終只會被最頂層能加載它的類加載器處理，避免了重復加載，保證了類的唯一性。
六、如何打破雙親委派機制？
雙親委派是默認規(guī)則，但不是強制的，我們可以通過重寫ClassLoader的loadClass方法，打破這個機制。結合我的學習總結，最核心、最簡單的方式如下：
核心原理
雙親委派的邏輯，本質上是寫在ClassLoader的loadClass方法里的——默認的loadClass方法，會先檢查類是否已加載，然后向上委派給父加載器，父加載器加載失敗后，才調用findClass方法兜底加載。
所以，最簡單的打破方式就是：重寫loadClass方法，徹底去掉向上委派父加載器的邏輯，直接調用findClass方法加載類——這種方式無需額外復雜操作，是最直觀、最易實現(xiàn)的打破雙親委派的方式，完全跳過了整個委派流程，實現(xiàn)“自己加載，不找父加載器”。
最簡單的打破方式（代碼示例）
public class CustomClassLoader extends ClassLoader {
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 1. 檢查類是否已加載（避免重復加載）
Class<?> loadedClass = findLoadedClass(name);
if (loadedClass == null) {
// 2. 不向上委派父加載器，直接調用findClass兜底加載
loadedClass = findClass(name);
}
// 3. 解析類（resolve參數(shù)相關，按需處理）
if (resolve) {
resolveClass(loadedClass);
}
return loadedClass;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 這里實現(xiàn)自己的加載邏輯，比如從指定路徑讀取class文件
// 簡化示例，實際需根據(jù)需求實現(xiàn)
byte[] classData = loadClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
}
// 將字節(jié)碼轉換為Class對象（JVM底層實現(xiàn)，不可重寫）
return defineClass(name, classData, 0, classData.length);
}
// 模擬從指定路徑加載class文件字節(jié)碼
private byte[] loadClassData(String className) {
// 實際開發(fā)中可從文件、網絡等地方讀取
return null;
}
}
打破后的問題：為什么不建議隨意打破？
雖然這種方式簡單，但風險很大，就像我們之前討論的：
核心類可能被覆蓋：比如我們寫的java.lang.String類會被加載，替換JDK核心的String類，導致JVM啟動失敗或程序邏輯混亂；
類重復加載和類轉換異常：同一個類被不同類加載器加載，會被JVM認為是兩個不同的類，引發(fā)異常；
安全機制失效：雙親委派的安全防護被繞過，核心類可能被惡意篡改，破壞Java沙箱安全機制。
注意：實際開發(fā)中，像Tomcat、JDBC等場景打破雙親委派，并不是完全去掉父加載器邏輯，而是自定義委派順序（比如Tomcat先加載應用內的類，再委派給父加載器），是“可控的打破”，而非這種粗暴的“完全拋棄父加載器”。
七、核心知識點總結（直接記，好理解）
結合上面的內容，整理了核心知識點，直接記下來，就能扎實掌握雙親委派機制：
雙親委派機制：類加載時，先由子加載器向上委派給父加載器，父加載器能加載就用父的，都加載不了，子加載器自己加載，findClass兜底；
三大類加載器：啟動（核心類）→ 擴展（JDK擴展類）→ 應用（自己寫的類、第三方jar）；
易混點：雙親委派是類加載器的層級關系，類繼承是類與類的關系，兩者無關；
核心好處：保護核心類不被篡改，避免類重復加載；
打破方式：重寫loadClass方法，去掉向上委派父加載器的邏輯，直接調用findClass，但會有安全風險；
關鍵方法：loadClass管委派，findClass管兜底，defineClass將字節(jié)碼轉為Class對象（不可重寫）。
八、最后想說
雙親委派機制不難，難的是分清它和類繼承的區(qū)別，以及理解loadClass和findClass的分工。我剛開始學習的時候，也經常記反類加載器的順序，混淆委派邏輯和繼承邏輯，后來通過梳理流程、結合簡單的代碼示例，慢慢就吃透了。
