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