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