1. 類加載機制到底在解決什么問題很多人寫Java寫了三五年對ClassLoader的印象還停留在“面試八股文”的層面背一句“雙親委托就是先讓父加載器加載父加載器加載不了自己再加載”就完事了。但真到了線上環(huán)境遇到ClassNotFoundException、NoClassDefFoundError、同一個類被加載兩次導(dǎo)致類型轉(zhuǎn)換失敗、熱部署失效、SPI機制加載不到實現(xiàn)類這些問題的時候光靠背那句話是解決不了的。這篇文章我想從一線開發(fā)的視角把雙親委托模型這件事講透。不只是講它是什么更要講它為什么這么設(shè)計、在哪些場景下會被打破、打破之后會帶來什么后果、以及我們在實際項目里應(yīng)該怎么利用或者繞開它。內(nèi)容會涉及類加載器的層次結(jié)構(gòu)、加載過程的細節(jié)、線程上下文類加載器、自定義類加載器的寫法、常見的坑和排查手段。適合有一定Java基礎(chǔ)、想真正搞明白類加載機制、或者正在被類加載相關(guān)問題困擾的開發(fā)者。先說結(jié)論性的認知雙親委托模型本質(zhì)上是一種類加載的優(yōu)先級約定它的核心目標是保證核心類庫的安全性和唯一性。但它不是鐵律Java在很多地方主動打破了它因為有些場景下死守這個模型根本沒法工作。理解“什么時候遵守、什么時候打破、為什么打破”比單純記住“先父后子”有價值得多。2. 類加載器的層次結(jié)構(gòu)與雙親委托的工作流程2.1 三層類加載器的分工JVM啟動的時候并不是只有一個類加載器在干活。從JDK 8及之前的實現(xiàn)來看大致分為三層加載器負責(zé)加載的路徑典型加載內(nèi)容啟動類加載器BootstrapJAVA_HOME/lib下的核心jar或被-Xbootclasspath指定的路徑j(luò)ava.lang.*、java.util.*等核心類擴展類加載器ExtensionJAVA_HOME/lib/ext目錄或系統(tǒng)屬性指定的路徑擴展功能的jar包應(yīng)用程序類加載器Application環(huán)境變量CLASSPATH指定的路徑我們自己寫的代碼、第三方依賴啟動類加載器比較特殊它是用本地代碼實現(xiàn)的在Java里拿不到它的引用所以String.class.getClassLoader()返回的是null。擴展類加載器和應(yīng)用程序類加載器在JDK 9之后有了變化因為模塊化系統(tǒng)的引入擴展類加載器被平臺類加載器Platform ClassLoader取代了但核心的分層思想沒變。除了這三層我們還可以自己繼承ClassLoader寫自定義加載器掛在這一層體系的下面。每一層加載器都有一個parent字段指向它的父加載器注意這個“父”不是繼承關(guān)系而是組合關(guān)系是通過構(gòu)造函數(shù)傳進去的一個引用。2.2 雙親委托的完整流程當一個類加載器收到加載請求時它不會立刻自己去加載而是按下面的順序走先檢查自己是否已經(jīng)加載過這個類如果加載過就直接返回。如果沒有把請求委托給父加載器。父加載器重復(fù)步驟1和2一直往上傳遞直到啟動類加載器。如果父加載器加載不了在自己的搜索路徑里找不到才回退給子加載器自己去加載。如果所有加載器都加載不了拋出ClassNotFoundException。用一段偽代碼來表示就是protected Class? loadClass(String name, boolean resolve) { synchronized (getClassLoadingLock(name)) { // 1. 檢查是否已加載 Class? c findLoadedClass(name); if (c null) { try { if (parent ! null) { // 2. 委托給父加載器 c parent.loadClass(name, false); } else { // 父加載器為空說明到了頂層找啟動類加載器 c findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加載器加載失敗繼續(xù)往下走 } if (c null) { // 3. 自己嘗試加載 c findClass(name); } } if (resolve) { resolveClass(c); } return c; } }這段代碼是ClassLoader.loadClass的核心邏輯理解它非常關(guān)鍵。因為后面我們要講的所有“打破雙親委托”的操作本質(zhì)上都是在重寫這個方法或者它調(diào)用的findClass方法。2.3 為什么非要“先問父加載器”這個設(shè)計背后的邏輯其實很樸素防止核心類庫被篡改。假設(shè)沒有雙親委托每個加載器都自己先加載。那我在自己的classpath下寫一個java.lang.String類里面塞一些惡意代碼。應(yīng)用程序類加載器一看哦classpath下有這個類就直接加載了。這樣一來JVM里就出現(xiàn)了兩個String類一個是啟動類加載器加載的正版一個是我偽造的盜版。程序里所有用到String的地方都可能被劫持安全性完全崩塌。有了雙親委托應(yīng)用程序類加載器收到加載java.lang.String的請求后會一路委托到啟動類加載器。啟動類加載器在自己的路徑下找到了正版的String直接返回。我偽造的那個String永遠沒有機會被加載。這就是雙親委托最核心的價值保證核心類的唯一性和安全性。另一個好處是避免重復(fù)加載。同一個類如果被不同的加載器加載JVM會認為是兩個不同的類這會導(dǎo)致instanceof判斷失敗、類型轉(zhuǎn)換異常等一堆問題。雙親委托保證了同一個類在同一個加載器體系下只會被加載一次。3. 雙親委托被打破的三種典型場景雙親委托雖然好但它不是萬能的。在某些場景下死守這個模型會導(dǎo)致功能無法實現(xiàn)所以Java在很多地方主動打破了它。理解這些“打破”的場景比記住模型本身更重要。3.1 第一次打破SPI機制與線程上下文類加載器這是最經(jīng)典的一次打破。我們以JDBC為例來說明。JDBC的核心接口java.sql.Driver定義在rt.jar里由啟動類加載器加載。但具體的驅(qū)動實現(xiàn)比如MySQL的驅(qū)動是在classpath下的第三方j(luò)ar里由應(yīng)用程序類加載器加載。問題來了DriverManager這個類在啟動類加載器加載的時候需要去加載具體的驅(qū)動實現(xiàn)。但啟動類加載器根本看不到classpath下的那些驅(qū)動jar它只能加載JAVA_HOME/lib下的東西。按照雙親委托啟動類加載器加載不了應(yīng)該回退給子加載器但問題是DriverManager的加載請求是啟動類加載器發(fā)起的它沒有“子加載器”可以回退。這就是所謂的父加載器無法訪問子加載器加載的類的問題。解決方案是引入線程上下文類加載器Thread Context ClassLoader。每個線程都有一個contextClassLoader默認是應(yīng)用程序類加載器。DriverManager在需要加載驅(qū)動實現(xiàn)的時候不再用自己的加載器而是獲取當前線程的上下文類加載器來加載。這樣就繞過了雙親委托的限制。// DriverManager中的關(guān)鍵代碼 ServiceLoaderDriver loadedDrivers ServiceLoader.load(Driver.class);ServiceLoader.load內(nèi)部就是用了線程上下文類加載器public static S ServiceLoaderS load(ClassS service) { ClassLoader cl Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); }這種“父加載器請求子加載器去加載”的行為本質(zhì)上違背了雙親委托的自下而上委托原則是一種反向委托。SPI機制、JNDI、部分XML解析實現(xiàn)都用了這種方式。3.2 第二次打破熱部署與OSGi做Web開發(fā)的同學(xué)可能用過Tomcat的熱部署功能改完代碼不用重啟就能生效。這個功能的實現(xiàn)也打破了雙親委托。按照雙親委托一個類被應(yīng)用程序類加載器加載后如果我想重新加載它必須先把舊的卸載掉。但JVM判斷一個類是否可以卸載的條件非?？量淘擃惖乃袑嵗急换厥?、該類的Class對象沒有被引用、加載該類的ClassLoader被回收。在正常的應(yīng)用運行中這些條件幾乎不可能同時滿足。Tomcat的解決方案是每個Web應(yīng)用用自己的類加載器。當需要熱部署時直接丟棄整個類加載器創(chuàng)建一個新的來加載新的類。舊的類加載器被回收后它加載的所有類也就都可以被卸載了。Tomcat的類加載器結(jié)構(gòu)大致是這樣的啟動類加載器擴展類加載器應(yīng)用程序類加載器加載Tomcat自身的類公共類加載器加載所有Web應(yīng)用共享的類每個Web應(yīng)用一個WebApp類加載器WebApp類加載器在加載類的時候會先嘗試自己加載優(yōu)先加載Web應(yīng)用自己的類加載不到再委托給父加載器。這跟標準的雙親委托順序正好相反。為什么要這樣因為Web應(yīng)用可能依賴不同版本的同一個庫如果都委托給父加載器就會導(dǎo)致版本沖突。讓每個Web應(yīng)用自己優(yōu)先加載可以做到應(yīng)用之間的隔離。OSGi的類加載器架構(gòu)更加復(fù)雜它把雙親委托變成了網(wǎng)狀結(jié)構(gòu)每個Bundle有自己的類加載器Bundle之間可以互相導(dǎo)入導(dǎo)出包。這種設(shè)計實現(xiàn)了模塊級別的熱插拔和版本隔離但復(fù)雜度也急劇上升。3.3 第三次打破自定義加載器的findClass嚴格來說這不是“打破”而是“擴展”。雙親委托的流程是loadClass方法定義的如果我們想在不破壞委托機制的前提下加載特殊來源的類可以重寫findClass方法。比如從網(wǎng)絡(luò)加載class文件、從數(shù)據(jù)庫加載、從加密文件解密后加載這些場景下我們不想改變委托順序只是想讓加載器在“自己加載”這一步有特殊的行為。這時候重寫findClass就夠了loadClass里的委托邏輯保持不變。public class NetworkClassLoader extends ClassLoader { private String baseUrl; public NetworkClassLoader(String baseUrl, ClassLoader parent) { super(parent); this.baseUrl baseUrl; } Override protected Class? findClass(String name) throws ClassNotFoundException { try { byte[] classData loadClassDataFromNetwork(name); return defineClass(name, classData, 0, classData.length); } catch (Exception e) { throw new ClassNotFoundException(name, e); } } private byte[] loadClassDataFromNetwork(String name) { // 從網(wǎng)絡(luò)獲取class文件的字節(jié)流 // 具體實現(xiàn)省略 return new byte[0]; } }這種寫法保留了雙親委托的安全性同時擴展了加載來源。實際項目中很多中間件比如某些RPC框架、規(guī)則引擎都用了這種方式來加載動態(tài)生成的類。4. 自定義類加載器的實操與關(guān)鍵細節(jié)4.1 重寫loadClass還是findClass這是寫自定義加載器時第一個要做的決策。我的建議是如果你只是想改變類的來源從網(wǎng)絡(luò)、數(shù)據(jù)庫、加密文件加載但不想改變委托順序重寫findClass。如果你想改變委托順序比如Web應(yīng)用那樣自己優(yōu)先加載重寫loadClass。如果你兩者都想改那就都重寫。重寫loadClass的時候要特別小心因為你要自己處理同步、已加載檢查、委托邏輯、解析等步驟。一個常見的錯誤是忘了加synchronized導(dǎo)致多線程環(huán)境下同一個類被加載兩次。4.2 defineClass的注意事項defineClass是把字節(jié)數(shù)組轉(zhuǎn)換成Class對象的關(guān)鍵方法。有幾個細節(jié)需要注意第一defineClass的name參數(shù)必須是類的全限定名而且必須和字節(jié)碼文件里的類名一致。如果傳錯了會拋出NoClassDefFoundError或者加載出來的類行為異常。第二defineClass只能把字節(jié)數(shù)組定義成類不能定義成接口或者枚舉。接口和枚舉在字節(jié)碼層面也是類所以實際上是可以的但要注意字節(jié)碼的格式必須正確。第三同一個類加載器不能對同一個類名調(diào)用兩次defineClass否則會拋出LinkageError。這就是為什么loadClass里要先檢查findLoadedClass。第四defineClass定義的類它的類加載器就是調(diào)用defineClass的那個加載器。這一點在排查類加載問題時非常重要。4.3 類加載器的命名空間與隔離每個類加載器都有自己的命名空間。同一個類名被不同的加載器加載在JVM里就是兩個不同的類。這既是隔離的基礎(chǔ)也是很多詭異問題的根源。舉個例子// 假設(shè)有兩個不同的類加載器loader1和loader2 Class? class1 loader1.loadClass(com.example.User); Class? class2 loader2.loadClass(com.example.User); // 下面這行會返回false System.out.println(class1 class2); // 下面這行會拋出ClassCastException Object obj class1.newInstance(); com.example.User user (com.example.User) obj;最后一行會拋異常因為class1加載的User和當前代碼里的User由應(yīng)用程序類加載器加載不是同一個類。這種問題在插件化框架、熱部署場景下非常常見。排查這類問題的思路是打印出兩個類的加載器看看是不是同一個。如果不是就要分析為什么會出現(xiàn)兩個加載器加載同一個類的情況。5. 常見問題排查與避坑經(jīng)驗5.1 ClassNotFoundException與NoClassDefFoundError的區(qū)別這兩個異常經(jīng)常被混淆但它們的含義完全不同異常觸發(fā)時機含義ClassNotFoundException加載階段加載器在搜索路徑下找不到這個類NoClassDefFoundError鏈接或初始化階段類曾經(jīng)被加載過但再次使用時找不到或者初始化失敗ClassNotFoundException通常是因為classpath配置不對、依賴缺失、類名拼寫錯誤。排查的時候先確認類名是否正確再確認對應(yīng)的jar是否在classpath下最后確認加載器的搜索路徑是否覆蓋了那個jar。NoClassDefFoundError更隱蔽一些。常見的原因有類的靜態(tài)初始化塊拋出了異常、類依賴的其他類加載失敗、同一個類被不同的加載器加載導(dǎo)致鏈接失敗。排查的時候要看異常的Caused by部分通常能找到更具體的原因。5.2 同一個類被加載兩次的排查這個問題的典型表現(xiàn)是ClassCastException而且異常信息看起來很詭異明明兩個類是同一個名字轉(zhuǎn)換卻失敗了。排查步驟在異常發(fā)生的地方打印出對象的getClass().getClassLoader()和目標的getClass().getClassLoader()看看是不是同一個加載器。如果不是往上追溯這兩個加載器分別是什么為什么會出現(xiàn)兩個加載器加載同一個類的情況。常見的原因是自定義加載器沒有正確委托給父加載器、線程上下文類加載器設(shè)置不當、多個框架各自創(chuàng)建了加載器。一個實用的技巧是在自定義加載器的loadClass方法里加日志記錄每次加載請求的類名和最終由哪個加載器加載。這樣能快速定位問題。5.3 線程上下文類加載器的坑線程上下文類加載器雖然解決了SPI的問題但它也帶來了新的坑。第一個坑是上下文類加載器被意外修改。有些框架在啟動的時候會把上下文類加載器設(shè)置成自己的加載器用完之后沒有恢復(fù)。這會導(dǎo)致后續(xù)的代碼在加載類的時候用了錯誤的加載器。第二個坑是線程池中的上下文類加載器。線程池里的線程是復(fù)用的如果提交任務(wù)的時候沒有正確設(shè)置上下文類加載器任務(wù)執(zhí)行時可能用的是上一個任務(wù)的加載器導(dǎo)致類加載混亂。我的建議是在創(chuàng)建線程或者提交任務(wù)的時候顯式地保存和設(shè)置上下文類加載器用完恢復(fù)。ClassLoader original Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(myClassLoader); // 執(zhí)行需要特定類加載器的代碼 } finally { Thread.currentThread().setContextClassLoader(original); }5.4 類加載問題的通用排查思路遇到類加載相關(guān)的問題我一般按下面的順序排查確認異常類型是ClassNotFoundException還是NoClassDefFoundError還是ClassCastException還是LinkageError。不同類型的排查方向不同。打印加載器信息用-verbose:class參數(shù)啟動JVM可以看到每個類被哪個加載器加載的詳細日志。檢查classpath確認需要的jar是否在classpath下有沒有版本沖突。檢查加載器層次確認自定義加載器的parent設(shè)置是否正確有沒有正確委托。檢查上下文類加載器確認當前線程的上下文類加載器是否符合預(yù)期。檢查類是否被多次加載用-verbose:class或者自定義加載器日志來確認。-verbose:class這個參數(shù)非常有用它會在控制臺輸出每個類的加載信息包括類名和加載器。雖然輸出量很大但配合grep能快速定位問題。6. 雙親委托在實際框架中的應(yīng)用與啟示6.1 Spring Boot的類加載器設(shè)計Spring Boot的可執(zhí)行jar包用了自定義的類加載器LaunchedURLClassLoader。它的特殊之處在于Spring Boot的jar包結(jié)構(gòu)是嵌套的依賴的jar被打包在BOOT-INF/lib目錄下而不是傳統(tǒng)的WEB-INF/lib。標準的應(yīng)用程序類加載器無法直接加載嵌套jar里的類所以Spring Boot自己寫了一個加載器來處理。LaunchedURLClassLoader繼承了URLClassLoader重寫了findClass方法能夠從嵌套的jar URL中讀取class文件。它保留了雙親委托的委托邏輯只是擴展了加載來源。這是一個很好的“擴展而非打破”的案例。6.2 從雙親委托看架構(gòu)設(shè)計雙親委托模型給我們的啟示其實超越了類加載本身。它體現(xiàn)了一種分層信任的設(shè)計思想核心層提供基礎(chǔ)能力擴展層在核心層的基礎(chǔ)上增加功能但核心層的安全性不被擴展層影響。這種思想在很多地方都有體現(xiàn)操作系統(tǒng)的內(nèi)核態(tài)和用戶態(tài)、瀏覽器的沙箱機制、微服務(wù)中的網(wǎng)關(guān)和業(yè)務(wù)服務(wù)。理解了這個思想再看雙親委托就不只是記住一個面試答案而是理解了一種通用的架構(gòu)原則。6.3 什么時候應(yīng)該打破雙親委托我的經(jīng)驗是除非有明確的隔離需求或者加載來源的特殊性否則不要打破雙親委托。打破雙親委托意味著你要自己處理類的唯一性、安全性、卸載等問題復(fù)雜度很高。只有在下面這些場景下才值得考慮需要加載不同版本的同一個類庫且它們必須在同一個JVM里共存。需要從非標準來源加載類比如網(wǎng)絡(luò)、數(shù)據(jù)庫、動態(tài)生成的字節(jié)碼。需要實現(xiàn)熱部署能夠卸載已經(jīng)加載的類。需要實現(xiàn)模塊隔離不同模塊之間的類不能互相訪問。如果只是普通的業(yè)務(wù)開發(fā)用標準的應(yīng)用程序類加載器就夠了不要沒事找事去寫自定義加載器。6.4 一個容易忽略的細節(jié)數(shù)組類的加載器數(shù)組類比較特殊它沒有對應(yīng)的class文件是由JVM在運行期動態(tài)創(chuàng)建的。數(shù)組類的加載器是它的元素類型的加載器。如果元素類型是基本類型數(shù)組類沒有加載器。這個細節(jié)在排查類加載問題時可能會遇到。比如你看到某個數(shù)組類的加載器是null不要驚訝先看看它的元素類型是什么。String[] arr new String[0]; // 輸出null因為String由啟動類加載器加載 System.out.println(arr.getClass().getClassLoader()); int[] intArr new int[0]; // 輸出null基本類型數(shù)組沒有加載器 System.out.println(intArr.getClass().getClassLoader());我在實際項目中排查過一個詭異的問題某個框架在判斷類是否相同時沒有考慮數(shù)組類的特殊情況導(dǎo)致數(shù)組類型的判斷出錯。后來在比較類的時候加了對數(shù)組類型的特殊處理才解決。這種細節(jié)平時不會注意到但真遇到了會很頭疼。6.5 類加載器的性能考量自定義類加載器如果實現(xiàn)不當會帶來性能問題。最常見的問題是重復(fù)加載每次請求都重新加載類而不是先檢查緩存。loadClass方法里的findLoadedClass就是用來做緩存的如果重寫的時候漏掉了這一步性能會急劇下降。另一個問題是鎖競爭。loadClass方法里的synchronized塊是以類名為鎖的如果大量線程同時加載不同的類鎖競爭不會太嚴重。但如果加載同一個類就會串行化。在并發(fā)量高的場景下可以考慮用ConcurrentHashMap來做加載緩存減少鎖的持有時間。還有一個容易被忽略的點是類加載器的內(nèi)存占用。每個類加載器都會持有它加載的所有類的引用如果創(chuàng)建了大量類加載器而不釋放會導(dǎo)致內(nèi)存泄漏。熱部署場景下尤其要注意這一點確保舊的類加載器能夠被GC回收。7. 寫在最后的一些個人體會雙親委托模型這個知識點我面試過別人也被別人面試過。我發(fā)現(xiàn)一個現(xiàn)象很多人能背出定義但問幾個追問就露餡了。比如“為什么要有雙親委托”、“什么場景下會打破它”、“打破之后怎么保證安全”能答上來的人不多。我的建議是學(xué)這個知識點的時候不要只盯著ClassLoader那幾個方法看。試著從JVM整體設(shè)計的角度去理解類加載器是JVM與外部世界的邊界雙親委托是這個邊界上的安全策略。理解了邊界和安全策略的關(guān)系很多設(shè)計決策就順理成章了。另外如果你正在做中間件、框架、插件化相關(guān)的開發(fā)類加載機制是繞不過去的。我踩過的坑包括自定義加載器忘了設(shè)parent導(dǎo)致核心類加載失敗、線程上下文類加載器被框架改掉導(dǎo)致SPI加載不到實現(xiàn)、熱部署時舊的類加載器沒釋放導(dǎo)致內(nèi)存泄漏。每一個坑都花了不少時間排查但排查完之后對類加載的理解就深了一層。最后分享一個實用的小技巧在IDE里調(diào)試類加載問題時可以在ClassLoader.loadClass方法上下斷點觀察加載請求的傳遞路徑。雖然會斷到很多次但配合條件斷點只在加載特定類時停下能很直觀地看到雙親委托的實際執(zhí)行過程。這比看多少篇文章都管用。