做Java這么多年我面試過不少候選人也帶過很多新人。一個(gè)很有意思的現(xiàn)象是大多數(shù)人能把Java語(yǔ)法背得滾瓜爛熟但你要是問他一個(gè).java文件從保存到程序跑起來中間到底發(fā)生了什么他反而會(huì)愣住。有人以為編譯完就是機(jī)器碼有人以為JVM就是解釋器還有人分不清javac和java兩條命令的工作邊界。這篇文章就把這條完整鏈路拆開講透javac怎么把源碼變成字節(jié)碼、類加載機(jī)制如何把class文件請(qǐng)進(jìn)JVM、字節(jié)碼又是怎么被真正執(zhí)行成機(jī)器指令的最后落到實(shí)際開發(fā)和面試?yán)锬切└哳l坑上。不管你是剛學(xué)Java的新手還是寫了幾年想補(bǔ)基礎(chǔ)的老手這條鏈路都值得徹底搞明白——因?yàn)楹芏嗑€上詭異問題根子都埋在這條鏈路里。1. javac編譯階段.java到.class之間發(fā)生了什么1.1 先明確一個(gè)誤區(qū)Java的編譯不是C/C那種編譯很多人默認(rèn)編譯就是把源代碼變成機(jī)器能直接跑的東西。在C語(yǔ)言里gcc把.c文件編譯成.o目標(biāo)文件再經(jīng)過鏈接變成可執(zhí)行二進(jìn)制操作系統(tǒng)直接加載執(zhí)行確實(shí)是這樣。但Java的編譯完全不同。javac命令把.java文件編譯出的.class文件里面的字節(jié)碼bytecode并不是任何CPU的機(jī)器指令。它是一種面向JVM的中間指令集類似虛擬CPU的匯編語(yǔ)言。這個(gè)設(shè)計(jì)是故意的——字節(jié)碼不認(rèn)識(shí)具體的操作系統(tǒng)和CPU架構(gòu)它只認(rèn)識(shí)JVM。這就是一次編譯到處運(yùn)行的真正含義你編譯一次得到.class文件然后把它丟到裝有對(duì)應(yīng)JVM的平臺(tái)上JVM負(fù)責(zé)翻譯成當(dāng)前平臺(tái)能執(zhí)行的機(jī)器碼。編譯產(chǎn)物跨平臺(tái)執(zhí)行過程不跨平臺(tái)跨的是JVM。所以從這一刻起Java程序的生命周期就被分成了兩段編譯期javac干的事和運(yùn)行期JVM干的事。這也是理解后面所有機(jī)制的總綱。1.2 編譯四步走從字符串到字節(jié)碼javac并不是一口氣把源碼變成字節(jié)碼的它內(nèi)部有嚴(yán)格的階段劃分。我自己早期以為javac就是個(gè)文本替換器后來翻了編譯原理的書才明白它的工作流程其實(shí)非常經(jīng)典大致是詞法分析把.java里的字符流拆成一個(gè)一個(gè)的token記號(hào)。比如public class Hello會(huì)被拆成public、class、Hello這些最小單位每個(gè)token還帶著自己的類型標(biāo)記關(guān)鍵字、標(biāo)識(shí)符、運(yùn)算符等。這個(gè)階段如果報(bào)錯(cuò)通常是你寫了非法字符或用錯(cuò)了關(guān)鍵字。語(yǔ)法分析根據(jù)Java語(yǔ)言規(guī)范把token序列組裝成抽象語(yǔ)法樹AST。這棵樹的結(jié)構(gòu)反映了代碼的語(yǔ)法層級(jí)比如方法里有變量聲明、if分支、循環(huán)。這個(gè)階段做的是句法是否正確的檢查比如if (x) {少了右括號(hào)就會(huì)在這里報(bào)錯(cuò)。語(yǔ)義分析這是最容易被忽略的一步也是javac價(jià)值所在。它檢查的不再是句子通不通而是意思對(duì)不對(duì)。比如類型是否匹配、方法是否存在、變量有沒有重復(fù)定義、泛型擦除、自動(dòng)拆裝箱的插入都是在這一階段完成的。int x hello這種錯(cuò)誤就是語(yǔ)義分析階段攔下來的。字節(jié)碼生成AST經(jīng)過驗(yàn)證和優(yōu)化后javac會(huì)生成對(duì)應(yīng)的字節(jié)碼指令寫入.class文件。有一個(gè)細(xì)節(jié)值得注意javac不會(huì)做特別深的性能優(yōu)化。它只做必要的語(yǔ)法糖處理和簡(jiǎn)單的常量折疊比如int a 2 * 3直接算成6真正的高階優(yōu)化全留給了運(yùn)行期的JIT編譯器。這跟GCC那種編譯期就做大量?jī)?yōu)化的思路完全不同。很多從C轉(zhuǎn)Java的人一開始不理解為什么編譯完還不快答案就在這里——Java的優(yōu)化大頭在運(yùn)行期。1.3 Class文件里到底存了什么如果你用十六進(jìn)制工具打開一個(gè).class文件第一眼看到的是魔數(shù)cafebabe這是JVM識(shí)別class文件的標(biāo)記。之后是版本號(hào)、常量池、訪問標(biāo)志、字段表、方法表、屬性表等結(jié)構(gòu)。我想重點(diǎn)說常量池。它是class文件里最核心的數(shù)據(jù)結(jié)構(gòu)說白了就是一個(gè)符號(hào)引用清單。里面存了類名、方法名、字段名、字符串字面量、類型描述符等。比如你寫了System.out.println(Hello)常量池里會(huì)存放System類的符號(hào)引用、out字段的符號(hào)引用、println方法的符號(hào)引用以及Hello這個(gè)字符串字面量。為什么我叫它符號(hào)引用而不是直接引用因?yàn)榫幾g期javac并不知道System.out在內(nèi)存里的具體地址它只能記錄一個(gè)名字。真正的地址解析要等到運(yùn)行期類加載時(shí)再做。這個(gè)機(jī)制牽連出一個(gè)重要結(jié)論后面會(huì)細(xì)說Java的鏈接時(shí)機(jī)發(fā)生在運(yùn)行期所以Java本質(zhì)上是動(dòng)態(tài)鏈接的。1.4 javac管了哪些事又刻意不管哪些事javac負(fù)責(zé)的事情包括語(yǔ)法檢查、類型檢查、常量折疊、泛型擦除、生成語(yǔ)法糖代碼比如foreach循環(huán)轉(zhuǎn)換成迭代器調(diào)用、lambda表達(dá)式轉(zhuǎn)換成invokedynamic指令、字符串拼接轉(zhuǎn)換成StringBuilder操作、生成class文件結(jié)構(gòu)。javac刻意不負(fù)責(zé)的事情包括不找到第三方依賴的入口地址、不進(jìn)行跨類的代碼優(yōu)化、不校驗(yàn)?zāi)繕?biāo)平臺(tái)兼容性、不生成可執(zhí)行文件。這里有個(gè)非常典型的實(shí)戰(zhàn)問題為什么有時(shí)候javac能編譯過但運(yùn)行時(shí)就報(bào)NoClassDefFoundError因?yàn)榫幾g期只需要能找到類的符號(hào)引用就能通過比如你import了某個(gè)包、調(diào)用了某個(gè)方法而運(yùn)行期JVM必須真的把那個(gè)類加載到內(nèi)存并找到方法實(shí)現(xiàn)。編譯時(shí)用的classpath和運(yùn)行時(shí)用的classpath不一致就會(huì)造成這種編過了但跑不起來的詭異情況。2. 類加載.class文件進(jìn)入JVM的完整旅程2.1 加載、驗(yàn)證、準(zhǔn)備、解析、初始化五階段.class文件是靜態(tài)文件跑起來之前必須先被JVM加載進(jìn)來。這個(gè)過程叫類加載包含五個(gè)階段加載由類加載器ClassLoader根據(jù)全限定名找到class文件或jar包里的class條目讀入字節(jié)流然后把它轉(zhuǎn)成方法區(qū)里的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)并在堆中生成一個(gè)java.lang.Class對(duì)象作為訪問入口。這一步就是把文件變成JVM內(nèi)部數(shù)據(jù)的過程。驗(yàn)證確保這個(gè)class文件是合法安全的不能破壞JVM。包括文件格式驗(yàn)證魔數(shù)是不是cafebabe、字節(jié)碼語(yǔ)義驗(yàn)證指令操作數(shù)是否合法、符號(hào)引用驗(yàn)證等。這個(gè)設(shè)計(jì)是為了安全——畢竟class文件不一定來自javac也可能是手工構(gòu)造的惡意字節(jié)碼。準(zhǔn)備為類的靜態(tài)變量分配內(nèi)存并設(shè)置默認(rèn)初始值。注意這里說的是默認(rèn)值不是代碼里寫的值。比如static int count 10在準(zhǔn)備階段count先被置為0真正的10要等初始化階段才賦上。解析把常量池里的符號(hào)引用替換為直接引用。簡(jiǎn)單說符號(hào)引用是名字直接引用是地址。比如之前說的System.out解析階段會(huì)真正找到它在內(nèi)存中的位置并建立關(guān)聯(lián)。這一步是Java動(dòng)態(tài)鏈接的關(guān)鍵環(huán)節(jié)——之所以叫動(dòng)態(tài)就是因?yàn)殒溄影l(fā)生在類被加載運(yùn)行的時(shí)候而不是編譯成可執(zhí)行文件時(shí)。初始化執(zhí)行類構(gòu)造器clinit方法給靜態(tài)變量賦上代碼里寫的值執(zhí)行靜態(tài)代碼塊。這個(gè)階段是很多亂象的溫床比如靜態(tài)塊里拋了異常、循環(huán)依賴導(dǎo)致的初始化順序問題都在這里爆發(fā)。五個(gè)階段里驗(yàn)證、準(zhǔn)備、解析統(tǒng)稱為連接linking整個(gè)類加載就是加載連接初始化的組合。2.2 雙親委派模型為什么是安全底線JVM的類加載器不是只有一個(gè)而是分層的。標(biāo)準(zhǔn)三層結(jié)構(gòu)分別是Bootstrap ClassLoader啟動(dòng)類加載器加載JDK核心類比如java.lang、java.util這個(gè)加載器是C寫的在Java里看不到它的實(shí)例。Platform ClassLoader平臺(tái)類加載器JDK9之后叫這個(gè)以前叫Extension加載一些擴(kuò)展模塊。Application ClassLoader應(yīng)用類加載器加載classpath下的用戶代碼。它們的協(xié)作機(jī)制叫雙親委派當(dāng)一個(gè)類加載請(qǐng)求到來先不自己加載而是委托給父加載器每一層都向上傳直到Bootstrap如果父加載器加載不了才往下返回由子加載器嘗試加載。為什么要這么復(fù)雜核心是安全。假如你自己寫了一個(gè)java.lang.String放在classpath里如果沒有雙親委派應(yīng)用類加載器直接加載了它那整個(gè)Java基礎(chǔ)類庫(kù)的安全性就崩了——你的假String可以篡改核心邏輯。有了雙親委派java.lang.String的加載請(qǐng)求最終會(huì)到達(dá)Bootstrap加載到的一定是JDK自帶的真String用戶自定義的偽造類根本沒機(jī)會(huì)被加載。這個(gè)機(jī)制也是后面排查ClassCastException、類隔離問題時(shí)的底層依據(jù)。比如Tomcat里每個(gè)Web應(yīng)用有獨(dú)立的類加載器就是靠破壞雙親委派模型實(shí)現(xiàn)應(yīng)用隔離的。2.3 靜態(tài)鏈接還是動(dòng)態(tài)鏈接一個(gè)很多人搞錯(cuò)的點(diǎn)我在網(wǎng)上看到一個(gè)熱搜詞叫java是靜態(tài)鏈接的。這個(gè)說法是錯(cuò)的但錯(cuò)得很典型。C程序編譯完鏈接器會(huì)把所有依賴的函數(shù)實(shí)現(xiàn)地址全部確定下來生成的可執(zhí)行文件可以直接運(yùn)行。這叫靜態(tài)鏈接或編譯期鏈接。Java不是這樣——Java的class文件在編譯期只記錄符號(hào)引用所有方法調(diào)用、字段訪問的地址綁定都是在運(yùn)行期解析階段完成的。這就是動(dòng)態(tài)鏈接。動(dòng)態(tài)鏈接帶來兩個(gè)直接結(jié)果第一類可以延遲加載JVM可以按需把某個(gè)類加載進(jìn)來避免啟動(dòng)時(shí)所有類全部就位第二多態(tài)才有實(shí)現(xiàn)的土壤——只有運(yùn)行期才知道變量的實(shí)際對(duì)象類型方法分派invokevirtual指令才能在方法表里查到真正的調(diào)用目標(biāo)。所以如果有人面試問你Java程序是靜態(tài)鏈接還是動(dòng)態(tài)鏈接答案是動(dòng)態(tài)鏈接論證過程就是類加載機(jī)制里的解析階段。3. 字節(jié)碼執(zhí)行解釋執(zhí)行與JIT編譯的協(xié)同作戰(zhàn)3.1 逐條翻譯的解釋執(zhí)行為什么慢class文件加載完畢之后JVM就要開始執(zhí)行字節(jié)碼了。最簡(jiǎn)單的執(zhí)行方式是解釋執(zhí)行——一條一條把字節(jié)碼指令翻譯成當(dāng)前平臺(tái)的機(jī)器指令然后執(zhí)行。你可以把解釋執(zhí)行想象成一個(gè)同聲傳譯外國(guó)人說一句翻譯跟一句。優(yōu)點(diǎn)是啟動(dòng)快、內(nèi)存占用低不需要額外編譯環(huán)節(jié)缺點(diǎn)是同一個(gè)方法被調(diào)用一萬次它就要翻譯一萬次執(zhí)行效率上不去。早期Java被人詬病慢就是這個(gè)原因。后來HotSpot虛擬機(jī)引入了JITJust-In-Time編譯Java的性能問題才逐步解決。3.2 熱點(diǎn)檢測(cè)與JIT編譯把字節(jié)碼變成機(jī)器碼JIT的思路很樸素一段代碼如果被反復(fù)執(zhí)行為什么還要每次都翻譯直接把它編譯成機(jī)器碼緩存起來下次調(diào)用直接執(zhí)行機(jī)器碼不就行了關(guān)鍵在于哪些代碼值得編譯。JVM通過運(yùn)行期統(tǒng)計(jì)信息來判定這就是熱點(diǎn)檢測(cè)。HotSpot虛擬機(jī)名字里的HotSpot就來自這里會(huì)統(tǒng)計(jì)方法調(diào)用次數(shù)和循環(huán)回邊次數(shù)當(dāng)超過閾值默認(rèn)方法調(diào)用10000次Server模式是10000可以用-XX:CompileThreshold調(diào)整就會(huì)把這個(gè)方法標(biāo)記為熱點(diǎn)交給JIT編譯器編譯成當(dāng)前平臺(tái)的機(jī)器碼。現(xiàn)代JVM普遍采用分層編譯HotSpot里對(duì)應(yīng)C1和C2兩套編譯器。C1編譯速度更快但編譯出的機(jī)器碼優(yōu)化程度一般C2編譯更慢但優(yōu)化更激進(jìn)生成的代碼質(zhì)量更高。分層編譯的做法是方法先被C1快速編譯用低質(zhì)量的機(jī)器碼先跑起來如果方法還是持續(xù)熱點(diǎn)再交給C2做深度優(yōu)化。為什么不像C/C那樣一次性全部編譯成機(jī)器碼要搞解釋執(zhí)行JIT混合這套原因是取舍全部編譯拖慢啟動(dòng)時(shí)間。一個(gè)大型Spring應(yīng)用幾萬個(gè)類全部編譯要幾十秒用戶等不起。運(yùn)行期編譯能拿到解釋執(zhí)行階段收集的運(yùn)行時(shí)信息可以針對(duì)實(shí)際數(shù)據(jù)做優(yōu)化這是靜態(tài)編譯做不到的。3.3 逃逸分析及其他運(yùn)行期優(yōu)化JIT編譯器里最有代表性的優(yōu)化之一是逃逸分析。名字聽著玄思路其實(shí)很簡(jiǎn)單判斷一個(gè)對(duì)象的作用域會(huì)不會(huì)逃逸出方法。如果一個(gè)對(duì)象只在方法內(nèi)部使用、不會(huì)被其他線程訪問、不會(huì)被外部引用那它就沒有逃逸。沒有逃逸的對(duì)象可以享受三個(gè)優(yōu)化棧上分配直接在虛擬機(jī)棧上分配內(nèi)存方法結(jié)束自動(dòng)銷毀不需要經(jīng)過垃圾回收。這是很多人說JVM未必所有對(duì)象都分配在堆上的原因。標(biāo)量替換把對(duì)象拆成它包含的基礎(chǔ)類型字段省去對(duì)象頭等額外開銷。鎖消除如果同步代碼塊里的鎖對(duì)象不會(huì)逃逸出當(dāng)前線程那就根本沒競(jìng)爭(zhēng)的鎖JIT會(huì)把同步直接去掉。此外還有內(nèi)聯(lián)把方法體直接嵌入調(diào)用處、死代碼消除、循環(huán)展開等。解釋執(zhí)行和JIT編譯的邊界清晰之后你就明白為什么Java程序常常是越跑越快——熱點(diǎn)方法被不斷優(yōu)化執(zhí)行效率隨時(shí)間上升這在編譯型語(yǔ)言里是見不到的現(xiàn)象。4. 從java命令到main方法運(yùn)行期的完整畫面4.1 JVM啟動(dòng)后先做什么你敲下java Hello那一刻開始發(fā)生的事情比你想象的要多得多JVM先啟動(dòng)自身進(jìn)程初始化運(yùn)行環(huán)境。創(chuàng)建引導(dǎo)類加載器開始加載核心類庫(kù)——java.lang、java.util這些最基礎(chǔ)的類其實(shí)在這里就已經(jīng)成批加載了。創(chuàng)建JVM內(nèi)部的一些核心數(shù)據(jù)結(jié)構(gòu)比如初始化各種內(nèi)存區(qū)域。找到你指定的主類啟動(dòng)類就是我們寫的含有main方法的類調(diào)用它的main方法。這里有個(gè)高頻問題為什么經(jīng)?？吹藉e(cuò)誤: 找不到或無法加載主類 Hello原因一般有三個(gè)classpath里沒有包含當(dāng)前目錄導(dǎo)致類加載器找不到Hello.class類文件名與類名不一致main方法的簽名寫錯(cuò)了比如漏了public或void、參數(shù)不是String[]。前兩種都跟類加載機(jī)制直接相關(guān)最后一種屬于JVM檢查方法簽名失敗。4.2 內(nèi)存區(qū)域與一個(gè)對(duì)象誕生的全過程JVM運(yùn)行期的內(nèi)存布局也是這條鏈路的重要一環(huán)。按照J(rèn)ava虛擬機(jī)規(guī)范運(yùn)行時(shí)數(shù)據(jù)區(qū)包括程序計(jì)數(shù)器記錄當(dāng)前線程執(zhí)行到哪一條字節(jié)碼指令是線程私有的。虛擬機(jī)棧每個(gè)線程一個(gè)棧里面是棧幀每個(gè)方法調(diào)用對(duì)應(yīng)一個(gè)棧幀里面有局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等。本地方法棧給native方法比如底層C/C實(shí)現(xiàn)的方法用的。堆幾乎所有對(duì)象實(shí)例都在這里分配是垃圾回收的主戰(zhàn)場(chǎng)。方法區(qū)JDK8之后叫元空間存儲(chǔ)類元信息、常量、靜態(tài)變量、JIT編譯后的代碼緩存等。一個(gè)對(duì)象從創(chuàng)建到回收的過程可以完整描述為類加載檢查確認(rèn)這個(gè)類已經(jīng)被加載→ 在堆上分配內(nèi)存如果開啟了TLAB優(yōu)先在TLAB里分配→ 把內(nèi)存清零 → 設(shè)置對(duì)象頭標(biāo)記字段、類指針等→ 執(zhí)行init構(gòu)造方法初始化字段 → 后續(xù)被GC回收或逃逸分析優(yōu)化。每次new一個(gè)對(duì)象背后都有這么一長(zhǎng)串動(dòng)作。這也是為什么推薦創(chuàng)建少量大對(duì)象而不是海量小對(duì)象——每一次分配都需要類加載檢查、分配、初始化、釋放的處理。4.3 一條Hello World的完整旅程為了把這整條鏈路串起來我習(xí)慣用最簡(jiǎn)單的Hello World做貫穿javac Hello.java把源碼變成hello.class。詞法、語(yǔ)法、語(yǔ)義都過了class文件里記下了main方法、打印語(yǔ)句、字符串常量。java Hello啟動(dòng)JVM使用應(yīng)用類加載器尋找Hello.class。加載Hello類后依次走驗(yàn)證、準(zhǔn)備、解析、初始化四個(gè)階段。其中解析階段會(huì)把Hello類里引用的System、PrintStream、out字段等符號(hào)引用解析成直接引用。JVM執(zhí)行main方法對(duì)應(yīng)的字節(jié)碼。在解釋階段逐條翻譯執(zhí)行此時(shí)調(diào)用System.out.println時(shí)會(huì)真正定位到PrintStream.println的實(shí)現(xiàn)。如果這個(gè)方法被大量調(diào)用成為熱點(diǎn)JIT編譯器會(huì)把它編譯成機(jī)器碼后續(xù)直接執(zhí)行機(jī)器碼速度更快。程序結(jié)束時(shí)非守護(hù)線程停止JVM進(jìn)程退場(chǎng)。一條輸出語(yǔ)句背后是編譯、類加載、符號(hào)解析、字節(jié)碼執(zhí)行、JIT優(yōu)化一整套機(jī)制的協(xié)同。5. 基于這條鏈路的常見問題排查與面試區(qū)分點(diǎn)5.1 高頻報(bào)錯(cuò)類找不到和主類找不到這是新手問得最多的一類問題但很多人分不清ClassNotFoundException和NoClassDefFoundError的區(qū)別。ClassNotFoundException是顯式加載某個(gè)類比如用Class.forName時(shí)類加載器在classpath里找不到這個(gè)類它是受檢異常屬于java.lang。NoClassDefFoundError則更陰險(xiǎn)——編譯時(shí)這個(gè)類是存在的但運(yùn)行時(shí)加載階段失敗了它是Error不是Exception。典型場(chǎng)景依賴的jar包沒部署到運(yùn)行環(huán)境、類的靜態(tài)初始化拋了異常、某個(gè)類因?yàn)榘姹静患嫒菰隍?yàn)證階段沒通過。區(qū)分這兩者的意義在于定位問題的方向前者說明你的classpath配置有問題或缺少依賴包后者說明你編譯時(shí)的環(huán)境和運(yùn)行時(shí)的環(huán)境不一致。我排查線上問題時(shí)遇到NoClassDefFoundError第一反應(yīng)就是檢查運(yùn)行環(huán)境里有沒有對(duì)應(yīng)版本的jar而不是去查代碼邏輯。5.2 版本不匹配問題UnsupportedClassVersionError這個(gè)報(bào)錯(cuò)信息里通常會(huì)帶一個(gè)數(shù)字比如class file version 61.0。61.0對(duì)應(yīng)Java 1755.0對(duì)應(yīng)Java 1152.0對(duì)應(yīng)Java 8。這個(gè)數(shù)字記錄在class文件的版本號(hào)位置JVM加載時(shí)會(huì)校驗(yàn)如果class文件的版本號(hào)高于當(dāng)前JVM支持的版本直接拒絕加載并拋UnsupportedClassVersionError。所以用JDK17編譯用JDK8運(yùn)行必然報(bào)這個(gè)錯(cuò)。常見解決辦法是重新用低版本JDK編譯或者換高版本JDK運(yùn)行。這個(gè)坑在多人協(xié)作項(xiàng)目里特別常見。5.3 編譯期異常與運(yùn)行期異常的邊界熱搜詞里有編譯期異常這里也順帶說清楚。Java把異常分成兩類受檢異常checked exception和不受檢異常unchecked exception。受檢異常比如IOException如果方法里可能拋出它要么在方法簽名里聲明throws要么在方法內(nèi)try-catch處理否則javac在編譯期就報(bào)錯(cuò)根本生成不了class文件。這叫編譯期強(qiáng)制檢查。不受檢異常包括RuntimeException及其子類比如NullPointerException、ArrayIndexOutOfBoundsException編譯器不強(qiáng)制處理它們通常到運(yùn)行期才會(huì)暴露。注意這里說的編譯期異常有兩個(gè)完全不同層面的含義一是編譯器要求你處理受檢異常這種編譯期報(bào)錯(cuò)二是編譯期生成的代碼導(dǎo)致運(yùn)行期異常比如泛型擦除后強(qiáng)轉(zhuǎn)失敗。踩過坑的人應(yīng)該懂一個(gè)List 在編譯期安全打包但類型擦除后在運(yùn)行期取出來時(shí)如果強(qiáng)轉(zhuǎn)成其他類型就會(huì)ClassCastException。5.4 面試回答Java是編譯型還是解釋型的框架這個(gè)問題幾乎每次面試都會(huì)遇到標(biāo)準(zhǔn)回答框架是Java既有編譯型的特點(diǎn)也有解釋型的特點(diǎn)準(zhǔn)確說是先編譯后解釋再編譯的混合模式。具體展開說javac把源碼編譯成字節(jié)碼這是編譯行為JVM一開始用解釋器逐條解釋字節(jié)碼這是解釋行為方法成為熱點(diǎn)后JIT把字節(jié)碼編譯成機(jī)器碼這又回到了編譯行為。所以不能簡(jiǎn)單歸為單一一種。另外一個(gè)高頻追問是一次編譯到處運(yùn)行為什么能實(shí)現(xiàn)回答落點(diǎn)是編譯產(chǎn)物是平臺(tái)無關(guān)的字節(jié)碼運(yùn)行依賴的平臺(tái)相關(guān)部分全部被封裝在JVM里不同平臺(tái)裝不同JVM但.class文件是同一份。我個(gè)人做了這么多年Java最大的體會(huì)是編譯到運(yùn)行這條鏈路不是枯燥的基礎(chǔ)理論它是定位問題的坐標(biāo)系。遇到任何詭異報(bào)錯(cuò)先問自己這句話發(fā)生在哪個(gè)階段——是javac編譯報(bào)錯(cuò)、還是類加載階段報(bào)錯(cuò)、還是字節(jié)碼執(zhí)行階段報(bào)錯(cuò)、還是JIT優(yōu)化導(dǎo)致的問題。把這個(gè)坐標(biāo)一劃90%的問題都能快速找到排查方向。如果這篇文章能幫你在腦海中建立這條完整鏈路比記多少API都值錢。以后無論是面試講原理還是線上排查疑難雜癥這條路就是你的地圖。