寫這篇東西的起因是前兩天又有同事跑過來問我“我寫了個注解結(jié)果反射的時候拿不到Class文件里也沒看到會不會是JVM把它吃了”這個問題看著小但牽出來的鏈路特別長Java源碼怎么變成Class文件、注解在字節(jié)碼里怎么存、類加載的時候怎么讀。我索性把Class文件這條線完整地梳理了一遍這也是我這么多年排查JVM問題的重要錨點。如果你剛開始學JVM或者寫了一段時間Java但沒細看.class里到底是什么再或者你在做Agent、字節(jié)碼增強、線上問題排查這類偏底層的工作這篇內(nèi)容都值得過一遍。我不會只講概念會直接掰開一個Class文件逐字節(jié)看也會把注解丟失、版本不兼容、Metaspace膨脹這類實戰(zhàn)坑講明白。1. 先搞清楚Class文件在JVM技術(shù)棧里的真正位置1.1 它是JVM的“通用語言”不是Java的專屬產(chǎn)物很多人有個錯覺覺得Class文件是Java編譯出來的所以是Java的東西。這個理解不完整。Class文件是JVM規(guī)范里定義的一種二進制格式JVM只認得這個格式誰編譯出來的它不管。Java、Kotlin、Groovy、Scala、Clojure都能編譯成Class文件。你甚至可以用文本編輯器手寫字節(jié)碼只要格式合法JVM一樣認。打個不全但貼切的比方Class文件像是JVM世界的“普通話”不同語言就是各地的方言。你寫Java、寫Kotlin本質(zhì)都是把自己的源碼“翻譯”成方言再統(tǒng)一整成普通話讓JVM這個“聽眾”聽懂。這也是為什么Kotlin能和Java無縫互調(diào)因為它們最終都落在同一個字節(jié)碼世界里。也正因如此想真正理解JVM繞開Class文件是不現(xiàn)實的。類加載、動態(tài)代理、AOP、熱部署、Agent這些看起來高級的能力底層全是在和Class文件打交道。1.2 JVM、JRE、JDK的關(guān)系幾句話講透網(wǎng)上天天有面試題問JVM和JRE的區(qū)別我發(fā)現(xiàn)很多人背了定義但沒串起來。前面已經(jīng)提了幾個熱詞這里就得把關(guān)系理順。JDK是Java Development Kit是給開發(fā)者用的完整工具包里面包含了編譯工具javac、打包工具jar、診斷工具jstack/jmap/jstat這些還包含一個JRE。JRE是Java Runtime Environment是給運行Java程序用的環(huán)境它里面包含JVM和Java核心類庫。JVM是Java Virtual Machine是真正執(zhí)行程序的那部分人話說是“跑字節(jié)碼的虛擬機”。關(guān)鍵點在于Class文件不是給操作系統(tǒng)直接執(zhí)行的而是給JVM執(zhí)行的。跨平臺靠的是JVM對Class文件的統(tǒng)一解釋不同操作系統(tǒng)裝不同的JVMClass文件不用變。這里有個經(jīng)常被誤解的點Java跨平臺不是“源碼跨平臺”源碼在哪都得先編譯成Class真正跨平臺的是這個統(tǒng)一的字節(jié)碼產(chǎn)物。1.3 JVM編譯器有幾種別再說“編譯器只有javac”熱詞里有“java jvm編譯器有幾種”這問題看著基礎(chǔ)其實問得很細。如果只答“javac”面試官容易覺得你停留在表面。實際上一套完整的Java技術(shù)棧里和編譯相關(guān)的行為至少有三類。第一類是前端編譯器最常見的就是javac也把Eclipse JDT里的ECJ算進去。它的職責很明確把.java源碼翻譯成.class文件做語法檢查、注解處理、生成字節(jié)碼。這一階段產(chǎn)出的是Class文件。第二類是即時編譯器也就是JIT運行期在JVM內(nèi)部工作的C1、C2還有Graal JIT。它們負責把熱點方法的字節(jié)碼進一步編譯成機器碼提升運行速度。第三類是提前編譯器AOT比如jaotc可以把Class文件或源碼直接編譯成原生二進制跳過運行期解釋或JIT編譯。理解這個分類Class文件的位置就清晰了。javac生產(chǎn)它JIT消費它AOT甚至能繞開它。你問“JVM編譯器有幾種”時如果能把這三類以及它們和Class文件的關(guān)系講清楚比死記答案有說服力得多。1.4 用十六進制認識一下CAFEBABE任何Class文件的頭4個字節(jié)一定是十六進制的CAFEBABE也就是咖啡寶貝。這是Class文件的魔數(shù)JVM用它來快速判斷文件是不是一個合格的Class文件。你隨便找一個.class文件用xxd或者Hex Fiend打開都能看到這個標志。緊接著是次版本號和主版本號各占2個字節(jié)。主版本號決定了這個Class文件是給哪個JDK版本用的52對應(yīng)Java 855對應(yīng)Java 1161對應(yīng)Java 1765對應(yīng)Java 21。所以“UnsupportedClassVersionError”本質(zhì)上就是版本號不匹配你用一個老JVM去加載一個高版本編譯出來的Class文件JVM一看版本號直接拒絕了。看十六進制只是第一步我得先說明一件事Class文件里存的所有字符串、引用、方法描述符都不是直接寫明文而是通過常量池來管理的。這個結(jié)構(gòu)是整個Class文件的靈魂我們下一步把它剝開。2. 逐字節(jié)看Class文件常量池才是真正的主角2.1 Class文件總體結(jié)構(gòu)一張表說清楚Class文件整體是一張線性的二進制表沒有分隔符靠固定的順序和每一個數(shù)據(jù)項的長度來確定邊界。作為參考它的頂層結(jié)構(gòu)大概是這樣的。數(shù)據(jù)項說明magic魔數(shù)固定CAFEBABEminor_version / major_version次版本號、主版本號決定JDK兼容版本constant_pool_count / constant_pool常量池數(shù)量與內(nèi)容access_flags類的訪問標志public/final/abstract等this_class / super_class當前類名索引、父類名索引interfaces_count / interfaces接口數(shù)量和索引列表fields_count / fields字段數(shù)量和字段表methods_count / methods方法數(shù)量和方法表attributes_count / attributes屬性數(shù)量和屬性表字段表里每一項都包含訪問標志、簡單名稱索引、描述符索引和屬性表方法表同理但方法表里的屬性表里通常藏著Code屬性這才是真正干活的字節(jié)碼指令。2.2 常量池是“數(shù)據(jù)倉庫”所有引用都靠下標常量池是Class文件里體量最大、也最容易被忽略的部分。Java源碼里出現(xiàn)的類名、方法名、字段名、字符串字面量、訪問修飾符全都被收進常量池統(tǒng)一編號。比如方法里要調(diào)用System.out.printlnClass文件不會直接把“System.out.println”這串字符寫進Code里而是存一個對常量池項的引用運行期再解析。先后我一起看一個簡化過的例子。比如一個被調(diào)用方法是print(String)V在常量池里你會看到類似這種結(jié)構(gòu)Utf8類型的“print”表示方法名Utf8類型的“(Ljava/lang/String;)V”表示方法描述符NameAndType指向這兩個Utf8Methodref再由類名和NameAndType組合起來。任何一個Class文件里這個鏈條無處不在。理解它你再看JVM規(guī)范里關(guān)于Methodref、Fieldref、InterfaceMethodref這些項就不會暈了。這也是為什么javap反編譯時滿屏的“#2 #5 #12”那些數(shù)字不是隨機的每個數(shù)字都對應(yīng)常量池里的一個槽位。我在實際排查中發(fā)現(xiàn)很多人看常量池覺得枯燥其實是沒把它當“倉庫”。你只要知道一句口訣就夠了在Class文件里凡是需要引用的名字最終都要落到常量池的一個下標上。常量池看懂Class文件的結(jié)構(gòu)就懂了一大半。2.3 訪問標志、字段表、方法表與Code屬性類的訪問標志由2字節(jié)的位掩碼構(gòu)成ACC_PUBLIC對應(yīng)的值是0x0001ACC_FINAL是0x0010ACC_ABSTRACT是0x0400ACC_SYNTHETIC是0x1000。位掩碼的意思就是多個修飾符疊加時直接把各數(shù)值按位或。比如一個public final類訪問標志就是0x0001 | 0x0010 0x0011。方法表里的Code屬性值得特別注意。它里面存字節(jié)碼指令、異常表、行號表、局部變量表。行號表表示哪一行Java源碼對應(yīng)哪些字節(jié)碼偏移這是異常堆棧能顯示“某某類第多少行”的原因。局部變量表則是存方法參數(shù)和局部變量的槽位描述。JIT做各種優(yōu)化時大量依賴這些附加信息。我見過不少人在分析性能問題時盯著系統(tǒng)調(diào)用的耗時看半天忘了先看方法的字節(jié)碼長什么樣。用javap -c就能把方法展開成一條條字節(jié)碼指令。字節(jié)碼是JVM執(zhí)行的中間形態(tài)它不像匯編那么底層但也不像Java那么抽象?？炊憔湍芑卮鸷芏唷斑@段代碼編譯后到底執(zhí)行了什么”的疑問。2.4 一條命令把Class文件“扒光”最常用也最推薦的工具是javap它是JDK自帶的Class文件反編譯工具。想快速看一個Class文件整體信息我第一次用時會執(zhí)行javap -v -p -c -s YourClass.class-v表示verbose打印堆棧、本地變量和常量池的詳細信息-p表示顯示私有成員-c表示對方法進行反匯編輸出字節(jié)碼-s表示打印方法簽名和字段簽名。如果想要更原始的信息可以配合xxd先看二進制再用javap對照。實際經(jīng)驗是先跑javap -v看版本號和常量池確認這個文件是不是你預期那個版本編譯的再跑javap -c看方法體確認某個邏輯有沒有被編譯器做掉或做成了什么樣子。對一些“明明寫了代碼但運行行為不對”的狀況這一步經(jīng)常能救命。3. 從加載到內(nèi)存模型Class文件進入JVM之后發(fā)生了什么3.1 類加載的五個階段與雙親委派Class文件在磁盤上只是文件真正跑起來前JVM要把它加載進來。類加載的生命周期大致分成加載、驗證、準備、解析、初始化五個階段。加載階段JVM按全限定名讀入Class文件二進制流把它轉(zhuǎn)換成方法區(qū)里的運行時數(shù)據(jù)結(jié)構(gòu)并在堆里生成一個Class對象作為訪問入口。驗證階段檢查格式、語義、字節(jié)碼合法性這是CAFEBABE魔數(shù)的意義所在防止非法文件混進來。準備階段給靜態(tài)變量分配內(nèi)存并設(shè)置零值。解析階段把常量池里的符號引用替換成直接引用。初始化階段才真正執(zhí)行靜態(tài)初始化器和靜態(tài)字段賦值。這里繞不開雙親委派。JVM的類加載器有層級關(guān)系啟動類加載器Bootstrap負責JDK內(nèi)部核心類平臺類加載器Platform負責模塊化類應(yīng)用類加載器Application負責classpath下的類。一個類要被加載時會先讓父加載器嘗試父親加載不了才輪到兒子。這樣做的核心價值有兩個一是避免核心類被應(yīng)用層的同名類替換二是保證同一個類在JVM里只有一個加載結(jié)果。如果你在做框架開發(fā)想打破雙親委派那就得自己繼承ClassLoader并重寫loadClass但這是反模式一般不建議在業(yè)務(wù)代碼里瞎搞。3.2 Class對象在JVM內(nèi)存模型里的落點熱詞“jvm內(nèi)存模型”經(jīng)常被討論但很多人把Java內(nèi)存模型JMM和JVM運行時內(nèi)存區(qū)混在一起。JMM是抽象并發(fā)語義討論的是線程與主內(nèi)存間的可見性規(guī)則JVM運行時內(nèi)存區(qū)是具體存儲區(qū)域比如堆、虛擬機棧、方法區(qū)。這里要講的是后者。Class文件被加載之后它的元數(shù)據(jù)——方法信息、字段信息、常量池解析結(jié)果、注解——是放在方法區(qū)里的。JDK 8之后方法區(qū)的落地實現(xiàn)是Metaspace也就是元空間它使用本地內(nèi)存不再像以前PermGen那樣有固定的默認上限。每一個被加載的類都會在堆里對應(yīng)一個java.lang.Class對象這個對象是訪問該類的元信息的“門把手”。這里有一個很微妙的地方你在代碼里寫“User.class”拿到的那個Class對象本身是在堆里的一個普通對象但它背后代表的類元數(shù)據(jù)卻在Metaspace里。對象頭里還有一個指向Klass的引用用來在運行時快速找到這個對象的類型信息。這也是為什么你能對任意對象調(diào)用getClass()JVM得靠對象頭里那個Klass指針去定位到Class文件解析出來的元數(shù)據(jù)。3.3 Kotlin寫Java Agent從Class文件到字節(jié)碼增強熱詞里有一條“Kotlin 快速上手在 JVM 上跑通一個 agent”這個場景特別適合用來理解Class文件的“活學活用”。所謂Java Agent本質(zhì)上就是在JVM啟動之后、正式類加載前后插一腳通過Instrumentation接口對Class文件做轉(zhuǎn)換。這個轉(zhuǎn)換不是改源碼而是直接改字節(jié)碼。寫Agent的思路大概是這樣的打包時在MANIFEST.MF里聲明Premain-Class指向一個包含premain方法的主類premain方法里拿到Instrumentation實例調(diào)用addTransformer注冊一個轉(zhuǎn)換器ClassFileTransformer.transform方法會在每個類被加載時收到原始字節(jié)數(shù)組你在這里面修改后返回新的字節(jié)數(shù)組。Kotlin寫這個為什么方便因為Kotlin編譯出來的同樣是標準Class文件方法、注解、屬性映射邏輯都還能保留。你可以用data class去定義Agent配置用協(xié)程去處理耗時邏輯最后打包成jar掛-javaagent啟動。由于最終產(chǎn)物是字節(jié)碼JVM根本不在乎你是用Java還是Kotlin寫的。真正的技術(shù)點在transform里怎么做字節(jié)碼增強。最常用的是ASM庫它是直接操作節(jié)點樹和指令的性能好但API難用。另外一個選擇是ByteBuddy它在ASM之上做了封裝寫起來舒服很多。舉個例子追蹤某個方法耗時用ByteBuddy的Advice機制在進入和退出兩個切點上織入System.nanoTime差值的邏輯幾行就能搞定。我踩過的一個坑是要修改的類正在被當前ClassLoader加載過程中transform里如果再去觸發(fā)其他類的加載可能死鎖。經(jīng)驗做法是做好類名過濾無關(guān)緊要的類直接返回null或用ClassReader快速跳過。還要注意ClassWriter的flags如果用COMPUTE_FRAMES能自動計算棧幀但性能會慢不少如果你明確知道字節(jié)碼不會改變棧幀結(jié)構(gòu)可以用COMPUTE_MAXS能省很多開銷。所以Agent技術(shù)并不神秘本質(zhì)就是“類加載前把Class文件改寫一下”。理解這一點你再看Arthas、SkyWalking這類工具的底層原理會突然通透很多。它們做的就是字節(jié)碼注入只是做進了更完善的產(chǎn)品里。3.4 版本窗口UnsupportedClassVersionError是怎么來的“編譯的時候好好跑起來就報UnsupportedClassVersionError”這種問題新人基本都會遇到一次。本質(zhì)上就是Class文件的主版本號高于當前JVM支持的版本。Java官方保持向后兼容高版本JVM能讀低版本Class文件但反過來不行老JVM沒法理解新版Class文件里的新字節(jié)碼指令。比如你用JDK 17的javac編譯默認主版本號就是61。把它扔到JDK 8的服務(wù)器上跑JVM版本號只支持52一看61大于52直接拒絕加載。解決辦法有幾種。第一降低編譯版本但注意-source/-target只控制語法和字節(jié)碼版本不能阻止你用到高版本JDK的新API后者照樣會在運行期報NoSuchMethodError。第二用--release參數(shù)比如javac --release 8它會同時限制API使用和版本輸出是更安全的選擇。第三升級線上JDK版本一勞永逸。排查時最快的方式是跑一句命令javap -verbose YourClass.class | grep major看到主版本號再對照當前JVM版本問題定位就完成了。4. 實戰(zhàn)踩坑注解丟失、字節(jié)碼修改與Class文件異常排查4.1 Override注解“丟”了先分清三種Retention熱詞里有一條“class文件overrider注解為什么會丟失”我非常確定提問者說的就是Override。先說結(jié)論Override注解的Retention是SOURCE它本來就不會進Class文件所以不是“丟了”是人家壓根不打算留。Java注解的保留策略有三種。SOURCE的注解只存在于源碼里編譯時就被丟棄典型代表就是Override和SuppressWarnings它們只是給編譯器看的提示。CLASS的注解會被寫進Class文件的注解屬性里但JVM運行時不加載它們默認的Retention就是CLASS這也是很多自定義注解“編譯在但運行時反射拿不到”的原因。RUNTIME的注解不僅進Class文件還會在運行期被JVM讀取反射API能拿到比如Transactional、GetMapping這些。所以排查自定義注解反射拿不到的時候第一件事就是查注解定義里的Retention。如果你寫的是Retention(RetentionPolicy.CLASS)那在運行時getAnnotation是拿不到的要改成RUNTIME。4.2 另一個常見元兇注解Target/Inherited與Kotlin use-site target除了Retention還有兩個很容易忽略的點。一個是Inherited。這個注解只對“類上的注解”的繼承起作用方法、字段、參數(shù)上的注解即使加了Inherited也不隨繼承傳遞。很多人以為父類方法上的注解子類重寫后還會在反射里出現(xiàn)其實不會。Spring的Transactional之所以能在子類方法上生效是因為Spring走了代理和AOP它讀的是目標方法注解并自己做了傳播處理跟JVM原生注解繼承是兩回事。另一個是Kotlin的use-site target。Kotlin代碼里的annotation寫在屬性上編譯成Class文件時這個注解到底落在哪個目標上取決于你有沒有指定use-site target。想讓它成為字段注解要寫field:NotNull若寫get:NotNull就成了getter方法上的注解。如果你在Kotlin和Java混編的項目里做反射很容易因為use-site沒指定而對不上目標表現(xiàn)就是“Java那邊反射明明該看到卻沒有”。這個坑我在跨語言工具里踩過不止一次排查方式永遠是反編譯看字節(jié)碼里的RuntimeVisibleAnnotations到底掛在哪個位置。4.3 字節(jié)碼修改工具鏈導致的“隱性丟注解”還有一種注解丟失既不怪Retention也不怪繼承而是字節(jié)碼處理工具在改寫Class文件時把注解洗掉了?；煜ぞ?、打包工具、字節(jié)碼AOP框架都可能干這種事。ProGuard/R8在做代碼壓縮和混淆時默認會丟棄注解信息。Spring框架大量使用注解驅(qū)動如果沒保注解啟動時一堆Autowired失效這是非常經(jīng)典的線上事故。解決方案是在混淆規(guī)則里寫上類似-keepattributesAnnotation之類的指令。ASM做類轉(zhuǎn)換時如果你只想改方法體但使用了自定義的ClassVisitor重寫visitMethod時忘了調(diào)用visitAnnotation把注解Visitor轉(zhuǎn)發(fā)出去注解信息也會悄悄消失。一個實際建議在改造Class文件的管道里最后一步加上“注解完整性校驗”。你可以先跑一個不改動的控制組用JDK自帶的能力或ASM的CheckClassAdapter做一次掃描對比改造前后的RuntimeVisibleAnnotations數(shù)量。我在做一個跨JVM語言的Agent時就是這么抓到丟注解問題的不是源碼層丟了是ASM的ClassNode處理路徑上有一段沒有遍歷AnnotationNode。4.4 常見Class文件相關(guān)異常速查表做應(yīng)用排障多了會發(fā)現(xiàn)Class文件相關(guān)的異常就那么幾個特征是重復且好認。我總結(jié)成了一張速查表。異常/錯誤典型原因排查方向ClassNotFoundException運行時找不到目標類檢查classpath是否完整、依賴是否缺失NoClassDefFoundError類存在但初始化失敗或依賴類缺失往前翻日志找Caused by多數(shù)是靜態(tài)初始化異常UnsupportedClassVersionErrorClass版本高于JVM版本javap看major版本調(diào)整編譯版本或JVMClassFormatErrorClass文件結(jié)構(gòu)非法確認文件有沒有被截斷、有沒有被錯誤處理VerifyError字節(jié)碼驗證失敗棧幀或類型不兼容多發(fā)生在字節(jié)碼增強代理類時檢查ASM轉(zhuǎn)換邏輯LinkageError類的重復加載或簽名不一致檢查依賴版本沖突是否多個ClassLoader加載同名類這里要特別提一下NoClassDefFoundError和ClassNotFoundException的區(qū)別。后者是找不到類前者是類其實存在但加載過程中因為某個依賴缺失或靜態(tài)初始化拋了異常導致JVM認為這個類不可用。排查NoClassDefFoundError時不能只看這一行一定要往前翻真正的Root Cause往往在第一條異常鏈里。5. JVM調(diào)優(yōu)與Class數(shù)量治理Metaspace才是隱藏焦點5.1 Class數(shù)量膨脹為什么危險很多人聊JVM調(diào)優(yōu)開口就是堆大小、GC策略但很少有人主動提Metaspace。實際上Class文件的加載結(jié)果就是Metaspace里的類元數(shù)據(jù)。如果一個應(yīng)用在運行期不斷創(chuàng)建新的類Metaspace就會持續(xù)增長。舊時代的PermGen空間溢出是著名的OOM來源到了JDK 8之后這個坑變成Metaspace OOM。哪些操作會“造類”JDK動態(tài)代理、CGLIB子類代理、熱部署框架、Groovy等動態(tài)腳本引擎、大量lambda捕獲外部變量導致動態(tài)類生成還有Spring這類依賴CGLIB做增強的框架。腳本引擎按次執(zhí)行可能每次都生成新類如果調(diào)用頻率高且不清理Metaspace漲得飛快。判斷是否是因為Class數(shù)量過多導致Metaspace緊張一個快捷方法是用jstat看一眼Metaspace的增長趨勢同時通過GC日志對比類加載數(shù)。如果加載數(shù)量飆升、卸載數(shù)量幾乎為零基本就是“只進不出”離OOM不遠了。5.2 動態(tài)類生成CGLIB、JDK代理與Kotlin編譯常見生成點先說JDK動態(tài)代理。它要求目標類實現(xiàn)接口運行時在內(nèi)存里生成一個實現(xiàn)該接口的Proxy類這個生成類是一個全新Class繼承自java.lang.reflect.Proxy。CGLIB則是生成目標類的子類靠繼承和覆寫方法實現(xiàn)增強所以目標類不能被final修飾。這些代理類本身也是標準Class文件你可以通過在啟動參數(shù)里加一個JVM開關(guān)把生成的類落盤JDK代理類可以用-Dsun.misc.ProxyGenerator.saveGeneratedFilestrue保存到磁盤CGLIB生成類則可以通過-Dcglib.debugLocation目錄來輸出再用javap或IDEA反編譯。做框架或插件開發(fā)時看這些生成類和看業(yè)務(wù)Class一樣重要。Kotlin這邊也有生成點。頂層函數(shù)會被編譯成以文件名加Kt后綴命名的類data class會生成componentN、copy、equals/hashCode/toStringlambda也會被編譯成Function接口的實現(xiàn)類。你要是發(fā)現(xiàn)某個應(yīng)用里Class數(shù)量多到一個詭異的值先別急著慌很可能是Kotlin的語法糖在生成輔助類這本身不算問題但反過來也說明Class數(shù)量會隨著這類語言特性明顯上升。5.3 調(diào)參方向與驗證手段針對MetaspaceJVM提供幾個常用參數(shù)。第一個是-XX:MetaspaceSize它表示Metaspace首次觸發(fā)GC的閾值不是上限。第二個是-XX:MaxMetaspaceSize這才是硬上限默認情況下受本地內(nèi)存限制你可以顯式設(shè)置一個值保護進程。第三個是-XX:MaxMetaspaceFreeRatio控制GC后Metaspace空閑容量百分比。排查時我會配合這幾個命令jstat -gc pid看M列和MC列的數(shù)值變化。MC表示當前Metaspace容量MU表示已使用量。再配合jcmd pid VM.native_memory加上JVM參數(shù)-XX:NativeMemoryTrackingsummary能看到Metaspace的本地內(nèi)存占用明細。如果懷疑是動態(tài)類生成直接加-XX:TraceClassLoading和-XX:TraceClassUnloading日志會刷出每個被加載或卸載的類重定向到文件里再按類名前綴統(tǒng)計就能揪出誰在瘋狂造類。我實際碰過一個案例一個平臺不停創(chuàng)建CGLIB代理類給遠程RPC做攔截運行兩天后Metaspace OOM。當時就是開著-XX:TraceClassLoading把日志存下來發(fā)現(xiàn)同一個業(yè)務(wù)接口的代理類被重復創(chuàng)建了數(shù)萬個原因是上層做緩存的時候key沒寫全每次調(diào)用都認為“代理不存在”然后重新生成。這只是治理Class數(shù)量膨脹的一個常見例子。5.4 面試官常問的JVM/Class文件進階題與我的回答思路熱詞里有“jvm面試題”這塊正好把這篇文章的知識點串起來。以下這幾個問題我經(jīng)常在面工程師時問也建議自查。先看“Class文件里有注解嗎”“注解存哪個段”。這兩個是結(jié)構(gòu)題考的是常量池、屬性表以及RuntimeVisibleAnnotations這類屬性。答出來說明看過Class文件答不出來大概率是背了書沒實操過。再看“類加載過程哪個階段會出錯”“一個類被兩個ClassLoader加載算兩個類嗎”。后者尤其刁鉆答案是類由類全限定名和定義加載器共同標識同一個Class文件被兩個不同加載器加載生成的兩個Class對象不相等instanceof校驗也可能過不去。這是OSGi、插件化框架的底層難題。再看“為什么高版本JDK不能運行低版本編譯的Class文件反而沒問題”“如果JDK 17編譯的Class在JDK 8上跑會怎樣”。這是版本兼容題考察Class版本號以及向后兼容的設(shè)計。最后是“Metaspace存什么”“為什么JDK 8要移除PermGen”。答到Metaspace存類元數(shù)據(jù)、運行時常量池用本地內(nèi)存替代固定容量避免因為固定上限導致OOM基本就能過關(guān)。最好再補一句實際調(diào)優(yōu)經(jīng)驗比如設(shè)置MaxMetaspaceSize不要過小否則正常應(yīng)用一天到晚在GC。我在實際篩人時最怕聽到“Class文件就是個字節(jié)碼文件”這種一句到底的答案。真正動手拆過Class、做過字節(jié)碼增強、處理過Metaspace問題的人描述同一個東西時是會有細節(jié)的。這也是這篇東西存在的意義把JVM這條線上的一個重要零件拆到能落地為止。后面如果再有人問我“注解為什么丟了”我不會再直接給答案而是讓他先跑一句javap -v看清楚Class文件里到底有什么再反推結(jié)論。這個習慣比記住任何一張表都有用。