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