1. 準(zhǔn)備階段環(huán)境與工具鏈的底層心思1.1 簡(jiǎn)單談?wù)勔粋€(gè)常被忽略的問題JDK 到底怎么選很多Java程序跑著跑著出了內(nèi)存問題第一反應(yīng)是“堆不夠了加大內(nèi)存”但加到多大、為什么加心里并沒底。我以前帶過一個(gè)學(xué)生線上服務(wù)頻繁GC停頓他連續(xù)加了三次堆內(nèi)存都沒好轉(zhuǎn)最后排查下來(lái)是程序里有個(gè)死循環(huán)一直在往一個(gè)List里塞數(shù)據(jù)內(nèi)存給再多也白搭。我講這個(gè)例子是想說Java程序的編譯與運(yùn)行機(jī)制不是面試八股是排查線上問題躲不開的基本功。回到選JDK這件事。很多剛開始學(xué)Java的人下載JDK時(shí)根本分不清哪個(gè)版本該配哪個(gè)。我就直接說結(jié)論如果你是在做企業(yè)級(jí)項(xiàng)目選LTS版本長(zhǎng)期支持版最穩(wěn)妥目前主流是JDK 8、JDK 11、JDK 17再新一點(diǎn)的JDK 21也開始普及。JDK 8在存量系統(tǒng)里占比還很高因?yàn)樗墒炝烁鞣N框架中間件都兼容得很好。JDK 11引入了不少新特性比如ZGC的初步版本、HTTP Client標(biāo)準(zhǔn)化遷移成本也不算太大。JDK 17則在性能和GC上又做了不少改進(jìn)新一代項(xiàng)目用這個(gè)比較多。其實(shí)這里面有個(gè)更底層的問題值得想清楚JDK和JRE到底什么關(guān)系。JRE只是Java運(yùn)行時(shí)環(huán)境只有JVM和核心類庫(kù)能運(yùn)行class文件但不能編譯。JDK是Java開發(fā)工具包包含完整的JRE、編譯器javac、打包工具jar、監(jiān)控工具jcmd等一大堆東西。一把梭裝JDK就行因?yàn)殚_發(fā)、編譯、運(yùn)行都覆蓋了。但如果是純生產(chǎn)服務(wù)器只想跑jar包理論上裝JRE就夠只是現(xiàn)在JDK和JRE的下載包也都在慢慢整合裝JDK倒也省事。1.2 環(huán)境變量配置不能省但別被舊教程帶偏環(huán)境變量這塊網(wǎng)上教程魚龍混雜動(dòng)不動(dòng)就讓配JAVA_HOME、PATH、CLASSPATH三件套。新版JDK其實(shí)沒這么復(fù)雜。PATH變量的作用是讓系統(tǒng)在任意目錄下都能直接執(zhí)行java、javac這些命令。它的本質(zhì)就是把JDK的bin目錄路徑添加到系統(tǒng)可執(zhí)行文件的搜索列表里。這個(gè)必須配不配的話你每次都要寫一長(zhǎng)串絕對(duì)路徑來(lái)調(diào)用命令。JAVA_HOME的作用主要是給其他依賴Java的工具用的比如Maven、Tomcat、Idea等。它們啟動(dòng)時(shí)通常通過JAVA_HOME去定位JVM如果你沒配或者配錯(cuò)經(jīng)常出現(xiàn)“一個(gè)工具能跑另一個(gè)工具起不來(lái)”的奇怪現(xiàn)象。所以我建議無(wú)論如何都配一下成本極低收益很穩(wěn)定。CLASSPATH就更有意思了。很多老教程還是煞費(fèi)苦心地配置它但如果你用的是JDK 9以上的版本官方已經(jīng)大大弱化了CLASSPATH的作用。因?yàn)镴DK 9引入了模塊系統(tǒng)類路徑傳統(tǒng)的那套全局搜索機(jī)制逐漸被邊緣化。我記得很多初學(xué)者在JDK 1.6時(shí)代配置CLASSPATH如果忘了加當(dāng)前目錄點(diǎn)編譯出來(lái)的class文件運(yùn)行時(shí)經(jīng)常報(bào)找不到主類煩躁得不行。現(xiàn)在的新版環(huán)境基本不用為這個(gè)折騰了。說白了舊知識(shí)里可能有一大半已經(jīng)過時(shí)你得先分清楚哪些是本質(zhì)、哪些是歷史遺留。我個(gè)人的建議是如果你剛接觸Java優(yōu)先裝最新的LTS版本配好JAVA_HOME和PATH用官方文檔確認(rèn)一下CLASSPATH是否需要手動(dòng)設(shè)置然后就開始寫代碼不用在環(huán)境上過度內(nèi)耗。1.3 必備的輔助工具做Java開發(fā)光有JDK還不夠。我強(qiáng)烈建議裝一兩個(gè)順手的小工具不用多但要精。比如反編譯查看字節(jié)碼用的javapJDK自帶、字節(jié)碼可視化工具、性能分析工具還有代碼熱部署插件之類的。尤其是javap它是JDK自帶的class文件反匯編工具能讓你直接看到自己的代碼編譯后長(zhǎng)什么樣這對(duì)于理解編譯機(jī)制非常非常有幫助。后面我在講字節(jié)碼的時(shí)候會(huì)實(shí)際操作一遍給大家看。提前說一句真正理解Java的編譯和運(yùn)行機(jī)制一半的功勞得歸給“親眼看看class文件里到底裝了什么”。2. 編譯階段從源代碼到字節(jié)碼javac到底做了什么2.1 javac不是簡(jiǎn)單“翻譯”它是一條流水線拿C/C說話編譯器是把高級(jí)語(yǔ)言直接編譯成特定CPU架構(gòu)的機(jī)器碼也就是說你在自己的電腦上編出的可執(zhí)行文件拿到另一臺(tái)不同架構(gòu)電腦上可能跑不了。Java的javac完全不同它并不生成機(jī)器碼而是生成一種中間表示——字節(jié)碼bytecode存放在.class文件里。字節(jié)碼不是給CPU讀的而是給JVM讀的。JVM在自己的虛擬世界里負(fù)責(zé)把字節(jié)碼翻譯成當(dāng)前CPU能理解的機(jī)器碼來(lái)執(zhí)行。這一層間接設(shè)計(jì)直接造就了Java“一次編譯處處運(yùn)行”的特性。javac的編譯流程一般分四步走。第一步詞法分析。把.java源代碼的字符流拆成一個(gè)一個(gè)的Token詞法單元就像把一句話拆成一個(gè)個(gè)單詞。比如把 int a 10 拆成 int、a、、10 這幾個(gè)Token。第二步語(yǔ)法分析。根據(jù)Java語(yǔ)法規(guī)則把這些Token組裝成一棵抽象語(yǔ)法樹AST如果語(yǔ)法有錯(cuò)誤在這里就會(huì)被抓出來(lái)。第三步語(yǔ)義分析。這一步是做類型檢查、變量定義和引用檢查等更高級(jí)層面的驗(yàn)證比如你把一個(gè)String賦值給int變量編譯器在這里就會(huì)報(bào)錯(cuò)。最后一步字節(jié)碼生成。遍歷語(yǔ)法樹生成符合Java虛擬機(jī)規(guī)范要求的class文件。很多人有個(gè)誤解覺得編譯階段是“把Java翻譯成CPU指令”其實(shí)不是。編譯階段的終點(diǎn)是class文件而真正“翻譯成機(jī)器碼”的動(dòng)作發(fā)生在運(yùn)行階段由JVM的即時(shí)編譯器來(lái)完成。這個(gè)區(qū)別是整個(gè)Java編譯與運(yùn)行機(jī)制認(rèn)知里最核心的分水嶺。2.2 用javap親眼看一次字節(jié)碼講原理講得再多不如實(shí)際打開一個(gè)class文件看看。我隨手寫一個(gè)極其簡(jiǎn)單的類public class Demo { public static void main(String[] args) { int a 3; int b 5; int c a b; System.out.println(c); } }編譯后用javap -c Demo.class一跑你會(huì)看到類似這樣的輸出public static void main(java.lang.String[]); Code: 0: iconst_3 1: istore_1 2: iconst_5 3: istore_2 4: iload_1 5: iload_2 6: iadd 7: istore_3 8: getstatic 11: iload_3 12: invokevirtual 15: return你別被這一堆嚇住實(shí)際上邏輯很清楚iconst_3就是把整數(shù)3推入操作數(shù)棧istore_1是把棧頂值存到局部變量表第1個(gè)位置。iadd是把兩個(gè)數(shù)加起來(lái)交給System.out.println調(diào)用。所謂的“虛擬機(jī)指令集”就是這么一條一條像匯編語(yǔ)言一樣的指令排布。想分清JVM的“棧式指令架構(gòu)”和x86的“寄存器架構(gòu)”看到這一段輸出你就會(huì)立刻明白JVM是通過操作數(shù)棧來(lái)完成計(jì)算的這跟CPU直接操作寄存器的工作方式是不一樣的。我建議每個(gè)Java開發(fā)者在學(xué)習(xí)類加載和JVM內(nèi)存模型之前都去親手javap一個(gè)自己寫的類。不用多看一個(gè)就夠瞬間就會(huì)對(duì)“Java源代碼到底經(jīng)歷了什么”有一個(gè)直觀印象。字節(jié)碼這個(gè)東西看多了之后很多高級(jí)框架的黑魔法在你眼里就會(huì)慢慢透明。2.3 編譯期能做的優(yōu)化比你想象中少很多人以為編譯器會(huì)做大量性能優(yōu)化這點(diǎn)Java和C區(qū)別挺大。javac做的優(yōu)化非常有限它更偏向于“忠實(shí)翻譯”。比如常量折疊如果你寫 int a 2 3編譯后可能直接就存了5而不是在運(yùn)行期再算一遍。再比如字符串字面量的一些簡(jiǎn)單合并處理。但真正復(fù)雜的方法內(nèi)聯(lián)、循環(huán)優(yōu)化、逃逸分析這些基本都不是javac在管而是運(yùn)行期JIT編譯器干的活兒。JIT編譯器有運(yùn)行時(shí)的統(tǒng)計(jì)信息知道哪段代碼是熱點(diǎn)從而決定優(yōu)化到什么程度。這是編譯期靜態(tài)死等永遠(yuǎn)比不了的。還有一個(gè)特別重要的點(diǎn)語(yǔ)法糖。像泛型、自動(dòng)拆裝箱、增強(qiáng)for循環(huán)、lambda表達(dá)式這些是程序員友好的“糖”編譯時(shí)會(huì)被javac“還原”成更基礎(chǔ)的寫法。泛型就一個(gè)大坑Java的泛型是“偽泛型”編譯前你把List 寫得好好的編譯后字節(jié)碼里泛型信息就被擦除了變成List這個(gè)在運(yùn)行期根本拿不到泛型參數(shù)。所以經(jīng)常有人說“運(yùn)行時(shí)想拿一個(gè)泛型的真實(shí)類型非常難”根子就在編譯期的類型擦除機(jī)制。再補(bǔ)充一點(diǎn)Java語(yǔ)言通過字節(jié)碼標(biāo)準(zhǔn)向其他JVM語(yǔ)言敞開了大門。Kotlin、Scala、Groovy這些語(yǔ)言最終都能編譯成JVM字節(jié)碼共用JVM的運(yùn)行時(shí)能力。也就是說只要你懂Java的編譯與運(yùn)行機(jī)制你學(xué)其他JVM語(yǔ)言時(shí)很多底層的堆、棧、GC、類加載機(jī)制是可以直接遷移過去的這是非常劃算的一筆知識(shí)投資。提示想深入理解編譯期行為除了javap還能用-verbose參數(shù)讓javac輸出更詳細(xì)的加載和編譯日志。多個(gè)編譯細(xì)節(jié)對(duì)照看很多以前想不通的問題很快就通了。3. 類加載機(jī)制字節(jié)碼進(jìn)入JVM的第一道關(guān)卡3.1 類加載的五步走class文件并不是一啟動(dòng)就全部被塞進(jìn)內(nèi)存的JVM采用“懶加載”策略用到哪個(gè)類才加載哪個(gè)類。這背后就是類加載的五階段流程加載、驗(yàn)證、準(zhǔn)備、解析、初始化。先說加載。這個(gè)階段由類加載器完成它負(fù)責(zé)把class文件的二進(jìn)制字節(jié)流讀進(jìn)內(nèi)存在方法區(qū)里生成對(duì)應(yīng)的類元信息同時(shí)在堆里創(chuàng)建一個(gè)Class對(duì)象作為外界訪問這個(gè)類的入口。類加載器真正讀取字節(jié)流時(shí)既可以從本地文件系統(tǒng)讀也可以從jar包、網(wǎng)絡(luò)甚至動(dòng)態(tài)生成的字節(jié)流中間接獲取這就為很多框架的騷操作埋下了伏筆。然后是驗(yàn)證和準(zhǔn)備。驗(yàn)證階段會(huì)做大量安全性檢查比如字節(jié)碼能不能按規(guī)范正確執(zhí)行、符號(hào)引用是否有效等防止惡意字節(jié)碼搞壞虛擬機(jī)。準(zhǔn)備階段則是在方法區(qū)中為類的static變量分配內(nèi)存并給出默認(rèn)值。注意是默認(rèn)值不是程序員寫的初始值。比如static int count 10在準(zhǔn)備階段count先變成0真正的10要等初始化階段才被設(shè)置進(jìn)去。接下來(lái)是解析。解析階段是把常量池里的符號(hào)引用替換成直接引用的過程。舉個(gè)例子代碼里寫的類名、方法名在編譯期只是一個(gè)符號(hào)引用解析階段要從JVM里找到對(duì)應(yīng)的實(shí)際內(nèi)存地址真正建立“引用連接”。最后是初始化執(zhí)行類的構(gòu)造器也就是static變量賦值和靜態(tài)代碼塊。整個(gè)過程聽著不難但有個(gè)細(xì)節(jié)很關(guān)鍵類的初始化時(shí)機(jī)不是隨意的。JVM只在遇到new對(duì)象、調(diào)用靜態(tài)方法、訪問靜態(tài)變量、使用反射觸碰類、初始化某個(gè)類的子類等幾個(gè)場(chǎng)景時(shí)才會(huì)觸發(fā)初始化。我自己就遇到過“奇怪現(xiàn)象”寫了一個(gè)工具類里面有靜態(tài)代碼塊但程序怎么運(yùn)行那個(gè)靜態(tài)代碼塊都沒執(zhí)行。原因很簡(jiǎn)單當(dāng)時(shí)我只拿它做了類名引用沒有觸發(fā)任何主動(dòng)使用場(chǎng)景初始化當(dāng)然不會(huì)發(fā)生。3.2 雙親委派模型一句話解釋清楚類加載器一共有四種主要的引導(dǎo)類加載器Bootstrap ClassLoader負(fù)責(zé)加載JDK核心類庫(kù)比如rt.jarJDK 8時(shí)代擴(kuò)展類加載器Extension ClassLoader或者叫平臺(tái)類加載器負(fù)責(zé)加載一些擴(kuò)展目錄下的類應(yīng)用類加載器Application ClassLoader負(fù)責(zé)加載classpath和項(xiàng)目依賴下的類還有用戶自定義類加載器由開發(fā)者自己寫。這四層之間有一種“委托”關(guān)系叫雙親委派模型。過程一句話一個(gè)類加載器收到加載請(qǐng)求時(shí)先不自己去加載而是把請(qǐng)求往上拋給父加載器父加載器再往上拋一直到頂層引導(dǎo)類加載器。只有父加載器加載不到子加載器才試著自己動(dòng)手。為什么非要做這種看似繞路的操作核心原因就六個(gè)字保證核心類不被篡改。比如你自己寫一個(gè)包名和java.lang.String一模一樣的類如果應(yīng)用類加載器直接加載你自己的類那JVM核心類庫(kù)就被完全污染了。但類加載請(qǐng)求經(jīng)過雙親委派一路傳到引導(dǎo)類加載器引導(dǎo)類加載器發(fā)現(xiàn)“這不就是JDK自帶的String嗎”直接用真正的核心類返回你寫的那個(gè)假String根本沒有機(jī)會(huì)被加載。這個(gè)機(jī)制對(duì)整個(gè)Java生態(tài)的穩(wěn)定性和安全性意義非常重大比JVM能跑多快重要得多。3.3 打破雙親委派的地方往往藏著重型武器雖然雙親委派是默認(rèn)規(guī)則但很多框架恰恰會(huì)在這個(gè)機(jī)制上動(dòng)刀。最典型的打破場(chǎng)景就是Tomcat這類Web容器和熱部署場(chǎng)景。Tomcat為了部署多個(gè)應(yīng)用、又讓各個(gè)應(yīng)用的類互不干擾每個(gè)應(yīng)用都用自己的類加載器來(lái)加載WEB-INF/classes下的類。如果嚴(yán)格遵守雙親委派父加載器先加載那多應(yīng)用之間很容易互相污染。所以Tomcat故意讓W(xué)eb應(yīng)用類加載器先嘗試加載自己的類加載不到才交給父加載器這其實(shí)是“優(yōu)先級(jí)翻轉(zhuǎn)”的破壞。熱部署原理也類似每次改完代碼重新編譯替換掉類文件然后干掉舊類加載器創(chuàng)建新類加載器去加載新的字節(jié)碼這樣同樣的類名在不同加載器里就能共存達(dá)到“不重啟JVM”的效果。這些場(chǎng)景告訴我們雙親委派不是死規(guī)矩它是個(gè)高度可插拔的機(jī)制。理解了類加載器的構(gòu)造和委派順序你才真正有機(jī)會(huì)看懂Spring、Dubbo、Tomcat這些框架的很多“神秘行為”。我在學(xué)習(xí)階段其實(shí)踩過不少坑比如排查一個(gè)NoClassDefFoundError查來(lái)查去最后發(fā)現(xiàn)是自己寫了個(gè)自定義類加載器加載范圍搞錯(cuò)了導(dǎo)致同一個(gè)類在不同類加載器里加載了兩份簽名對(duì)不上運(yùn)行期才爆出來(lái)。這類問題日志里往往不直接你只能順著類加載器的委派路徑一層層查。4. 運(yùn)行階段解釋執(zhí)行與JIT編譯的理性博弈4.1 為什么既有解釋器又有JIT編譯器前面說JVM執(zhí)行字節(jié)碼不是直接給CPU執(zhí)行的它需要把字節(jié)碼變成機(jī)器碼。這個(gè)轉(zhuǎn)變JVM提供了兩種模式解釋執(zhí)行和即時(shí)編譯執(zhí)行JIT編譯。解釋執(zhí)行就像你讀一本外文書看到一句話翻一句邊翻邊讀。好處是啟動(dòng)快、不用等待編譯壞處是每句話都要現(xiàn)場(chǎng)翻譯運(yùn)行速度上不去。JIT編譯就像你先把整本外文書翻譯成中文裝訂好再一次性讀中文版。好處是后面讀得非?？靿奶幨情_頭那一段翻譯時(shí)間你得等一等。所以JVM默認(rèn)不傻選一條路走到黑程序啟動(dòng)初期大量代碼還沒跑熱用解釋執(zhí)行讓程序先跑起來(lái)隨著程序運(yùn)行JVM不斷統(tǒng)計(jì)哪些方法被反復(fù)執(zhí)行、哪些是熱點(diǎn)代碼熱點(diǎn)方法就會(huì)被交給JIT編譯器編譯成本地機(jī)器碼后續(xù)執(zhí)行直接跑機(jī)器碼速度飛快。一條方法從“被解釋執(zhí)行幾千次”到“被JIT編譯成機(jī)器碼”這中間就是性能暴漲的關(guān)鍵一躍。這也是為什么Java程序啟動(dòng)后要“預(yù)熱”一段時(shí)間性能才會(huì)達(dá)到巔峰狀態(tài)。4.2 分層編譯和熱點(diǎn)代碼你需要知道的實(shí)操常識(shí)現(xiàn)代JVM基本都會(huì)開啟分層編譯Tiered Compilation。JIT編譯器分C1客戶端編譯器和C2服務(wù)端編譯器兩層。C1編譯速度快優(yōu)化程度中等適合快速啟動(dòng)場(chǎng)景C2編譯慢優(yōu)化非常激進(jìn)適用于長(zhǎng)時(shí)間跑的重型服務(wù)。分層編譯的策略是一個(gè)方法先被解釋執(zhí)行被判定為熱點(diǎn)后先用C1編譯一遍拿個(gè)中等的性能提升如果熱度還在繼續(xù)上升再用C2做激進(jìn)優(yōu)化。這也解釋了為什么同一個(gè)方法在不同時(shí)期可能“變了個(gè)人”快慢差別巨大。哪些方法算熱點(diǎn)JVM用的是“基于計(jì)數(shù)器的熱點(diǎn)探測(cè)”它給每個(gè)方法維護(hù)調(diào)用計(jì)數(shù)器給循環(huán)體維護(hù)回邊計(jì)數(shù)器。方法在一個(gè)時(shí)間段內(nèi)被調(diào)用超過閾值默認(rèn)可能上千次或者循環(huán)次數(shù)超出閾值就觸發(fā)JIT編譯。你寫一個(gè)每秒跑幾萬(wàn)次的調(diào)用方法幾乎必然會(huì)被JIT察覺得到然后被編譯成高度優(yōu)化的本地代碼。熱點(diǎn)編譯還能順手做一堆優(yōu)化其中我特別想說兩個(gè)。第一個(gè)是方法內(nèi)聯(lián)。把被頻繁調(diào)用的小方法體的代碼“搬”到調(diào)用處內(nèi)嵌起來(lái)省掉方法調(diào)用和返回的開銷。很多人在網(wǎng)上搜性能優(yōu)化技巧搜來(lái)搜去結(jié)論就是“別寫多余的方法”其實(shí)JIT早就可能幫你內(nèi)聯(lián)了。過度拆分方法反而可能增加編譯壓力性能并不一定更好。第二個(gè)是逃逸分析。JVM會(huì)分析一個(gè)對(duì)象會(huì)不會(huì)“逃逸”出方法作用域。如果對(duì)象只在一個(gè)方法內(nèi)部使用沒有外部引用觸及JVM就可以嘗試把它分配在棧上而不是堆上方法結(jié)束直接彈棧釋放根本不用進(jìn)GC回收流程。JVM還能因此做鎖消除、標(biāo)量替換等激進(jìn)優(yōu)化。不過說實(shí)話這些優(yōu)化細(xì)節(jié)平時(shí)寫業(yè)務(wù)代碼不太會(huì)直接體會(huì)到但遇到階段性的性能壓測(cè)理解這些背景能幫你少走很多彎路。注意任何時(shí)候都不要把業(yè)務(wù)邏輯正確性押注在JIT優(yōu)化上比如你在循環(huán)里寫了個(gè)多余的對(duì)象創(chuàng)建JIT可能會(huì)幫你優(yōu)化掉但不同JDK版本、不同CPU架構(gòu)下的優(yōu)化決策不完全一致。正確做法是先把代碼寫干凈再讓JVM去優(yōu)化而不是反過來(lái)指望JVM替你遮丑。4.3 JIT相關(guān)的JVM參數(shù)可調(diào)的也就那么幾個(gè)JVM的JIT相關(guān)參數(shù)其實(shí)不需要背太多常用的也就幾個(gè)-XX:TieredCompilation開啟分層編譯新版本默認(rèn)開啟-XX:CompileThreshold10000調(diào)整熱點(diǎn)閾值的調(diào)用計(jì)數(shù)-XX:PrintCompilation打印方法編譯日志-XX:-UseCompiler關(guān)閉JIT編譯跑純解釋模式通常不推薦純粹為了對(duì)比性能。排查問題的時(shí)候輸出一下Compilation日志看看哪些方法被編譯了、編譯耗時(shí)多少對(duì)定位性能瓶頸有直接幫助。另外提一下JVM有“解釋器模式”和“編譯器模式”啟動(dòng)參數(shù)的差別。如果你執(zhí)行java -Xint就是強(qiáng)制純解釋模式啟動(dòng)快但后面性能拉胯java -Xcomp則是強(qiáng)制所有方法都走編譯執(zhí)行啟動(dòng)特別慢。這兩者都不是常態(tài)選項(xiàng)生產(chǎn)環(huán)境用默認(rèn)混合模式即可別閑得沒事去亂改啟動(dòng)參數(shù)。5. 運(yùn)行時(shí)區(qū)域與內(nèi)存管理代碼逃不掉的地基5.1 運(yùn)行時(shí)數(shù)據(jù)區(qū)哪些是線程私有哪些是共享JVM啟動(dòng)后在內(nèi)存里劃分了若干區(qū)域Java程序的每個(gè)線程都在這片區(qū)域里活動(dòng)。按是否線程私有的標(biāo)準(zhǔn)分開就可以理得很清楚。程序計(jì)數(shù)器Program Counter Register是線程私有的一個(gè)小區(qū)域存儲(chǔ)當(dāng)前線程正在執(zhí)行的字節(jié)碼指令地址。如果一個(gè)線程要發(fā)生上下文切換恢復(fù)現(xiàn)場(chǎng)時(shí)就需要靠它找回位置。Java虛擬機(jī)棧也是線程私有的每執(zhí)行一個(gè)方法JVM就創(chuàng)建一個(gè)棧幀棧幀里存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接和方法出口等。方法調(diào)用和返回對(duì)應(yīng)著棧的壓棧和出棧。如果方法遞歸過深?？臻g不夠就會(huì)拋StackOverflowError。本地方法棧和虛擬機(jī)棧很像區(qū)別在于它為native方法服務(wù)。這個(gè)區(qū)域經(jīng)常被忽視但老技術(shù)棧里會(huì)有大量native調(diào)用排查問題繞不開。堆和元空間JDK 8之后取代了永久代是線程共享的。堆是絕大多數(shù)對(duì)象實(shí)例存放的地方也是GC的主要戰(zhàn)場(chǎng)元空間裝類的元信息、靜態(tài)變量等和堆的回收邏輯不同。JVM內(nèi)存模型中最關(guān)鍵的那個(gè)思想——幾乎所有對(duì)象都存在堆里由GC統(tǒng)一管理這從一開始就決定了Java程序員不用也沒法手動(dòng)管理內(nèi)存。5.2 GC機(jī)制建議掌握的底層邏輯對(duì)Java來(lái)說GC不是“性能好壞的附屬品”而是內(nèi)存管理的基石。但垃圾回收本身也是有代價(jià)的尤其是回收時(shí)經(jīng)常需要“停頓應(yīng)用線程”也就是Stop The World這個(gè)停頓時(shí)間如果太長(zhǎng)線上服務(wù)就會(huì)出現(xiàn)明顯的卡頓。現(xiàn)代JVM的GC基本都采用分代收集思想?！胺执钡囊罁?jù)是對(duì)象的存活特征絕大部分對(duì)象很快變成垃圾所以堆被分成新生代和老年代。新生代里又細(xì)分Eden區(qū)和兩個(gè)Survivor區(qū)大部分對(duì)象先在Eden區(qū)分配經(jīng)過若干次Minor GC仍存活的對(duì)象慢慢晉升到老年代。新生代GC經(jīng)常用復(fù)制算法速度快但浪費(fèi)空間老年代對(duì)象存活率高就不適合復(fù)制更傾向于標(biāo)記-清除或標(biāo)記-整理這類算法。具體到垃圾收集器不同版本場(chǎng)景選擇很多JDK 8舊的組合里ParNewCMS很常見到了JDK 11及以后G1成了默認(rèn)選擇JDK 17以及更新的LTS里ZGC開始在高吞吐、低延遲場(chǎng)景里表現(xiàn)出色。ZGC有一點(diǎn)特別神奇它能把STW時(shí)間壓到個(gè)位數(shù)毫秒級(jí)別這個(gè)特性對(duì)大內(nèi)存服務(wù)非常友好。但GC選型要結(jié)合服務(wù)特點(diǎn)來(lái)定不是無(wú)腦用最新的就好。你一個(gè)吞吐型批處理任務(wù)用G1或者Parallel Scavenge反而簡(jiǎn)單可靠。5.3 JVM啟動(dòng)參數(shù)寫模板不如懂語(yǔ)義網(wǎng)上一搜JVM調(diào)優(yōu)參數(shù)能搜出無(wú)數(shù)“JVM調(diào)優(yōu)模板”但很多模板都是老掉牙的。我的原則是參數(shù)寧缺毋濫每一個(gè)參數(shù)你都要知道它到底在干什么。堆大小配置是最基礎(chǔ)的三個(gè)-Xms2048m設(shè)置初始堆大小-Xmx2048m設(shè)置最大堆大小-Xmn512m設(shè)置新生代大小。實(shí)際部署時(shí)一般把-Xms和-Xmx設(shè)為相同數(shù)值避免堆擴(kuò)容時(shí)產(chǎn)生性能抖動(dòng)。如果堆設(shè)置太小對(duì)象頻繁觸發(fā)GC系統(tǒng)吞吐量拉胯堆設(shè)置太大GC單次回收時(shí)間變長(zhǎng)反而可能導(dǎo)致超時(shí)。要在內(nèi)存和停頓之間做權(quán)衡。此外元空間用-XX:MaxMetaspaceSize來(lái)限制防止框架動(dòng)態(tài)生成大量類元信息把內(nèi)存擠爆線程棧大小用-Xss控制一個(gè)進(jìn)程能開的線程數(shù)也受它影響GC日志開啟參數(shù)建議生產(chǎn)環(huán)境一直打開比如-Xlog:gc*配合文件輸出以后排查問題沒日志你根本無(wú)從下手。我強(qiáng)烈建議任何部署到服務(wù)器的服務(wù)至少把堆大小、GC日志兩個(gè)配置寫清楚其他參數(shù)等遇到具體問題再動(dòng)手。6. 一次典型的線上問題排查壓測(cè)峰值時(shí)接口大面積超時(shí)6.1 場(chǎng)景還原我以前處理過一個(gè)案例模擬項(xiàng)目背景大致是這樣某業(yè)務(wù)的API服務(wù)平時(shí)響應(yīng)幾十毫秒某天大促壓測(cè)接口突然大面積超時(shí)CPU飆高部分請(qǐng)求直接報(bào)錯(cuò)。當(dāng)時(shí)團(tuán)隊(duì)的直覺是“服務(wù)器性能不行”馬上想加機(jī)器。但加了機(jī)器之后過了幾分鐘新節(jié)點(diǎn)竟然也出現(xiàn)同樣的情況這就不對(duì)勁了。我接手后先看三件事看GC日志、看線程棧、看堆內(nèi)存。命令組合無(wú)非就是jstat、jmap、jstack、jcmd這一套。先跑jstat -gcutil看GC情況發(fā)現(xiàn)老年代GC特別頻繁而且每次Full GC耗時(shí)高達(dá)好幾秒。再看堆內(nèi)存JVM可用堆分配了4G但老年代占用已經(jīng)飆到非常危險(xiǎn)的水位說明大量對(duì)象長(zhǎng)期存活。最后jstack看線程狀態(tài)發(fā)現(xiàn)有一批線程大量阻塞在等待同一個(gè)鎖上面。6.2 順著運(yùn)行機(jī)制一步步拆解問題最終定位到某段核心方法里有個(gè)對(duì)象被保存在了一個(gè)靜態(tài)的Map里并發(fā)環(huán)境下大家都在往這個(gè)Map里寫數(shù)據(jù)讀寫還套了一把重量級(jí)鎖。堆內(nèi)存被高頻創(chuàng)建的大量中間對(duì)象撐爆GC線程一直在拼命回收卻擋不住對(duì)象產(chǎn)生的速度而大量線程排隊(duì)搶鎖導(dǎo)致請(qǐng)求堆積響應(yīng)越來(lái)越慢。把JVM的堆設(shè)到8G問題依然存在因?yàn)楦驹蚴谴a邏輯不是內(nèi)存不足。解決方案是重構(gòu)那段方法的鎖粒度去掉全局鎖改成線程局部變量和合適的并發(fā)容器同時(shí)優(yōu)化對(duì)象創(chuàng)建頻率減輕GC壓力。改完之后接口響應(yīng)時(shí)間和GC停頓直接掉到正常水平。這個(gè)案例給我最大的啟發(fā)是調(diào)優(yōu)不是先調(diào)參數(shù)而是先確認(rèn)問題出在JVM的哪一層。是堆分配問題、GC算法問題、類加載問題、JIT編譯問題還是純粹代碼問題方向錯(cuò)了加多少內(nèi)存都是白搭。6.3 線上調(diào)優(yōu)的實(shí)戰(zhàn)建議有一句忠告我要放在前面任何生產(chǎn)環(huán)境改動(dòng)JVM參數(shù)都要做小流量灰度驗(yàn)證。我見過有人只調(diào)了一個(gè)-Xmx值上線后發(fā)現(xiàn)頻繁Full GC因?yàn)槌绦蛟疽蕾嚧蠖丫彺鏀?shù)據(jù)堆縮了反而導(dǎo)致緩存不斷失效重新構(gòu)建業(yè)務(wù)數(shù)據(jù)要回源查詢性能反而更差。調(diào)優(yōu)的一般步驟可以歸納為先建立監(jiān)控基線搞清楚正常情況下的GC頻率、堆占用、CPU和響應(yīng)時(shí)間再根據(jù)突變的場(chǎng)景高并發(fā)、大數(shù)據(jù)量、內(nèi)存泄漏做定向分析最后小步修改參數(shù)每次只改一個(gè)變量對(duì)比前后效果。一次改一堆參數(shù)出了問題你根本不知道是誰(shuí)惹的禍。工具鏈上面jstat查看類加載和GC統(tǒng)計(jì)jmap導(dǎo)出堆快照jstack打印線程堆棧jcmd做各類診斷分析這些都是JDK自帶的部署環(huán)境里基本都可用。復(fù)雜一點(diǎn)的場(chǎng)景配合內(nèi)存分析工具打開dump文件定位問題熟練掌握這套流程對(duì)Java開發(fā)者是必修課。7. 常見錯(cuò)誤與排查思路速查表我在實(shí)際的Java開發(fā)與問題排查中遇到過很多很典型的“編譯運(yùn)行機(jī)制相關(guān)錯(cuò)誤”這里整理成一張速查表方便你對(duì)號(hào)入座?，F(xiàn)象可能原因處理方向ClassNotFoundException類加載器在classpath里找不到指定類檢查依賴是否缺失、打包是否完整、類加載器范圍是否對(duì)NoClassDefFoundError類在編譯期存在運(yùn)行期加載失敗初始化異?；蛞蕾嚾笔е攸c(diǎn)排查靜態(tài)初始化異常、依賴包版本沖突、類加載器重復(fù)加載StackOverflowError方法遞歸層數(shù)過深導(dǎo)致虛擬機(jī)棧溢出檢查遞歸終止條件和遞歸深度必要時(shí)調(diào)大-Xss但根本方法是改算法OutOfMemoryError: Java heap space堆內(nèi)對(duì)象過多或內(nèi)存泄漏用jmap導(dǎo)出堆dump分析對(duì)象引用鏈路OutOfMemoryError: Metaspace元空間放不下類元信息增加-XX:MaxMetaspaceSize排查動(dòng)態(tài)生成類反射、代理、熱部署是否過多頻繁Full GC老年代空間持續(xù)不足或存在大對(duì)象持續(xù)存活檢查GC日志、堆占用確認(rèn)是否存在對(duì)象過快晉升和內(nèi)存泄漏這些錯(cuò)誤看似五花八門骨子里都能追溯到“編譯產(chǎn)生的class文件、類加載器的加載路徑、JVM運(yùn)行時(shí)內(nèi)存劃分”這三個(gè)層面。所以我還是那句話編譯與運(yùn)行機(jī)制是根本問題表象再多根子大多在這。排查的時(shí)候我會(huì)給團(tuán)隊(duì)定一個(gè)簡(jiǎn)單的鐵律不要一上來(lái)就改參數(shù)先把日志和現(xiàn)場(chǎng)撈干凈再說。GC日志、異常堆棧、堆dump、線程快照這四樣?xùn)|西是定位問題的起點(diǎn)。沒有現(xiàn)場(chǎng)數(shù)據(jù)參數(shù)改來(lái)改去只是在碰運(yùn)氣尤其是在Java這種運(yùn)行期高度動(dòng)態(tài)的平臺(tái)上盲猜的效率極低。8. 結(jié)尾我的一點(diǎn)個(gè)人體會(huì)寫了這么多我想分享一個(gè)我個(gè)人特別深的體會(huì)Java程序的編譯與運(yùn)行機(jī)制最大的價(jià)值不體現(xiàn)在你背下了多少條JVM參數(shù)或者能畫出類加載流程圖而在于它能幫你建立一套“定位問題時(shí)的直覺”。線上出了問題你大概能猜到是堆不夠、GC停頓、類加載失敗、還是JIT編譯異常這個(gè)方向的判斷力靠刷題刷不出來(lái)只能在一次次和代碼、日志、字節(jié)碼打交道的過程里慢慢磨出來(lái)。如果今天這篇內(nèi)容只讓你記住三件事我希望是這三條第一javac編譯的終點(diǎn)是字節(jié)碼真正的機(jī)器碼翻譯發(fā)生在運(yùn)行期JIT手里第二類加載不是一啟動(dòng)就全部完成的它的懶加載和雙親委派決定了Java生態(tài)里很多詭異行為的底層原因第三堆、GC、參數(shù)這些屬于運(yùn)行時(shí)資源管理出了問題先看日志再動(dòng)參數(shù)方向比速度重要。最后再補(bǔ)一句實(shí)操經(jīng)驗(yàn)日常開發(fā)中養(yǎng)成隨手看字節(jié)碼和GC日志的習(xí)慣不需要多頻繁一個(gè)月認(rèn)真看一兩次就行?？吹枚嗔四銓?duì)Java程序的運(yùn)行情況會(huì)建立一種像老司機(jī)對(duì)車子引擎一樣的敏感度——一聽聲音就知道哪里不對(duì)勁。這比記住任何一份優(yōu)化模板都管用得多。