很多Java開發(fā)者寫了好幾年業(yè)務(wù)代碼第一次被JVM的類加載子系統(tǒng)“教育”通常是從某個(gè)詭異報(bào)錯(cuò)開始的ClassNotFoundException、NoClassDefFoundError或者“同一個(gè)類在兩個(gè)ClassLoader里長得不一樣”。我第一次真正理解ClassLoader是幫人排查一個(gè)明明classpath里什么都有、啟動(dòng)卻找不到類的線上問題折騰到凌晨才發(fā)現(xiàn)是兩個(gè)類加載器各加載了一份類。從那一刻起我意識(shí)到類加載子系統(tǒng)不是面試題里的紙面概念而是每個(gè)JVM應(yīng)用都要走一遍的“字節(jié)碼入職流水線”。這篇文章把JVM類加載子系統(tǒng)拆開講透它接收什么、產(chǎn)出什么加載、鏈接、初始化三個(gè)階段到底干了什么事三個(gè)內(nèi)置類加載器和雙親委派機(jī)制為什么這么設(shè)計(jì)以及怎么手寫一個(gè)自定義類加載器來做加密加載和模擬熱部署。最后我會(huì)把ClassNotFoundException和NoClassDefFoundError的區(qū)別、Class.forName與loadClass的差異這些高頻問題一起清一遍適合正在學(xué)JVM的開發(fā)者也適合準(zhǔn)備面試或者排查運(yùn)行時(shí)類加載問題的人。1. 類加載子系統(tǒng)在整臺(tái)JVM里的“工位”輸入、輸出與全程數(shù)據(jù)流1.1 它到底接收什么、產(chǎn)出什么類加載子系統(tǒng)的職責(zé)簡單說就是一句話“把class文件里的二進(jìn)制字節(jié)流變成JVM運(yùn)行時(shí)可以直接使用的Class對(duì)象?！彼皇菆?zhí)行引擎并不知道方法內(nèi)部怎么跑它也不管對(duì)象實(shí)例怎么創(chuàng)建。它只負(fù)責(zé)“把一個(gè)類從無到有地立起來”。它接收的輸入是類的全限定名比如com.example.demo.UserService和對(duì)應(yīng)的二進(jìn)制字節(jié)流。這個(gè)字節(jié)流不一定來自磁盤上的.class文件也可以是jar包、網(wǎng)絡(luò)傳輸、動(dòng)態(tài)生成代理類、JSP編譯產(chǎn)物、甚至加密后的class字節(jié)。JVM規(guī)范對(duì)“從哪里拿class”沒有硬性要求只要你給它字節(jié)流。它輸出的結(jié)果有兩塊一塊是方法區(qū)HotSpot里對(duì)應(yīng)元空間里的類元數(shù)據(jù)包括字段結(jié)構(gòu)、方法簽名、常量池、方法字節(jié)碼這些另一塊是堆內(nèi)存里的java.lang.Class對(duì)象。注意每個(gè)被加載的類都會(huì)在堆里有一個(gè)對(duì)應(yīng)的Class對(duì)象它是程序通過反射訪問類元數(shù)據(jù)的入口也是getClass()返回的東西。這兩塊要分清楚類元數(shù)據(jù)可以理解為“檔案”Class對(duì)象是“檔案的窗口”。實(shí)例對(duì)象userService在初始化時(shí)創(chuàng)建它的類信息引用指向Class對(duì)象Class對(duì)象引用指向方法區(qū)里的元數(shù)據(jù)。很多人把Class對(duì)象和類元數(shù)據(jù)混在一起一旦后面講到元空間OOM和類卸載就會(huì)繞暈。1.2 一個(gè)類的完整“入職”時(shí)間線把整個(gè)過程按時(shí)間線排開大概是這樣的代碼里第一次出現(xiàn)new UserService()或者訪問了某個(gè)類的靜態(tài)字段/靜態(tài)方法。JVM檢查類是否已經(jīng)被加載。沒加載就交給類加載子系統(tǒng)。類加載子系統(tǒng)通過全限定名獲取二進(jìn)制字節(jié)流完成“加載”。加載完成后進(jìn)入“鏈接”驗(yàn)證字節(jié)碼合法性、給靜態(tài)變量分配默認(rèn)值、把符號(hào)引用替換成直接引用。鏈接完成后進(jìn)入“初始化”執(zhí)行clinit方法給靜態(tài)變量賦真實(shí)值、執(zhí)行靜態(tài)代碼塊。類加載完成JVM開始真正執(zhí)行new字節(jié)碼在堆上創(chuàng)建實(shí)例。這里有個(gè)重要細(xì)節(jié)類加載的三個(gè)階段——“加載、鏈接、初始化”——是嚴(yán)格按順序開始的但鏈接里的“解析”不是必須等到所有驗(yàn)證和準(zhǔn)備都做完才開始。JVM規(guī)范允許解析被延遲甚至在某個(gè)類已經(jīng)開始初始化之后才解析它的部分符號(hào)引用這是為了支持動(dòng)態(tài)語言綁定等高級(jí)場景。所以面試?yán)锶绻粏柕健敖馕鲆欢òl(fā)生在初始化之前嗎”答案是不一定。還有一個(gè)容易被忽略的點(diǎn)什么時(shí)候會(huì)觸發(fā)加載JVM規(guī)范用的是“首次主動(dòng)使用”而不是“首次出現(xiàn)”。寫了一百處new UserService()只有第一次執(zhí)行到它時(shí)才觸發(fā)加載和初始化。這也是后面講“被動(dòng)引用”的底層邏輯。2. 加載與鏈接之間的細(xì)節(jié)驗(yàn)證、準(zhǔn)備、解析為什么容易被忽略很多人把“加載”和“類加載”混為一談其實(shí)“加載”只是整個(gè)流程里最前置的一步。加載階段做的事情是通過全限定名獲取二進(jìn)制字節(jié)流、把字節(jié)流轉(zhuǎn)換成方法區(qū)數(shù)據(jù)結(jié)構(gòu)、在堆里生成Class對(duì)象。真正決定一個(gè)類“能不能被安全使用”的是接下來的鏈接階段。鏈接包含三個(gè)子步驟驗(yàn)證、準(zhǔn)備、解析。這三個(gè)步驟不像加載那樣有炫酷的ClassLoader參與所以經(jīng)常被跳過但線上很多詭異的類加載報(bào)錯(cuò)恰恰是這三個(gè)環(huán)節(jié)出的問題。2.1 驗(yàn)證階段在攔什么驗(yàn)證的目標(biāo)就一句話防止惡意或不完整的字節(jié)碼破壞JVM運(yùn)行時(shí)。字節(jié)碼不是只能由javac生成任何人都可以手工構(gòu)造。所以JVM必須驗(yàn)證字節(jié)碼的每一個(gè)細(xì)節(jié)。規(guī)范要求的驗(yàn)證包括四類文件格式驗(yàn)證、元數(shù)據(jù)驗(yàn)證、字節(jié)碼驗(yàn)證、符號(hào)引用驗(yàn)證。文件格式驗(yàn)證檢查魔數(shù)是不是0xCAFEBABE、主次版本號(hào)是否在JVM支持的范圍內(nèi)元數(shù)據(jù)驗(yàn)證檢查這個(gè)類是否有父類、是否繼承了不該繼承的final類、抽象方法是否有實(shí)現(xiàn)字節(jié)碼驗(yàn)證對(duì)方法體的指令流做數(shù)據(jù)流分析確保操作數(shù)棧的類型不會(huì)出問題符號(hào)引用驗(yàn)證發(fā)生在解析階段確認(rèn)類確實(shí)能訪問到引用的符號(hào)。給你一個(gè)直觀的例子如果你用javap -c看編譯后的class會(huì)發(fā)現(xiàn)方法里大量的invokevirtual、getstatic指令后面跟著常量池索引。如果手工篡改字節(jié)碼把一個(gè)本該加載字符串的位置改成加載一個(gè)對(duì)象引用類型就對(duì)不上字節(jié)碼驗(yàn)證階段直接失敗拋出VerifyError。這個(gè)錯(cuò)誤我見過不少大多發(fā)生在字節(jié)碼增強(qiáng)框架比如那些AOP代理工具版本不兼容時(shí)。排查建議看到j(luò)avalang.VerifyError先檢查依賴?yán)镒鲎止?jié)碼增強(qiáng)的庫和JDK版本是否匹配不要一上來就懷疑業(yè)務(wù)代碼。2.2 準(zhǔn)備階段給靜態(tài)變量發(fā)的“默認(rèn)工資”準(zhǔn)備階段是為靜態(tài)變量分配內(nèi)存并設(shè)置默認(rèn)值的階段。重點(diǎn)這里設(shè)置的是默認(rèn)值不是代碼里寫的初值。舉個(gè)例子public class Person { static int age 30; static final String name Tom; }在準(zhǔn)備階段age的值是0不是30。name因?yàn)槭蔷幾g期常量static final且值在編譯期確定會(huì)直接被賦成“Tom”它不進(jìn)clinit方法里賦值這是準(zhǔn)備階段唯一的例外。age 30這個(gè)動(dòng)作會(huì)被javac收集到clinit方法里等初始化階段執(zhí)行。這個(gè)過程理解透了遇到“靜態(tài)字段的值好端端變成0/null”的詭異問題就能快速定位大概率類還沒走到初始化階段或者初始化由于異常被中斷了。之前我排查過一個(gè)案例一個(gè)工具類里有個(gè)靜態(tài)Map運(yùn)行時(shí)一直是null后來發(fā)現(xiàn)是另一個(gè)線程先觸發(fā)了類初始化但靜態(tài)代碼塊里拋了異常導(dǎo)致clinit失敗之后所有線程拿到的都是“半初始化”的狀態(tài)。2.3 解析符號(hào)引用到直接引用別小看這張“地圖”解析階段做的事是把常量池里的符號(hào)引用替換為直接引用。符號(hào)引用是什么可以理解為一串“字面地址”比如類名com/example/Service、字段描述符java/lang/String、方法名sayHelloJVM看到這些符號(hào)還不能直接干活必須找到它們對(duì)應(yīng)的真實(shí)內(nèi)存地址或運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)才能執(zhí)行指令。直接引用在HotSpot里通常是指向方法區(qū)里相關(guān)數(shù)據(jù)的指針、字段偏移量或者句柄。之所以叫“直接”是因?yàn)镴VM拿到它之后不需要再做任何查表換算直接用就行。解析最常發(fā)生在哪個(gè)指令上invokevirtual。JVM在執(zhí)行invokevirtual時(shí)面對(duì)的是一個(gè)接口方法或虛方法需要根據(jù)實(shí)際對(duì)象類型做動(dòng)態(tài)分派所以解析過程還會(huì)引入方法表查找。這也是為什么動(dòng)態(tài)代理會(huì)產(chǎn)生額外的性能成本——每個(gè)代理方法調(diào)用都要走方法查找與解析。有一個(gè)實(shí)戰(zhàn)細(xì)節(jié)如果一個(gè)類在鏈接階段解析失敗錯(cuò)誤記錄下來后續(xù)訪問同類引用會(huì)直接拋NoClassDefFoundError或IllegalAccessError。所以要分辨“類文件找不到”和“類文件存在但解析不了”后者往往更隱蔽因?yàn)闀?huì)拿著一個(gè)完整的類路徑去排查結(jié)果發(fā)現(xiàn)那個(gè)類在包里好好的。3. 初始化階段真正執(zhí)行static邏輯的時(shí)刻加載、鏈接都完成之后類還處于“圖紙階段”——變量都是默認(rèn)值靜態(tài)字段沒有真正賦初始值。初始化階段執(zhí)行clinit方法才把靜態(tài)初始化塊和靜態(tài)變量賦初值這些代碼真正跑一遍。clinit是類初始化方法不是構(gòu)造函數(shù)。它由javac生成收集所有靜態(tài)變量賦值動(dòng)作和靜態(tài)代碼塊按它們?cè)谠创a里出現(xiàn)的順序合并而成。注意實(shí)例構(gòu)造器是init類初始化是clinit兩者完全不一樣。3.1 觸發(fā)初始化的六種主動(dòng)引用到底哪些情況會(huì)觸發(fā)類初始化JVM規(guī)范列得很明確歸納成六類new一個(gè)類的實(shí)例創(chuàng)建對(duì)象是直接訪問一個(gè)類的“實(shí)體”必須初始化。訪問類的靜態(tài)字段getstatic或給靜態(tài)字段賦值putstatic如果該字段不是編譯期常量。編譯期常量的值在編譯后直接寫進(jìn)使用方代碼里根本不需要訪問定義類。調(diào)用類的靜態(tài)方法invokestatic。對(duì)類進(jìn)行反射調(diào)用比如Class.forName(com.example.User)默認(rèn)會(huì)執(zhí)行初始化注意Class.forName(name, initialize, loader)有一個(gè)參數(shù)控制是否初始化默認(rèn)initializetrue。初始化類時(shí)如果它的父類還沒初始化先觸發(fā)父類初始化。這里注意父類先于子類初始化。程序入口類也就是包含main方法的那個(gè)類JVM啟動(dòng)時(shí)會(huì)先初始化它。直接看到這里可能覺得很簡單但考察點(diǎn)是“被動(dòng)引用”。比如通過子類引用父類的靜態(tài)字段只會(huì)觸發(fā)父類的初始化子類不初始化。看這段class Parent { static int value 42; static { System.out.println(Parent init); } } class Child extends Parent { static { System.out.println(Child init); } } public static void main(String[] args) { System.out.println(Child.value); }輸出是“Parent init”和42沒有“Child init”。為什么因?yàn)関alue定義在父類訪問它的字節(jié)碼是getstatic Parent.valueJVM只需要確保Parent已初始化并不會(huì)因此去初始化Child。類似的Parent[] arr new Parent[10]創(chuàng)建的是數(shù)組對(duì)象初始化一個(gè)“數(shù)組類”不會(huì)觸發(fā)Parent初始化。這些“看起來會(huì)但實(shí)際不會(huì)”的場景是最容易在面試?yán)锓嚨摹?.2clinit的三個(gè)容易被忽視的坑第一個(gè)坑線程安全。JVM保證一個(gè)類的clinit方法在多線程環(huán)境下只被執(zhí)行一次。當(dāng)多個(gè)線程同時(shí)首次觸發(fā)這個(gè)類的初始化時(shí)只有一個(gè)線程會(huì)執(zhí)行clinit其他線程阻塞等待。如果執(zhí)行clinit的線程陷進(jìn)去了——比如靜態(tài)代碼塊里死循環(huán)、長時(shí)間持鎖、發(fā)起網(wǎng)絡(luò)請(qǐng)求——其他所有使用這個(gè)類的線程全部卡住表現(xiàn)就是應(yīng)用“假死”。第二個(gè)坑異常中斷。clinit如果拋出異常JVM會(huì)給首次捕捉到這個(gè)異常的線程拋ExceptionInInitializerError并且把這個(gè)類標(biāo)記為“初始化失敗”。下次其他線程再訪問這個(gè)類不會(huì)再嘗試初始化而是直接拋NoClassDefFoundError。這個(gè)問題非常隱蔽因?yàn)槿罩纠镏粫?huì)看到第一次的異常堆棧后面的NoClassDefFoundError很容易誤導(dǎo)人往“類缺失”方向排查。第三個(gè)坑父類先初始化但接口不一定。初始化子類之前父類一定先初始化這是強(qiáng)約束。但接口的初始化規(guī)則不一樣接口初始化時(shí)并不要求父接口先完成初始化除非子接口在運(yùn)行中使用到了父接口的static字段。這是因?yàn)榻涌诶锏撵o態(tài)字段一旦被引用就意味著真的需要訪問該接口的成員這時(shí)才初始化對(duì)應(yīng)接口。實(shí)戰(zhàn)中還有一個(gè)小坑靜態(tài)字段初始化順序。看這段public class Order { static { count 10; // 這里count已經(jīng)被賦值但還看不到它的“最終初值” // 因?yàn)楹竺娌艌?zhí)行 static int count 5; } static int count 5; }靜態(tài)代碼塊里給count 10之后緊接著的static int count 5;還會(huì)再覆蓋一次最終結(jié)果永遠(yuǎn)是5。所以在靜態(tài)代碼塊里讀靜態(tài)字段前心里要有一張“源碼順序執(zhí)行”的流程圖不然很容易寫出邏輯看似對(duì)、結(jié)果全錯(cuò)的初始化代碼。4. 類加載器的三層模型與雙親委派誰是誰的爸爸上面講的加載、鏈接、初始化屬于“同類的一生”現(xiàn)在換到另一個(gè)維度這個(gè)類到底是由誰加載進(jìn)來的。JVM里的類加載器不是只有一個(gè)而是一個(gè)層級(jí)體系。4.1 三個(gè)內(nèi)置類加載器的管轄范圍JDK 8與JDK 9差異JVM預(yù)置了三個(gè)類加載器從頂層到底層啟動(dòng)類加載器Bootstrap ClassLoader負(fù)責(zé)加載JDK核心類比如java.lang.String、java.lang.Object、java.util.*。它由C實(shí)現(xiàn)不是java.lang.ClassLoader的子類。JDK 8里加載JAVA_HOME/lib下被JVM識(shí)別的類JDK 9之后由于模塊化它加載的是java.base等基礎(chǔ)模塊。擴(kuò)展類加載器JDK 8叫ExtensionJDK 9后叫平臺(tái)類加載器PlatformJDK 8里加載JAVA_HOME/lib/ext下的jar包以及被java.ext.dirs指定的目錄。JDK 9以后Java SE標(biāo)準(zhǔn)類庫被極度模塊化平臺(tái)類加載器負(fù)責(zé)加載的是java.sql、java.xml、java.logging這些“非基礎(chǔ)但屬于平臺(tái)”的模塊。應(yīng)用程序類加載器AppClassLoader加載classpath下的用戶類也就是我們平時(shí)的com.example這類業(yè)務(wù)代碼。它是ClassLoader類的子類在sun.misc.Launcher內(nèi)部創(chuàng)建。JDK 9之后最大的變化就是Extension被替換成Platform。面試和工作中如果看到ExtClassLoader的舊資料要知道那是JDK 8的寫法到了JDK 17還照搬舊概念很容易踩坑。4.2 雙親委派執(zhí)行鏈路與loadClass源碼真相雙親委派機(jī)制定義很簡潔當(dāng)一個(gè)類加載器收到類加載請(qǐng)求時(shí)它不會(huì)自己先去加載而是把這個(gè)請(qǐng)求委托給父類加載器。父類加載器再委托給自己的父類加載器直到啟動(dòng)類加載器。如果父類加載不了子加載器才自己嘗試加載。這里說的“父子關(guān)系”不是繼承關(guān)系而是組合關(guān)系。每個(gè)類加載器實(shí)例內(nèi)部持有parent字段指向自己的父加載器?？碕DK的經(jīng)典實(shí)現(xiàn)邏輯JDK 8的AppClassLoader、ExtClassLoader都沿用了這套模板protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 1. 檢查這個(gè)類是不是已經(jīng)加載過了 Class? c findLoadedClass(name); if (c null) { try { // 2. 有父加載器先讓父加載器加載 if (parent ! null) { c parent.loadClass(name, false); } else { // 3. 沒有父加載器說明是頂層交給啟動(dòng)類加載器 c findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加載器都沒找到說明這個(gè)類不在父的管轄范圍 } if (c null) { // 4. 父加載不了自己來 c findClass(name); } } if (resolve) { resolveClass(c); } return c; } }注意第1步先查重。findLoadedClass檢查這個(gè)類在當(dāng)前類加載器里是不是已經(jīng)加載過。如果已經(jīng)加載直接返回不會(huì)重復(fù)加載。這是JVM保證類加載“一次”的重要機(jī)制。另外注意loadClass整體是同步的鎖對(duì)象是“類加載鎖”。這也是為了并發(fā)安全防止同一個(gè)類加載器并發(fā)加載同一個(gè)類時(shí)出現(xiàn)兩份Class對(duì)象。4.3 為什么這么設(shè)計(jì)類唯一性、安全沙箱與“爸爸優(yōu)先”雙親委派不是拍腦袋定的它解決三個(gè)核心問題。第一個(gè)是避免類的重復(fù)加載。如果每個(gè)類加載器都自己從頭加載java.lang.String你的代碼里可能會(huì)出現(xiàn)兩個(gè)“String類”并存各自的equals判定都不一樣整個(gè)類型系統(tǒng)直接崩潰。第二個(gè)是安全。因?yàn)槊繉诱?qǐng)求都先向上委托用戶自定義的類加載器根本接觸不到核心類無法用偷換java.lang包的方式包藏惡意代碼。啟動(dòng)類加載器只會(huì)加載信任目錄下的核心類這種“爸爸先試”的路徑天然形成一道安全沙箱。第三個(gè)是類唯一性。JVM里判斷兩個(gè)類是不是同一個(gè)“類”不僅看全限定名是否相同還要看它們是否由同一個(gè)類加載器加載。即使同一個(gè)class文件被兩個(gè)不同的類加載器各加載一次它們也是兩個(gè)不同的Class對(duì)象。這個(gè)原理在后面講類卸載和熱部署時(shí)是核心也是無數(shù)框架bug的根源。一個(gè)經(jīng)典測試兩個(gè)自定義加載器分別加載同一個(gè)Hello.class然后用aClass.isInstance(instanceFromB)判斷返回false。不是“長得像”就等于同一個(gè)類在JVM眼里加載器不同就是“不同種族”。5. 雙親委派被破壞的典型場景SPI與熱部署雙親委派不是萬能的有些場景必須“逆行”才能工作。最典型的就是Java的SPI機(jī)制Service Provider Interface以及熱部署、OSGi這類模塊化容器。5.1 線程上下文類加載器SPI的“借道”先想一個(gè)問題數(shù)據(jù)庫驅(qū)動(dòng)接口定義在java.sql.Driver這個(gè)接口由啟動(dòng)類加載器加載。但驅(qū)動(dòng)實(shí)現(xiàn)類比如某個(gè)廠商寫的客戶端Driver是放在classpath里的jar包按雙親委派路徑啟動(dòng)類加載器根本看不到它AppClassLoader又因?yàn)橛小鞍职謨?yōu)先”的規(guī)則而不會(huì)主動(dòng)去加載。于是DriverManager在加載驅(qū)動(dòng)時(shí)不能靠Class.forName(驅(qū)動(dòng)類名)這種默認(rèn)雙親委派的方式因?yàn)榫€程上下文類加載器不在默認(rèn)委托鏈上它調(diào)用了Thread.currentThread().getContextClassLoader()拿到線程上下文類加載器然后由這個(gè)加載器去加載classpath里的數(shù)據(jù)庫驅(qū)動(dòng)實(shí)現(xiàn)類。這個(gè)上下文加載器默認(rèn)是AppClassLoader所以能加載用戶jar里的類。這類場景總結(jié)為核心類庫在頂層加載器里但需要加載底層加載器才可見的實(shí)現(xiàn)類。JDK里很多SPI擴(kuò)展點(diǎn)都用了這個(gè)模式比如JNDI、XML解析器、數(shù)據(jù)庫驅(qū)動(dòng)等。面試時(shí)如果被問“哪里打破了雙親委派”SPI 線程上下文類加載器是答案榜第一名。5.2 熱部署/模塊化打破雙親委派的代價(jià)熱部署的核心需求是同一個(gè)類名在舊版本class被替換后能重新加載一份“新版本”。如果走雙親委派AppClassLoader加載了com.example.Task之后后面改成新代碼findLoadedClass一查發(fā)現(xiàn)已經(jīng)加載過直接返回舊版Class新代碼根本不會(huì)生效。所以Tomcat、OSGi這類容器設(shè)計(jì)了更復(fù)雜的類加載器體系。Tomcat的每個(gè)Web應(yīng)用都有自己的WebAppClassLoader放棄“永遠(yuǎn)先給父加載器”的嚴(yán)格規(guī)則優(yōu)先加載自身WEB-INF/classes目錄下的類實(shí)現(xiàn)應(yīng)用間的類隔離和熱部署。OSGi更進(jìn)一步每個(gè)Bundle模塊都有獨(dú)立的類加載器類可見性由導(dǎo)入/導(dǎo)出包配置控制完全自定義了加載順序。這里的代價(jià)很明顯類加載順序不再是線性委托而是變成一張復(fù)雜的依賴圖。一旦多個(gè)模塊里有同名類就會(huì)產(chǎn)生“類沖突”問題——兩個(gè)Bundle各自加載出一份同名的類互相強(qiáng)轉(zhuǎn)直接報(bào)ClassCastException而且異常信息看起來莫名其妙“A cannot be cast to A”。業(yè)界很多框架的版本沖突問題根源都在這。6. 動(dòng)手寫一個(gè)自定義類加載器從加密class到模擬熱替換雙親委派說得再多不如自己寫一個(gè)類加載器。自定義類加載器的常見需求有兩個(gè)一是從特殊來源加載字節(jié)碼比如文件加密、網(wǎng)絡(luò)傳輸二是繞過父加載實(shí)現(xiàn)“同名類重新加載”來模擬熱部署。6.1 重寫 findClass 而不是 loadClass自定義類加載器最推薦的做法是繼承ClassLoader重寫findClass方法。為什么重寫findClass而不是重寫loadClass因?yàn)镴DK源碼里的loadClass已經(jīng)實(shí)現(xiàn)了完整的雙親委派邏輯先查已加載、再找父加載器、父找不到才調(diào)findClass。我們只需要在“父加載器沒找到”的兜底階段告訴JVM“從哪些自定義位置獲取字節(jié)流”剩下的事JVM幫你處理。如果直接重寫loadClass等于把整條雙親委派鏈親手拆掉一般只有寫容器框架才需要這種操作。標(biāo)準(zhǔn)模板長這樣public class FileClassLoader extends ClassLoader { private final String path; public FileClassLoader(String path) { this.path path; } Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] bytes loadClassData(name); if (bytes null) { throw new ClassNotFoundException(name); } // defineClass 是 ClassLoader 提供的方法把字節(jié)數(shù)組變成 Class 對(duì)象 return defineClass(name, bytes, 0, bytes.length); } private byte[] loadClassData(String name) { String fileName path / name.replace(., /) .class; try (InputStream in new FileInputStream(fileName); 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) { e.printStackTrace(); return null; } } }核心就兩個(gè)方法loadClassData負(fù)責(zé)拿到字節(jié)數(shù)組defineClass負(fù)責(zé)把字節(jié)數(shù)組轉(zhuǎn)換成Class對(duì)象。defineClass是ClassLoader里的一個(gè)protected方法不需要自己實(shí)現(xiàn)直接調(diào)用即可。6.2 加密字節(jié)碼加載的實(shí)戰(zhàn)例子如果class文件被加密過普通ClassLoader讀出來的是一堆亂碼字節(jié)碼驗(yàn)證直接失敗。解決辦法就是在loadClassData里拿到原始字節(jié)流后、調(diào)用defineClass之前先做一次解密。實(shí)際項(xiàng)目中通常用AES或者異或做混淆。簡單起見用一個(gè)異或加密示意public class EncryptClassLoader extends ClassLoader { private static final byte KEY 0x5A; private final String classPath; public EncryptClassLoader(String classPath) { this.classPath classPath; } Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] encrypted loadClassData(name); byte[] decrypted new byte[encrypted.length]; for (int i 0; i encrypted.length; i) { decrypted[i] (byte) (encrypted[i] ^ KEY); } return defineClass(name, decrypted, 0, decrypted.length); } }這里的邏輯很簡單加密時(shí)對(duì)class文件的每個(gè)字節(jié)異或一個(gè)KEY解密時(shí)再異或一次。真實(shí)防破解當(dāng)然不會(huì)用這么弱的方式但思路是通用的——在字節(jié)流進(jìn)入defineClass之前你有充分的自由度對(duì)字節(jié)做處理。很多商業(yè)軟件把整個(gè)class加密再用native方法在啟動(dòng)時(shí)解密骨架都是這樣。這里提醒一句加密class只能增加逆向門檻不能做到絕對(duì)安全。因?yàn)镴VM最終還是要拿到明文字節(jié)碼只要進(jìn)程在運(yùn)行字節(jié)碼就在內(nèi)存里可以被dump。做版權(quán)保護(hù)要考慮的是一整套方案別指望一個(gè)加密加載器解決所有問題。6.3 同名類“熱替換”的簡易Demo與局限模擬熱部署的最簡單做法不是修改父加載邏輯而是每次創(chuàng)建一個(gè)新的類加載器實(shí)例去加載同名類。因?yàn)镴VM判斷“同類”時(shí)類加載器也是標(biāo)準(zhǔn)之一。新的類加載器是新對(duì)象它的findLoadedClass緩存是空的所以同一個(gè)class文件能被再加載一遍。示例邏輯public class HotSwapDemo { public static void main(String[] args) throws Exception { while (true) { FileClassLoader loader new FileClassLoader(./classes); Class? clazz loader.loadClass(demo.Hello); Object instance clazz.newInstance(); clazz.getMethod(say).invoke(instance); Thread.sleep(3000); } } }只要我在./classes/demo/Hello.class里改了內(nèi)容并重新編譯下一輪循環(huán)就會(huì)加載出新的Class對(duì)象。但這里有個(gè)關(guān)鍵局限舊對(duì)象還在堆里新的類和舊的對(duì)象之間沒有任何血緣關(guān)系。如果嘗試把舊對(duì)象強(qiáng)轉(zhuǎn)成新加載的類類型結(jié)果是ClassCastException。真正的熱部署框架要復(fù)雜得多需要把對(duì)象狀態(tài)遷移、線程上下文切換、資源清理都處理干凈。所以“熱替換”在Demo層面很容易在生產(chǎn)層面極難。如果你只是在本地實(shí)驗(yàn)理解這個(gè)概念就夠了如果要上生產(chǎn)系統(tǒng)老老實(shí)實(shí)用成熟的容器和框架別自己造熱部署輪子。7. 類加載相關(guān)的疑難雜癥與高頻辨析最后把類加載子系統(tǒng)里最容易混淆的幾個(gè)問題一次性講透這些也是面試和日常排查中最常遇到的點(diǎn)。7.1 ClassNotFoundException 與 NoClassDefFoundError 到底差在哪這兩個(gè)異常名字接近但本質(zhì)完全不同。ClassNotFoundException是一個(gè)受檢異常checked exception通常由Class.forName()、ClassLoader.loadClass()這類顯式加載方法拋出表示“你要我加載的類我在指定加載器里找不到”。它發(fā)生在“主動(dòng)找類”的場景解決思路簡單檢查classpath、檢查類名拼寫、檢查加載器能否看到那個(gè)類。NoClassDefFoundError是一個(gè)Error發(fā)生在“類已經(jīng)被編譯但運(yùn)行時(shí)加載失敗”或“靜態(tài)初始化失敗”之后。典型場景有兩個(gè)第一某個(gè)類在編譯期存在運(yùn)行期卻不在classpath里第二更陰間的是這個(gè)類在初始化階段拋異常了JVM標(biāo)記它為“初始化失敗”后續(xù)再使用它時(shí)直接拋NoClassDefFoundError。線上排查時(shí)如果只看到NoClassDefFoundError先往兩個(gè)方向看底層依賴丟沒丟、該類初始化時(shí)有沒有拋過ExceptionInInitializerError。很多時(shí)候真正的異常棧發(fā)生在很久之前被別的線程吞了要往回翻日志。7.2 Class.forName 和 ClassLoader.loadClass 的差異Class.forName(com.example.User)和loader.loadClass(com.example.User)最大的差別默認(rèn)情況下Class.forName會(huì)執(zhí)行類的初始化觸發(fā)clinit而ClassLoader.loadClass不會(huì)。底層原理是Class.forName有一個(gè)參數(shù)boolean initialize默認(rèn)true。所以經(jīng)典用法是加載數(shù)據(jù)庫驅(qū)動(dòng)時(shí)用Class.forName(某個(gè)驅(qū)動(dòng)類)因?yàn)轵?qū)動(dòng)的靜態(tài)代碼塊里做了注冊(cè)動(dòng)作而Spring的ClassUtils.forName、以及一些延遲加載場景會(huì)刻意用ClassLoader.loadClass或指定initializefalse就是為了“只加載類不執(zhí)行靜態(tài)邏輯”。這個(gè)差異在動(dòng)態(tài)生成類、延遲初始化、以及判斷“加載體只要Class對(duì)象不要副作用”的場景里非常關(guān)鍵。比如做字節(jié)碼增強(qiáng)時(shí)如果增強(qiáng)類的靜態(tài)塊有耗時(shí)邏輯用了Class.forName會(huì)把啟動(dòng)時(shí)間拖慢一大截而loadClass就不會(huì)。7.3 類何時(shí)能被卸載元空間OOM的反思很多人以為類加載進(jìn)來就永遠(yuǎn)留在內(nèi)存里其實(shí)不是。類可以被卸載但有嚴(yán)格條件只有當(dāng)加載這個(gè)類的類加載器本身被回收且該類沒有實(shí)例、Class對(duì)象沒有外部引用時(shí)這個(gè)類才能被JVM回收。內(nèi)置類加載器AppClassLoader、PlatformClassLoader等通常生命周期和應(yīng)用一樣長它們加載的類基本不會(huì)卸載。會(huì)頻繁產(chǎn)生“可卸載類”的場景幾乎都是自定義類加載器的場景每次熱部署新建一個(gè)類加載器、大量使用動(dòng)態(tài)代理生成新類、頻繁用反射框架做字節(jié)碼生成、JSP熱編譯新class等。如果這類操作失控元空間Metaspace會(huì)持續(xù)增長最終觸發(fā)java.lang.OutOfMemoryError: Metaspace。排查這類問題的核心就是回答一個(gè)問題除了JVM內(nèi)置加載器還有誰在源源不斷地創(chuàng)建類加載器或加載新類常見元兇包括濫用Class.forName創(chuàng)建大量臨時(shí)類、緩存的動(dòng)態(tài)代理類沒有釋放、每次請(qǐng)求都新建一個(gè)ClassLoader、腳本引擎反復(fù)編譯同一個(gè)腳本。我排查過的一個(gè)案例某個(gè)接口被調(diào)用一次就創(chuàng)建一個(gè)動(dòng)態(tài)代理Class代理類數(shù)量線性增長重啟前元空間漲到幾個(gè)G。這類問題光調(diào)-XX:MaxMetaspaceSize只能治標(biāo)根本解法是讓Class生成可控、復(fù)用緩存、及時(shí)釋放類加載器引用。這幾年和類加載子系統(tǒng)打過不少交道最大的體會(huì)是它不像GC、并發(fā)那些機(jī)制一樣每天都能感知到但一旦出問題往往都是“最講道理卻最難看到全景”的類型。寫業(yè)務(wù)代碼時(shí)確實(shí)很少直接操作ClassLoader可只要你在做中間件、插件化、熱部署、字節(jié)碼增強(qiáng)、或者排查線上詭異類沖突這張“字節(jié)碼入職流水線”的完整地圖就是最趁手的工具。建議你按這篇文章的內(nèi)容自己寫一個(gè)自定義類加載器跑一遍加密加載和同名類加載的Demo再動(dòng)手驗(yàn)證一下子類引用父類靜態(tài)字段不初始化子類的輸出順序。做完這些類加載子系統(tǒng)在你這里就不再是面試提綱而是真正能指揮調(diào)試的心智模型。