雙親委派模型深度解析大概每個(gè)Java開發(fā)者都經(jīng)歷過這么一幕面試官輕描淡寫地問“說說雙親委派模型”你能背出“先讓父加載器加載父加載器不行再自己加載”然后面試官追問一句“那你知道怎么打破它嗎什么場(chǎng)景需要打破”——空氣突然安靜。我當(dāng)年就是這樣被問住的。后來在幾個(gè)線上問題和中間件二次開發(fā)里反復(fù)跟類加載器打交道才把這塊真正吃透。這篇文章我想把這些年積累的東西一次性講清楚雙親委派模型到底在解決什么問題、JDK源碼里是怎么實(shí)現(xiàn)的、哪些場(chǎng)景必須打破它、以及遇到類加載相關(guān)的報(bào)錯(cuò)時(shí)怎么快速定位。不管你是剛接觸JVM的新手還是準(zhǔn)備面試的進(jìn)階開發(fā)者或者正在排查詭異的類沖突問題這篇文章都會(huì)給你一套能直接拿去用的思路。1. 雙親委派模型的設(shè)計(jì)初衷與核心機(jī)制1.1 類加載器的三層結(jié)構(gòu)先搞清楚“誰是誰”雙親委派模型不是一個(gè)孤立的概念它建立在一套固定的類加載器層級(jí)之上。絕大多數(shù)Java應(yīng)用啟動(dòng)后進(jìn)程里至少存在以下幾個(gè)類加載器類加載器負(fù)責(zé)加載什么典型路徑Bootstrap ClassLoader啟動(dòng)類加載器JDK核心類庫$JAVA_HOME/jre/lib如rt.jar、java.lang.*Platform/Extension ClassLoader擴(kuò)展類加載器JDK擴(kuò)展類$JAVA_HOME/jre/lib/ext或java.ext.dirsApplication ClassLoader應(yīng)用類加載器classpath下的項(xiàng)目類和依賴項(xiàng)目打包后的jar、classes目錄自定義ClassLoader開發(fā)者按需加載的類熱部署、加密class、網(wǎng)絡(luò)加載等有一個(gè)地方需要特別留意Bootstrap ClassLoader不是Java類它由JVM底層實(shí)現(xiàn)C編寫所以在Java代碼里你打印它的getClass()會(huì)得到null。這個(gè)細(xì)節(jié)經(jīng)常讓人困惑——你調(diào)用String.class.getClassLoader()結(jié)果是null不是沒有加載器而是它的加載器是Bootstrap。我們自己寫的自定義類加載器父加載器默認(rèn)是Application ClassLoader這是通過構(gòu)造器默認(rèn)參數(shù)實(shí)現(xiàn)的。這三層結(jié)構(gòu)是雙親委派模型的地基。沒有這個(gè)層級(jí)后面講的“向上委派”就無從談起。1.2 委派流程與核心規(guī)則一張圖勝過千言萬語雙親委派的工作流程用文字描述其實(shí)很短某個(gè)類加載器收到加載請(qǐng)求比如ClassLoader.loadClass(com.example.User)它先不自己嘗試加載而是把請(qǐng)求交給父加載器父加載器同樣不自己加載繼續(xù)向上傳遞傳到Bootstrap ClassLoader如果Bootstrap能加載說明是核心類加載完成Bootstrap加載不了往下回到Extension ClassLoader嘗試Extension也加載不了繼續(xù)回到Application ClassLoaderApplication都加載不了才輪到最開始發(fā)起請(qǐng)求的那個(gè)類加載器自己去加載最后實(shí)在找不到拋出ClassNotFoundException。這里我用了文字描述但記住一句話就夠了類加載請(qǐng)求從下往上傳遞加載嘗試從上往下進(jìn)行。我用一個(gè)生活化的例子幫助理解你在公司要申請(qǐng)一筆采購(gòu)先找部門主管父主管說這事我做不了主你找總監(jiān)父的父總監(jiān)說也不歸我管最后到VP定了。你要是能自己決定就不需要層層上報(bào)了——類加載也是這樣能者先上而且是越核心的類越優(yōu)先。這套機(jī)制的巧妙之處在于它保證了Java核心類在整個(gè)應(yīng)用生命周期中只有一個(gè)版本、只被加載一次。假如沒有雙親委派你在classpath里放了一個(gè)自己寫的java.lang.String應(yīng)用類加載器就會(huì)把它加載進(jìn)來那java.lang體系的所有類都會(huì)被替換掉整個(gè)JVM直接亂套。雙親委派從制度上杜絕了這種“貍貓換太子”的隱患。2. 源碼級(jí)視角類加載器如何“向上詢問”2.1 loadClass方法的執(zhí)行邏輯逐行拆解講完理論必須落到源碼上不然理解永遠(yuǎn)是浮的。雙親委派的核心實(shí)現(xiàn)在java.lang.ClassLoader的loadClass方法里我基于JDK 8版本的邏輯逐段說明protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 第一步檢查該類是否已經(jīng)加載過 Class? c findLoadedClass(name); if (c null) { long t0 System.nanoTime(); try { // 第二步父加載器不為null委派給父加載器 if (parent ! null) { c parent.loadClass(name, false); } else { // 父加載器為null說明直接用Bootstrap加載 c findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加載器拋出異常說明父加載不了吞掉異常繼續(xù)往下 } if (c null) { // 第三步父加載器沒有加載到調(diào)用findClass自己加載 long t1 System.nanoTime(); c findClass(name); } } if (resolve) { resolveClass(c); } return c; } }這個(gè)方法里有幾個(gè)關(guān)鍵點(diǎn)值得展開聊findLoadedClass(name)是第一步檢查。JVM維護(hù)了一份已加載類的記錄同一個(gè)類加載器不會(huì)重復(fù)加載同一個(gè)類。這個(gè)緩存機(jī)制保證了類加載的冪等性——你在程序里多次觸發(fā)同一個(gè)類的加載最終只會(huì)有一個(gè)Class對(duì)象存在。這也是為什么后面講“類隔離”時(shí)不同的類加載器可以各自加載同一個(gè)類因?yàn)樗鼈兏髯缘木彺媸仟?dú)立的。parent ! null的判斷邏輯很有意思。自定義類加載器如果不顯式傳父加載器默認(rèn)就是Application ClassLoader。而Application ClassLoader的父加載器是ExtensionExtension的父加載器邏輯上是Bootstrap。如果某個(gè)加載器的parent是nullloadClass就會(huì)走findBootstrapClassOrNull分支。catch (ClassNotFoundException e)這里有個(gè)反直覺的地方父加載器沒找到類拋出了異常子加載器在catch里什么都沒做只是吞掉異常繼續(xù)往下走。這個(gè)設(shè)計(jì)是刻意的——父加載不到類在雙親委派里是“正常情況”不需要提前暴露。最后一步findClass(name)是真正做事的地方。ClassLoader基類的findClass默認(rèn)實(shí)現(xiàn)是拋出ClassNotFoundException也就是說如果你寫自定義類加載器時(shí)只重寫loadClass而不調(diào)用super.loadClass()你就完全繞過了雙親委派機(jī)制。這在大多數(shù)場(chǎng)景下是不推薦的正確做法是重寫findClass而不是loadClass。2.2 為什么是“先緩存、再委派、后加載”很多人看源碼會(huì)有個(gè)疑問為什么先檢查緩存而不是先問父加載器順序反過來不也一樣嗎這里藏著性能考量。類加載是高頻操作一個(gè)大型應(yīng)用啟動(dòng)時(shí)要加載數(shù)千個(gè)類如果每次都走一遍完整的委派鏈路哪怕是內(nèi)存里的邏輯判斷也會(huì)帶來不必要的開銷。先用findLoadedClass看看自己這邊有沒有有就直接返回這是最快的路徑。再往下想一層緩存檢查是“自己轄區(qū)內(nèi)”的快速通道委派是“向上請(qǐng)求”findClass是“自己動(dòng)手”。這個(gè)順序也映射了類加載器之間的信任關(guān)系——先承認(rèn)現(xiàn)狀已加載的類再相信父加載器最后才相信自己。還有一個(gè)容易被忽略的細(xì)節(jié)resolve參數(shù)。loadClass(name, false)中的false表示只加載不鏈接。鏈接包含驗(yàn)證、準(zhǔn)備、解析三個(gè)階段其中解析涉及到符號(hào)引用替換為直接引用可能觸發(fā)更多類的加載。JDK里大部分觸發(fā)類加載的入口都傳false等真正需要初始化時(shí)才走完整個(gè)流程。這是JVM的懶加載策略的一部分理解這一點(diǎn)對(duì)你分析類初始化時(shí)機(jī)很有幫助。3. 打破雙親委派為什么需要、怎么打破3.1 經(jīng)典場(chǎng)景分析JDBC和SPI機(jī)制的委派困境既然雙親委派模型這么好為什么還要打破它因?yàn)殡p親委派模型有一個(gè)與生俱來的困境它只解決了核心類庫被正確加載的問題但沒有解決“核心類庫調(diào)用第三方實(shí)現(xiàn)”的問題。最經(jīng)典的就是JDBC。java.sql.DriverManager在rt.jar里由Bootstrap ClassLoader加載。而com.mysql.cj.jdbc.Driver是我們引入的第三方j(luò)ar包由Application ClassLoader加載。當(dāng)DriverManager執(zhí)行Class.forName(com.mysql.cj.jdbc.Driver)來加載驅(qū)動(dòng)時(shí)問題來了Bootstrap ClassLoader的委派鏈路上根本沒有應(yīng)用類路徑它不可能找到com.mysql.cj.jdbc.Driver。就算按照雙親委派模型一路向上傳遞應(yīng)用類加載器確實(shí)能加載這個(gè)類但調(diào)用的發(fā)起方是Bootstrap加載的核心類——核心類看不到應(yīng)用類。這里需要理解一個(gè)底層規(guī)則一個(gè)類能訪問的類受限于它的定義類加載器可見的類范圍。Bootstrap ClassLoader的可見范圍只有核心類庫所以DriverManager代碼里哪怕出現(xiàn)了應(yīng)用類路徑里的類名也不可能加載成功。為了解決這個(gè)問題JDK引入了一套SPIService Provider Interface機(jī)制和線程上下文類加載器。Java 6之后DriverManager在初始化時(shí)會(huì)通過ServiceLoader加載META-INF/services/java.sql.Driver文件里聲明的驅(qū)動(dòng)實(shí)現(xiàn)類而ServiceLoader加載這些類時(shí)使用的正是Thread.currentThread().getContextClassLoader()——線程上下文類加載器。線程上下文類加載器是什么它是每個(gè)線程都能設(shè)置和獲取的一個(gè)ClassLoader引用默認(rèn)繼承創(chuàng)建線程時(shí)的父線程上下文類加載器通常就是Application ClassLoader。它的作用就是打破“父加載器無法向下委托”的僵局把類加載請(qǐng)求“逆向”交給底層加載器來完成。它不算一種新的類加載器更像是一個(gè)傳遞通道。3.2 自定義類加載器的完整實(shí)現(xiàn)示例代碼示例是最好的講解方式。我寫一個(gè)打破雙親委派的自定義類加載器實(shí)現(xiàn)“自己先加載加載不到再給父加載器”的邏輯public class BreakParentClassLoader extends ClassLoader { private String basePath; public BreakParentClassLoader(String basePath, ClassLoader parent) { super(parent); this.basePath basePath; } Override protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 1. 先檢查自己是否已經(jīng)加載過 Class? c findLoadedClass(name); if (c ! null) { return c; } // 2. 核心類庫交給父加載器處理 if (name.startsWith(java.) || name.startsWith(javax.)) { try { c super.loadClass(name, resolve); } catch (ClassNotFoundException e) { // 核心類不存在繼續(xù)往下走 } } // 3. 自己的路徑自己加載 if (c null) { try { c findClass(name); } catch (ClassNotFoundException e) { // 自己也沒找到再嘗試父加載器 c super.loadClass(name, resolve); } } if (resolve) { resolveClass(c); } return c; } } Override protected Class? findClass(String name) throws ClassNotFoundException { String fileName basePath File.separator name.replace(., File.separatorChar) .class; File file new File(fileName); if (!file.exists()) { throw new ClassNotFoundException(name); } byte[] bytes readClassBytes(file); return defineClass(name, bytes, 0, bytes.length); } private byte[] readClassBytes(File file) { try (FileInputStream in new FileInputStream(file)) { ByteArrayOutputStream out new ByteArrayOutputStream(); byte[] buffer new byte[1024]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } return out.toByteArray(); } catch (IOException e) { throw new RuntimeException(e); } } }注意我在loadClass里加了name.startsWith(java.)的判斷。這是個(gè)非常關(guān)鍵的保護(hù)措施即使是打破雙親委派的自定義加載器也絕對(duì)不能嘗試加載java.lang等核心類庫的類。一旦自定義類加載器加載了java.*開頭的類而這個(gè)類的真實(shí)核心版本已經(jīng)由Bootstrap加載過了那么兩個(gè)不同類加載器定義的java.lang.String就會(huì)造成命名空間沖突輕則類型轉(zhuǎn)換異常重則直接拖垮JVM。這個(gè)保護(hù)策略是很多框架級(jí)類加載器比如某些Web容器的通用做法。打破雙親委派不代表徹底拋棄它——核心類庫的安全底線任何時(shí)候都不能碰。3.3 線程上下文類加載器的設(shè)置與使用前面提到線程上下文類加載器是打破雙親委派的重要工具所以單獨(dú)拿出來講講。它的API非常簡(jiǎn)單直白// 獲取當(dāng)前線程的上下文類加載器 ClassLoader cl Thread.currentThread().getContextClassLoader(); // 設(shè)置當(dāng)前線程的上下文類加載器 Thread.currentThread().setContextClassLoader(new BreakParentClassLoader(/tmp/classes, getClass().getClassLoader())); // 使用上下文類加載器加載類 Class? clazz Thread.currentThread().getContextClassLoader().loadClass(com.example.ServiceImpl);線程上下文類加載器本來只是Thread類里的一個(gè)普通字段但它承載了一個(gè)很重要的思想當(dāng)一個(gè)由高層級(jí)加載器加載的組件如DriverManager需要調(diào)用低層級(jí)加載器才能加載的實(shí)現(xiàn)類時(shí)可以借助線程上下文完成“逆向委托”。有幾點(diǎn)實(shí)踐心得值得記錄設(shè)置線程上下文類加載器后一定要記得在finally塊里恢復(fù)。特別是使用線程池的場(chǎng)景線程是復(fù)用的如果你改了某個(gè)線程的上下文類加載器而沒有恢復(fù)下一次線程執(zhí)行其他任務(wù)時(shí)TCCL已經(jīng)變了可能引發(fā)非常難排查的類加載怪異問題。ClassLoader oldCl Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(newCl); // 業(yè)務(wù)邏輯... } finally { Thread.currentThread().setContextClassLoader(oldCl); }框架代碼里到處都在用TCCL最典型的是Spring框架的類加載策略。Spring的ClassUtils、各種SPI實(shí)現(xiàn)機(jī)制、Configuration類的解析都依賴TCCL來定位和加載用戶代碼。排查框架相關(guān)類加載問題時(shí)第一反應(yīng)就應(yīng)該是把當(dāng)前線程的TCCL打印出來看看。4. 實(shí)戰(zhàn)排查與高頻問題速查4.1 三類經(jīng)典報(bào)錯(cuò)的定位思路類加載相關(guān)的問題一旦發(fā)生報(bào)錯(cuò)信息往往比較直接但真正的根因常常需要一層層剝。下面這三個(gè)是我在工作中遇到頻率最高的NoClassDefFoundError和ClassNotFoundException是兩類容易混淆的錯(cuò)誤。ClassNotFoundException是顯式拋出通常出現(xiàn)在Class.forName、loadClass、findClass等主動(dòng)加載類時(shí)NoClassDefFoundError則更隱蔽——編譯期類還在運(yùn)行期某個(gè)類文件被刪除、jar包缺失、靜態(tài)初始化失敗JVM在隱式加載類時(shí)發(fā)現(xiàn)找不到。我排查這類問題的經(jīng)驗(yàn)是不要只看報(bào)錯(cuò)的類名先確認(rèn)這個(gè)類應(yīng)該由哪個(gè)類加載器負(fù)責(zé)加載再逐個(gè)檢查對(duì)應(yīng)加載器的classpath。LinkageError及其子類NoSuchMethodError、NoClassDefFoundError是的它也是LinkageError的子類代表了更麻煩的情況同一個(gè)類被多個(gè)類加載器加載版本不一致或者同名類在不同加載器里產(chǎn)生了沖突。典型場(chǎng)景是項(xiàng)目中同時(shí)存在兩個(gè)不同版本的某個(gè)依賴jar而這兩個(gè)jar被不同的類加載器加載到了。ClassCastException也是類加載器隔離的經(jīng)典癥狀。比如你把同一個(gè)com.example.User類分別讓兩個(gè)自定義類加載器加載然后用一個(gè)加載器定義的User類型去強(qiáng)轉(zhuǎn)另一個(gè)加載器加載的User實(shí)例即使包名類名完全一樣JVM也會(huì)拋出ClassCastException。很多容器應(yīng)用“熱部署幾次后報(bào)ClassCastException”就是這個(gè)原因——新舊類加載器各自加載了一份類。4.2 類加載問題排查速查表報(bào)錯(cuò)類型常見原因定位路徑解決手段ClassNotFoundException依賴缺失、加載路徑錯(cuò)誤、SPI未注冊(cè)檢查實(shí)際生效的classpath、打印當(dāng)前classloader的URL列表補(bǔ)依賴、調(diào)整classpath、檢查SPI配置NoClassDefFoundError類文件被刪除、靜態(tài)初始化失敗、依賴沖突關(guān)注報(bào)錯(cuò)棧中最底部的Caused by修復(fù)初始化邏輯、恢復(fù)缺失文件LinkageError / NoSuchMethodError同名為多個(gè)類加載器加載、版本不一致-verbose:class看類的實(shí)際來源統(tǒng)一依賴版本、使用類隔離機(jī)制時(shí)注意兼容ClassCastException同各類被不同加載器加載通過getClass().getClassLoader()確認(rèn)加載器統(tǒng)一類加載器、避免跨加載器強(qiáng)轉(zhuǎn)排查類沖突時(shí)JVM的參數(shù)-verbose:class是最直接的幫手。加上這個(gè)參數(shù)后JVM啟動(dòng)時(shí)會(huì)打印每一個(gè)加載的類和對(duì)應(yīng)的類加載器來源。在遇到詭異的類問題時(shí)我會(huì)先加上它跑一次最小復(fù)現(xiàn)從日志里定位兩個(gè)同名類分別是什么加載器、從哪個(gè)jar加載的。4.3 高頻面試題深入解析其實(shí)很多人問的雙親委派相關(guān)問題就是把自己繞進(jìn)去的部分。這里挑幾個(gè)必考題說點(diǎn)能拿來用的回答思路?！盀槭裁匆秒p親委派”先答安全性再答唯一性。安全是指核心類庫不被應(yīng)用類覆蓋JVM核心體系不被破壞唯一性是指同一個(gè)類由同一個(gè)類加載器加載避免了重復(fù)加載和命名空間混亂?！澳懿荒茏寖蓚€(gè)同名的類同時(shí)存在”能。只要你用兩個(gè)不同的類加載器分別加載它們就是兩個(gè)完全獨(dú)立的對(duì)象。這正是很多框架做“類隔離”或“熱部署”的底層原理。但要注意這種“同名同類”不能互相賦值因?yàn)镴VM的類相等判斷不僅看類的全限定名還要看ClassLoader是否相同。“雙親委派可以完全被繞過嗎”可以。重寫loadClass不調(diào)用super.loadClass(name, resolve)就完全繞過了委派鏈。但在生產(chǎn)環(huán)境里我建議只在明確的場(chǎng)景下這么做——比如需要隔離不同版本的依賴、實(shí)現(xiàn)熱部署、或者需要加載加密的class文件。無腦打破會(huì)引入類加載順序不可控的問題排查成本極高?！盀槭裁碩omcat等Web容器要打破雙親委派”核心原因是Web應(yīng)用需要自己管理依賴的版本。不同應(yīng)用可能依賴同一個(gè)庫的不同版本如果全部交給Application類加載器統(tǒng)一加載版本沖突就無法避免。Web容器為每個(gè)應(yīng)用創(chuàng)建獨(dú)立的類加載器優(yōu)先加載應(yīng)用自身的WEB-INF/classes和WEB-INF/lib里的類實(shí)現(xiàn)“應(yīng)用之間互不干擾”。當(dāng)然容器自身核心庫和JDK基礎(chǔ)類仍然委托給上層加載器處理。5. 項(xiàng)目中的實(shí)際經(jīng)驗(yàn)與避坑心得5.1 熱部署場(chǎng)景下的類加載器管理有一個(gè)實(shí)際項(xiàng)目中踩過的坑對(duì)我的理解影響很大。當(dāng)時(shí)我們做了一套簡(jiǎn)單的熱部署機(jī)制用自定義類加載器加載某個(gè)業(yè)務(wù)模塊的jar包期望更新jar后用新的類加載器加載新版本。第一次實(shí)驗(yàn)就翻車了。更新jar后跑的還是舊邏輯。后來查了半天發(fā)現(xiàn)是因?yàn)閼?yīng)用里某個(gè)單例對(duì)象持有了舊類加載器加載的類實(shí)例新邏輯的類加載器雖然在運(yùn)行但業(yè)務(wù)代碼入口拿到的還是舊單例。復(fù)盤時(shí)總結(jié)了幾個(gè)關(guān)鍵點(diǎn)熱部署不只是“換一個(gè)類加載器”你必須把持有舊對(duì)象狀態(tài)的引用一并清理掉。類可以重新加載但運(yùn)行中的對(duì)象引用不會(huì)自己切換。設(shè)計(jì)上要保證對(duì)象狀態(tài)存放在可替換的存儲(chǔ)中或者通過接口隔離持有關(guān)系。另外頻繁創(chuàng)建類加載器會(huì)帶來元空間Metaspace的持續(xù)增長(zhǎng)。每個(gè)類加載器加載過的類元數(shù)據(jù)都保存在Metaspace里舊的類加載器如果沒有被GC回收對(duì)應(yīng)的類元數(shù)據(jù)也不會(huì)釋放。我在實(shí)踐里曾經(jīng)見過連續(xù)熱部署幾十次后Metaspace暴漲的服務(wù)。后來加了一組專門的觀察任務(wù)定期檢查類加載器數(shù)量和Metaspace使用量才把這個(gè)隱患控制住。5.2 復(fù)雜項(xiàng)目里快速判斷類歸屬的技巧最后分享一個(gè)排查類加載問題時(shí)很有用的實(shí)踐手段——寫一個(gè)簡(jiǎn)單的工具方法來打印類的加載信息。這比翻文檔管用得多public static void printClassOrigin(Class? clazz) { ClassLoader loader clazz.getClassLoader(); System.out.println(類名: clazz.getName()); System.out.println(加載器: loader); if (loader ! null) { System.out.println(加載器類型: loader.getClass().getName()); System.out.println(父加載器: loader.getParent()); if (loader instanceof URLClassLoader) { URL[] urls ((URLClassLoader) loader).getURLs(); for (URL url : urls) { System.out.println( classpath: url); } } } }當(dāng)你在報(bào)表錯(cuò)、查類版本不一致時(shí)先把這個(gè)類打出來。如果發(fā)現(xiàn)同一個(gè)類在不同環(huán)節(jié)被不同類加載器加載了問題范圍基本就鎖定了。這個(gè)方法我?guī)缀趺總€(gè)項(xiàng)目都會(huì)備一套便宜好用不需要額外工具。往回看雙親委派模型本身很簡(jiǎn)潔真正復(fù)雜的是它跟實(shí)際需求碰撞時(shí)產(chǎn)生的各種變體。理解它的關(guān)鍵不在于記住流程而在于理解它到底保護(hù)了什么、限制了什么。想通了這一點(diǎn)你寫自定義類加載器時(shí)就會(huì)知道哪些機(jī)制必須保留哪些規(guī)則可以有限度地突破——這個(gè)分寸感是類加載這片領(lǐng)域里最值錢的經(jīng)驗(yàn)。