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