做了這么多年Java后端兜兜轉(zhuǎn)轉(zhuǎn)還是覺得JVM這塊最值得花時間去啃。不管你是剛接觸Java的新手還是已經(jīng)工作幾年的老開發(fā)JVM相關(guān)的問題總會以各種方式出現(xiàn)在你的面前——線上應(yīng)用突然內(nèi)存溢出、面試被問垃圾回收器選型、啟動時莫名其妙報錯。這篇筆記我就把JVM全體系的知識點串聯(lián)起來結(jié)合我實際踩過的坑和調(diào)優(yōu)經(jīng)驗整理成文希望能幫你少走一些彎路。內(nèi)容偏實操概念部分我也會講清楚背后的原理接著往下看。1. 內(nèi)容整體設(shè)計與思路拆解1.1 為什么JVM知識必須體系化學(xué)習(xí)很多人學(xué)JVM喜歡直接啃面試題比如JVM內(nèi)存模型是什么垃圾回收算法有哪些如何設(shè)置JVM參數(shù)背得滾瓜爛熟但一到線上出了問題還是無從下手。原因就在于面試題是碎片化的知識點而JVM本身是一個環(huán)環(huán)相扣的系統(tǒng)。舉個最典型的例子你只知道年輕代和老年代的比例卻不理解對象晉升的觸發(fā)條件那你在調(diào)優(yōu)時設(shè)置的-Xmn參數(shù)就完全是拍腦袋決定的而且拍完了還不知道對不對。我自己的體會是JVM學(xué)習(xí)必須沿著一條主線走從Java源碼編譯成字節(jié)碼到類加載機制把字節(jié)碼裝入運行時數(shù)據(jù)區(qū)再到執(zhí)行引擎逐條解釋執(zhí)行或即時編譯最后落到垃圾回收器對內(nèi)存進行自動管理。這條主線上每一個環(huán)節(jié)都會衍生出值得深入的知識點比如運行時數(shù)據(jù)區(qū)就是常說的JVM內(nèi)存模型類加載機制里面又牽扯到雙親委派模型垃圾回收又要講清楚G1和ZGC的區(qū)別。按照這條主線去梳理筆記你會發(fā)現(xiàn)前后知識點是能互相印證的學(xué)習(xí)效率會高很多。我在整理這份筆記時把整條主線又分成了三大部分內(nèi)存結(jié)構(gòu)與管理、類的生命周期與加載機制、垃圾收集與調(diào)優(yōu)實戰(zhàn)。每個部分內(nèi)部再往下拆比如垃圾收集部分會從最基礎(chǔ)的引用計數(shù)法講起然后到可達性分析再到各種垃圾收集器的演進。用這種金字塔式的結(jié)構(gòu)來記筆記面試前翻一遍能在腦子里快速建立起知識樹平時排查問題時也能順著樹枝快速定位到具體環(huán)節(jié)。1.2 這套筆記適合誰看以及能解決什么問題這份筆記面向的讀者大概有這么幾類第一類是準(zhǔn)備Java后端崗位面試的開發(fā)者JVM相關(guān)問題在面試中出現(xiàn)的頻率極高尤其是內(nèi)存模型、垃圾回收、類加載這幾個方向?qū)儆诒乜碱}第二類是剛接手線上服務(wù)運維的初級開發(fā)可能已經(jīng)遇到過幾次應(yīng)用重啟或者內(nèi)存告警但不太清楚要怎么分析和解決第三類是希望系統(tǒng)梳理JVM知識體系、補齊短期內(nèi)的中級開發(fā)者。這套筆記能解決三個層面的問題面試層面幫你把?？键c串成體系避免零散記憶實戰(zhàn)層面教你遇到OutOfMemoryError、頻繁Full GC時該用什么工具、按什么順序去排查原理層面讓你知道參數(shù)背后對應(yīng)的是哪一塊運行時數(shù)據(jù)區(qū)調(diào)整之后影響的是哪個環(huán)節(jié)。我見過太多人把-Xms和-Xmx設(shè)成一樣的值就以為完成了JVM調(diào)優(yōu)但實際連堆內(nèi)存使用率都不看這種參數(shù)潔癖式的調(diào)優(yōu)沒有實際意義。另一個容易被忽視的點是JVM知識體系和JDK版本強相關(guān)。JDK 8默認(rèn)的Parallel ScavengeJDK 11開始G1成為默認(rèn)收集器JDK 17則進一步優(yōu)化了ZGC。我在筆記里特意標(biāo)出了每個知識點在不同JDK版本下的差異避免讀者看清一色的舊版資料后拿JDK 11以上的環(huán)境去套JDK 8的默認(rèn)配置結(jié)果完全對不上號。2. 核心細(xì)節(jié)解析與實操要點2.1 JVM內(nèi)存模型理解一切調(diào)優(yōu)的基礎(chǔ)把JVM內(nèi)存模型放在整個體系的第一位因為它決定了你后面學(xué)的所有垃圾回收、參數(shù)調(diào)優(yōu)都會落在哪塊區(qū)域上。JVM在運行Java程序時會把它管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)域這些區(qū)域各有各的用途、創(chuàng)建時間和銷毀時間。很多人面試時背得很溜一畫圖就露餡原因是沒有理解每個區(qū)域的設(shè)計意圖。程序計數(shù)器是線程私有的行號指示器字節(jié)碼解釋器工作時就是通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令。分支、循環(huán)、跳轉(zhuǎn)、異常處理、線程恢復(fù)等基礎(chǔ)功能都需要依賴它。注意這里有個面試高頻考點程序計數(shù)器是唯一一個不會出現(xiàn)OutOfMemoryError的區(qū)域因為它的生命周期隨線程創(chuàng)建而創(chuàng)建、隨線程結(jié)束而消亡。Java虛擬機棧也是線程私有的生命周期和線程相同。棧里面存放的是一個個棧幀每個方法在執(zhí)行的同時會創(chuàng)建一個棧幀棧幀里存儲了局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口等信息。平時遇到的StackOverflowError就是在虛擬機棧深度超過JVM允許范圍時拋出的。我用一個生活化的類比來幫助理解如果把線程看作一條工廠流水線那虛擬機棧就是流水線上的工位一個方法調(diào)用就在工位上放一個加工單據(jù)方法返回就把單據(jù)拿走工位上的作業(yè)空間是固定有上限的。本地方法棧和虛擬機棧的作用非常相似區(qū)別在于虛擬機棧為Java方法服務(wù)本地方法棧為Native方法服務(wù)。HotSpot虛擬機把這兩者合二為一了所以在實際的JVM內(nèi)存模型中畫圖時通常畫成一塊。Java堆是JVM管理的最大的一塊內(nèi)存區(qū)域也是垃圾回收器重點關(guān)注的地方幾乎所有的對象實例都在這里分配。堆在物理上可以不連續(xù)只要邏輯上連續(xù)即可。從垃圾回收的角度堆又可以細(xì)分為新生代和老年代新生代里還有Eden區(qū)和Survivor區(qū)From和To這種劃分是為了更好地回收短期存活的對象。再看方法區(qū)它用于存儲已被虛擬機加載的類型信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼緩存等數(shù)據(jù)。JDK 8以后方法區(qū)被移到了元空間Metaspace不再使用堆內(nèi)存而是使用本地內(nèi)存。2.2 JVM參數(shù)設(shè)置這一步錯了應(yīng)用根本起不來JVM參數(shù)雖然只是一行行啟動命令但它的坑反而最多。我記得有一次幫同事排查一個Spring Boot應(yīng)用啟動失敗的問題現(xiàn)象是點擊啟動按鈕后控制臺直接報error invoking method. failed to launch jvm我第一反應(yīng)是JVM版本不匹配查了一圈才發(fā)現(xiàn)是IDEA里的VM options填了一個不存在的路徑參數(shù)JVM啟動時解析參數(shù)失敗直接中止。這種問題看著嚇人其實排查路徑很明確先確認(rèn)JDK本身能正常運行再確認(rèn)IDE或啟動腳本傳入的每一個參數(shù)都能被當(dāng)前JDK版本識別和支持。JVM參數(shù)大致可以分成三類標(biāo)準(zhǔn)參數(shù)以-開頭、非標(biāo)準(zhǔn)參數(shù)以-X開頭和非穩(wěn)定參數(shù)以-XX開頭。標(biāo)準(zhǔn)參數(shù)在所有JDK版本中都保持兼容比如-version、-classpath非標(biāo)準(zhǔn)參數(shù)是JDK特有的比如-Xms、-Xmx、-Xmn這些參數(shù)在未來的JDK版本中可能會調(diào)整但當(dāng)前版本是穩(wěn)定的-XX參數(shù)則是最不穩(wěn)定的比如-XX:UseG1GC、-XX:MaxMetaspaceSize不同版本之間可能有很大變化。實際工作中用得最多的是堆內(nèi)存相關(guān)的幾個參數(shù)-Xms初始堆大小、-Xmx最大堆大小、-Xmn新生代大小、-XX:MetaspaceSize元空間初始大小和-XX:MaxMetaspaceSize元空間最大大小。很多人會有疑問-Xms和-Xmx設(shè)置成不一樣的值好還是壞我的建議是生產(chǎn)環(huán)境直接設(shè)置成一樣的值避免JVM在運行期因為堆內(nèi)存使用波動而頻繁擴展或收縮堆大小這反而會帶來額外的性能開銷。注意這只是基于我實際運維經(jīng)驗的一種工程慣例如果你的應(yīng)用內(nèi)存占用有非常明顯的波峰波谷也可以保留JVM自動伸縮堆的能力具體情況具體分析。關(guān)于Cannot collect JVM options caused by: 0: cannot read:d:v作業(yè)實訓(xùn) vjetbrain_這類報錯我在這里也多說一句。這是典型的啟動工具在讀取JVM options配置時遇到了一個路徑字符串中包含特殊字符比如空格、冒號、中文導(dǎo)致讀取失敗。解決辦法很簡單檢查IDE或啟動腳本中配置的JVM options文件路徑把路徑用引號包起來或者挪到不包含特殊字符的目錄下。這不算什么高深問題但它出現(xiàn)的頻率真不低尤其是Windows環(huán)境下目錄命名比較隨意的情況。2.3 類加載機制JVM運行的物流系統(tǒng)我之前遇到過一個問題明明項目里有一個類運行時就報ClassNotFoundException找了半天才發(fā)現(xiàn)是打Jar包時沒有把依賴打進去。這就牽扯到類加載機制了。JVM的類加載器可以類比成物流系統(tǒng)里的調(diào)度中心負(fù)責(zé)把字節(jié)碼文件從磁盤或網(wǎng)絡(luò)加載到JVM內(nèi)存中并生成對應(yīng)的Class對象。類加載器之間是父子關(guān)系頂層是啟動類加載器Bootstrap ClassLoader加載JAVA_HOME/lib目錄下的核心類庫再往下是擴展類加載器Platform ClassLoader主要負(fù)責(zé)加載一些擴展的Jar包最下層是應(yīng)用類加載器App ClassLoader負(fù)責(zé)加載用戶類路徑上的所有類。這種層級關(guān)系的精髓在于雙親委派模型當(dāng)一個類加載請求到來時首先會把這個請求委派給父類加載器去完成每一層的父類加載器都無法完成時子加載器才會嘗試自己加載。雙親委派模型的好處很本質(zhì)它保證了Java核心類庫的類型安全。舉個例子如果你自己寫了一個java.lang.String類想混進JVM里替換核心類雙親委派模型會讓啟動類加載器優(yōu)先加載真正的java.lang.String你自定義的類根本沒機會被加載也就無法破壞核心類庫的結(jié)構(gòu)。很多人面試喜歡問如何打破雙親委派模型目的就是為了考察你是否真正理解了這個機制的邊界在哪里。常見的打破方式是自定義類加載器并重寫loadClass方法Tomcat就通過這種方式實現(xiàn)了多個Web應(yīng)用之間的類隔離。類加載過程本身又分為加載、驗證、準(zhǔn)備、解析、初始化五個階段。加載是找到字節(jié)碼文件并讀入內(nèi)存驗證是確保字節(jié)碼文件符合JVM規(guī)范防止惡意代碼準(zhǔn)備是為類變量分配內(nèi)存并設(shè)置初始值解析是把符號引用替換為直接引用初始化是執(zhí)行類構(gòu)造器clinit方法。我想指出一個容易混淆的細(xì)節(jié)準(zhǔn)備階段賦的是默認(rèn)值比如int類型是0不是你在代碼里寫的初始值實際賦初始值的操作發(fā)生在初始化階段。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 從零配置一份合理的JVM啟動參數(shù)先來走一遍生產(chǎn)環(huán)境JVM參數(shù)配置的完整實操。假設(shè)我們有一個Spring Boot應(yīng)用部署在4核8G的云服務(wù)器上目標(biāo)是支撐日均百萬級請求量的業(yè)務(wù)。在配置參數(shù)之前先要做一個粗略的資源規(guī)劃操作系統(tǒng)本身要留出1G左右的內(nèi)存剩下的內(nèi)存里JVM堆內(nèi)存可以分配4G到5G元空間固定256M線程棧大小根據(jù)業(yè)務(wù)特性設(shè)置。如果按照堆4G來配置我的啟動參數(shù)大致是這樣一組java -Xms4g -Xmx4g -Xmn2g \ -XX:MetaspaceSize256m \ -XX:MaxMetaspaceSize256m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis100 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/data/logs/jvm/heapdump.hprof \ -jar your-app.jar每個參數(shù)的含義拆開來看-Xms4g -Xmx4g把初始堆和最大堆都設(shè)為4G避免堆伸縮-Xmn2g設(shè)定2G的新生代新生代夠大短期對象基本都在新生代就被回收掉了不會頻繁晉升到老年代-XX:UseG1GC指定使用G1垃圾收集器它的優(yōu)勢在于可預(yù)測的停頓時間-XX:MaxGCPauseMillis100設(shè)定目標(biāo)GC停頓不超過100毫秒-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath是強烈建議配置的一旦發(fā)生內(nèi)存溢出自動導(dǎo)出堆轉(zhuǎn)儲文件這是事后排查的關(guān)鍵證據(jù)。這里有幾個要注意的點。第一-Xmn不是越大越好新生代太大意味著老年代被壓縮如果老年代空間不夠?qū)ο髸苯釉谀昀洗峙浠蛘哳l繁觸發(fā)Full GC。第二MaxGCPauseMillis只是一個軟目標(biāo)G1會盡量去滿足但在極端情況下它會放棄這個目標(biāo)優(yōu)先保證吞吐量所以不要以為設(shè)置了100毫秒就萬事大吉。第三MetaspaceSize別設(shè)太小很多框架比如Spring、MyBatis會生成大量動態(tài)代理類如果元空間上限設(shè)太低運行一段時間后會出現(xiàn)OutOfMemoryError: Metaspace。經(jīng)驗值一般從256M起步但也取決于你的項目復(fù)雜度和依賴數(shù)量。配置完成后最不能省的一步是壓測驗證。我會先用壓測工具比如JMeter模擬線上流量跑個十幾分鐘同時配合JVM監(jiān)控工具觀察堆內(nèi)存曲線和GC頻率。你設(shè)定參數(shù)的最終目的是讓應(yīng)用在最高峰流量時段內(nèi)Full GC頻率趨近于零Young GC頻率穩(wěn)定在幾十秒到幾分鐘內(nèi)一次服務(wù)響應(yīng)時間沒有明顯的毛刺。如果壓測發(fā)現(xiàn)老年代占用居高不下說明對象晉升得太早或太快可能需要調(diào)整新生代大小或者讓大對象直接在老年代分配。3.2 從Error invoking method到Cannot collect JVM options的排障實錄這張里我記幾個親測有效的排查過程它們都和IDE啟動Java程序相關(guān)現(xiàn)象相似但根因完全不同非常值得對比著看。案例一是error invoking method. failed to launch jvm。出現(xiàn)這個提示時我先在命令行里手動執(zhí)行java -version發(fā)現(xiàn)JDK正常工作。接著再看IDE里配置的JRE/JDK路徑發(fā)現(xiàn)項目SDK指向的是一個只裝了JRE的目錄JDK和JRE混用導(dǎo)致IDE找不到完整的運行時環(huán)境。這里你還需要分清楚JRE和JDK的關(guān)系JRE是Java運行時環(huán)境只包含JVM和核心類庫負(fù)責(zé)把Java程序跑起來JDK是Java開發(fā)工具包包含了JRE的全部內(nèi)容又額外提供了編譯器、調(diào)試器等開發(fā)工具。所以如果你的IDE項目SDK只指向JRE路徑那編譯調(diào)試功能會受限但通常啟動程序時如果只是運行模式有JRE也能跑。排障時要看得再細(xì)一層如果項目SDK路徑?jīng)]問題那再看啟動配置里的VM options很多時候報這個錯是因為參數(shù)里寫了當(dāng)前JDK版本不支持的-XX參數(shù)比如在JDK 8上寫了-XX:UseZGC啟動程序時JVM直接拒絕啟動。案例二是Cannot collect JVM options caused by: 0: cannot read:d:v作業(yè)實訓(xùn) vjetbrain_。這個報錯的字面意思就是JVM options收集失敗原因在于JVM options配置文件路徑無法讀取。我遇到的情況是IDE的VM options文件路徑指向了一個目錄但目錄名里含有空格和中文解析器在讀取時把路徑截斷了。解決辦法很簡單用文本編輯器打開IDE的配置文件找到VM options路徑配置項把路徑用英文雙引號整體包住。如果你根本不知道VM options文件在哪也可以在IDE里直接把啟動配置里的VM options清空改用程序內(nèi)代碼設(shè)置或環(huán)境變量設(shè)置避免文件路徑解析的問題。案例三是jvm reference can not find the corresponding jvm service。這個錯誤常見于使用了某些Java Agent插件或者容器化部署場景。它想表達的意思是JVM引用找不到對應(yīng)的JVM服務(wù)通常是啟動時嘗試連接JVM服務(wù)比如JMX、JVM attach機制失敗。排查思路是先確認(rèn)Java進程確實在運行再用jps命令查看本機Java進程ID最后檢查啟動參數(shù)里的-Dcom.sun.management.jmxremote相關(guān)配置是否正確。如果是在容器里跑還要確認(rèn)容器是否暴露了JMX端口很多環(huán)境里容器內(nèi)部網(wǎng)絡(luò)和宿主機網(wǎng)絡(luò)的端口映射不一致會導(dǎo)致外部監(jiān)控工具連接不上。3.3 JVM參數(shù)設(shè)置與調(diào)優(yōu)實戰(zhàn)工具箱再分享一套我平時做JVM調(diào)優(yōu)時一定會用到的工具鏈。不看數(shù)據(jù)就調(diào)參數(shù)都是耍流氓所以工具優(yōu)先級排在參數(shù)前面。JDK自帶的命令行工具永遠(yuǎn)是首選比如jps查看Java進程jstat查看GC情況和類加載統(tǒng)計jmap導(dǎo)出堆內(nèi)存快照jstack導(dǎo)出線程快照。線上排查時我最常用的組合是先用jps確認(rèn)進程號再用jstat -gcutil pid 1000每秒打印一次GC匯總信息能看到Eden、Survivor、老年代的使用百分比以及Young GC和Full GC的次數(shù)和耗時。如果發(fā)現(xiàn)Full GC次數(shù)多再用jmap -dump:formatb,fileheap.hprof pid導(dǎo)出堆快照交給MAT或者VisualVM分析對象引用鏈定位到底是哪塊業(yè)務(wù)代碼在瘋狂造對象。還有一個容易被忽略的工具是jcmd它可以算是jmap、jstack、jstat的集大成者很多JDK版本里官方推薦優(yōu)先使用jcmd。比如想看線程轉(zhuǎn)儲jcmd pid Thread.print就能搞定想看堆信息jcmd pid GC.heap_info也可以。線上事故處理時如果環(huán)境里只允許用一個工具我會選jcmd因為它一個命令能完成大多數(shù)診斷需求。調(diào)優(yōu)的流程也很有講究不要一上來就改參數(shù)。第一步先明確瓶頸是內(nèi)存不足是線程競爭還是GC停頓過高第二步用工具采集數(shù)據(jù)GC日志、堆轉(zhuǎn)儲、線程轉(zhuǎn)儲至少收集一份。第三步才是針對瓶頸做參數(shù)調(diào)整每次只改一兩個參數(shù)改完重新壓測對比不要一次改五六個參數(shù)否則出了問題你根本不知道是哪一個改壞的。關(guān)于GC日志別忘了在啟動參數(shù)里加上-Xlog:gc*:file/data/logs/jvm/gc.logJDK 9語法JDK 8用-XX:PrintGCDetails有了GC日志才能復(fù)盤每次GC行為。3.4 一堂課理解JVM面試必問的垃圾回收器垃圾回收是JVM面試題的重災(zāi)區(qū)但也是調(diào)優(yōu)繞不開的核心。我在筆記里整理了這樣一條技術(shù)演進線Serial - Serial Old - Parallel Scavenge - Parallel Old - CMS - G1 - ZGC。這條線的演進邏輯本質(zhì)上就是追求兩件事減少暫停時間提高吞吐量。這兩個目標(biāo)看似矛盾不同收集器只是在兩者之間做了不同取舍。Serial和Parallel系列都是分代收集器的典型代表新生代用復(fù)制算法老年代用標(biāo)記-整理或標(biāo)記-清除算法。Parallel Scavenge的設(shè)計目標(biāo)偏吞吐量優(yōu)先適合后臺計算任務(wù)它在JDK 8里是默認(rèn)收集器。CMSConcurrent Mark Sweep則追求最短停頓時間采用標(biāo)記-清除算法并發(fā)標(biāo)記和并發(fā)清除階段可以和業(yè)務(wù)線程一起跑代價是吞吐量下降而且CMS在JDK 9以后就被標(biāo)記為廢棄了。G1Garbage First是JDK 11以后的默認(rèn)收集器它的核心思路是把堆劃分成多個大小相等的Region在后臺維護一個優(yōu)先級列表優(yōu)先回收垃圾對象最多的Region。它不像傳統(tǒng)分代收集器那樣在物理上區(qū)分年輕代老年代而是讓每個Region動態(tài)扮演Eden、Survivor或Old的角色這種設(shè)計既保證了可預(yù)測的停頓時間又避免了CMS的碎片問題。ZGC則是面向超大堆TB級別的低延遲收集器停頓時間控制在10毫秒以內(nèi)原理上使用了著色指針和讀屏障技術(shù)理論要求遠(yuǎn)高于G1。面試題里經(jīng)常問怎么選擇垃圾回收器我會這么答如果追求最大吞吐量且不介意偶爾的長停頓選Parallel系列如果業(yè)務(wù)對延遲敏感GC停頓影響用戶體驗選G1并配合MaxGCPauseMillis設(shè)置期望停頓目標(biāo)如果堆內(nèi)存極大且延遲要求極高探索ZGC。這個回答能覆蓋大多數(shù)場景也能展示出你對不同收集器的適用邊界有真實理解。實際選擇時建議參考官方文檔和壓測結(jié)果不要人云亦云。4. 常見問題與排查技巧實錄把平時容易被問爆的、踩過坑的JVM問題整理成了速查表直接照著排查效率很高。問題現(xiàn)象可能原因建議排查方向啟動即報failed to launch jvmJDK/JRE路徑配置錯誤、VM options含非法參數(shù)先單獨執(zhí)行java -version再檢查IDE項目SDK路徑和啟動參數(shù)啟動報Cannot collect JVM optionsVM options配置文件路徑無法讀取含空格或中文用引號包住路徑或清理路徑中的特殊字符運行中報OutOfMemoryError: Java heap space堆內(nèi)存不足或內(nèi)存泄漏導(dǎo)出堆快照用MAT分析大對象引用鏈檢查-Xmx是否合理運行中報OutOfMemoryError: Metaspace元空間不足或動態(tài)類生成過多增大-XX:MaxMetaspaceSize檢查是否有類加載器泄漏頻繁Full GCGC日志顯示老年代占滿對象晉升過快、有大對象直接進入老年代觀察Survivor區(qū)大小與晉升閾值考慮調(diào)整-Xmn或-XX:MaxTenuringThreshold應(yīng)用響應(yīng)慢但CPU占用不高線程阻塞、死鎖或鎖競爭使用jstack抓線程快照分析BLOCKED狀態(tài)線程和鎖等待關(guān)系JMX監(jiān)控連接不上報cannot find the corresponding jvm service端口未開放或JVM attach機制失敗檢查JMX端口映射使用jps確認(rèn)進程是否存活我在這份表格里想特別強調(diào)-XX:MaxTenuringThreshold這個參數(shù)。它控制的是對象在年輕代熬過多少次Young GC后晉升到老年代默認(rèn)值在HotSpot里通常是15。但如果你發(fā)現(xiàn)老年代增長過快且老年代對象大多不是大對象可以適當(dāng)降低這個閾值或反過來調(diào)大但這必須配合對象年齡分布的數(shù)據(jù)來判斷。直接用-Xlog:gcagetrace可以打印對象年齡分布看到底是哪幾個年齡段的對象占比高再決定要不要調(diào)整閾值。另一個值得單獨拎出來講的問題是OutOfMemoryError的分型。很多人一看到OOM就想著加內(nèi)存這是最常見的誤區(qū)。OOM分好幾種Java heap space說明堆內(nèi)存不夠可能是內(nèi)存泄漏或者業(yè)務(wù)量真的超出預(yù)期Metaspace說明元空間不夠unable to create new native thread說明操作系統(tǒng)無法創(chuàng)建新線程往往是線程數(shù)打滿了還可能是操作系統(tǒng)級限制GC overhead limit exceeded說明JVM一直忙于GC但收效甚微是內(nèi)存泄漏的強信號。加-Xmx只能短期掩蓋前兩種問題真正要治本必須分析堆轉(zhuǎn)儲找到泄漏源。排查時我還會用到一個小技巧打開GC日志后關(guān)注Young GC之后老年代的占用變化。正常情況下老年代占用應(yīng)該平穩(wěn)如果每次Young GC后老年代都明顯增長說明大量對象歲數(shù)沒到就提前晉升了這時候要懷疑Survivor空間太小對象在Survivor區(qū)裝不下直接被提升。相應(yīng)的調(diào)整方向是增加-Xmn或者提高Survivor區(qū)比例讓存活的對象有足夠空間在新生代完成多輪回收。再補一個容易被忽略的點線程棧大小-Xss。默認(rèn)值在大多數(shù)平臺上是1M對于業(yè)務(wù)中大量使用遞歸或者深方法調(diào)用鏈的場景1M可能不夠用會出現(xiàn)StackOverflowError但隨便改大這個值也不是好事因為線程棧是從操作系統(tǒng)內(nèi)存中分配的線程數(shù)一多內(nèi)存消耗巨大。一個典型場景是服務(wù)器上線程數(shù)達到幾百上千每個線程棧1M光線程棧就要占幾百M甚至幾G內(nèi)存。所以如果應(yīng)用是IO密集型、線程數(shù)多、調(diào)用鏈不深反而可以考慮調(diào)小-Xss來節(jié)省內(nèi)存比如-Xss512k讓同樣的物理內(nèi)存能支撐更多線程。# 一個實用的JVM GC日志查看命令示例按每10次GC匯總一次采樣數(shù)據(jù) jstat -gcutil pid 1000 10輸出結(jié)果里FGC列代表Full GC次數(shù)FGCT列代表Full GC累計耗時GCT代表所有GC累計耗時。如果FGC在短時間內(nèi)漲得很快或者FGCT數(shù)值異常高那基本可以判斷GC出了問題繼續(xù)往下抓堆快照就行了。5. 深入追問JVM原理層面那些面試官想聽的東西如果你準(zhǔn)備的是高級崗位的面試只背參數(shù)和工具是不夠的。面試官往往還會圍繞JVM原理問幾個為什么這里我把高頻追問也整理一遍。5.1 為什么說Java是跨平臺的跨的到底是什么很多人張口就來Java跨平臺是因為JVM但面試官就是想聽更完整的鏈路.java源文件通過各種編譯器比如javac編譯成字節(jié)碼文件字節(jié)碼是JVM的指令集和操作系統(tǒng)、CPU架構(gòu)無關(guān)不同平臺安裝不同版本的JVMJVM負(fù)責(zé)把字節(jié)碼翻譯成本地機器指令。所以跨平臺的是Java字節(jié)碼和JVM這一整套運行時規(guī)范不是編譯后的機器碼本身。換個說法你拿到一份.class文件在任何安裝了對應(yīng)JDK/JRE的平臺上都能直接運行這才叫跨平臺。5.2 為什么需要JIT即時編譯器解釋執(zhí)行字節(jié)碼效率不高所以HotSpot引入了JITJust-In-Time編譯器。當(dāng)某個方法被頻繁調(diào)用時JIT會把它編譯成機器碼并緩存下來下次直接執(zhí)行機器碼速度大幅提升。這就是熱點代碼的概念也解釋了為什么Java應(yīng)用剛啟動時性能通常差一些隨著時間推移越跑越快。JIT有兩種主流模式C1編譯器Client模式編譯速度快但優(yōu)化程度一般C2編譯器Server模式編譯慢但優(yōu)化徹底。高版本JDK還在推進GraalVM作為新一代JIT編譯器這是一個值得關(guān)注的演進方向。5.3 為什么元空間替換了永久代永久代PermGen是JDK 8以前方法區(qū)的實現(xiàn)但它有個致命缺陷占用JVM堆內(nèi)存大小難以精確控制經(jīng)常因為加載大量類就拋OutOfMemoryError: PermGen space。元空間Metaspace的核心變化是使用本地內(nèi)存默認(rèn)情況下大小只受宿主機可用內(nèi)存限制這就避免了永久代那種明明機器內(nèi)存還多JVM卻先死了的尷尬。改到元空間后JDK自身也需要動態(tài)生成大量內(nèi)部類不再受堆大小的約束穩(wěn)定性明顯改善。5.4 為什么線上環(huán)境GC日志和HeapDump一定要開我不止一次在排查線上問題時因為GC日志缺失而抓瞎。HeapDumpOnOutOfMemoryError也是同樣重要的護身符一旦程序因為OOM掛掉至少能留下一份堆快照文件你可以復(fù)盤是哪個方法導(dǎo)致了內(nèi)存暴漲。如果這兩個都沒開進程一掛你只能靠監(jiān)控面板上的歷史曲線去猜效率天差地別。另外在容器環(huán)境里跑Java應(yīng)用還有一個和以前不一樣的點容器會限制CPU和內(nèi)存但JVM不是總能自動識別容器的資源限制。JDK 8u191以前的版本JVM默認(rèn)可能看到的是宿主機全部內(nèi)存導(dǎo)致-Xmx設(shè)大了容器直接被殺JDK 8u191及以后增加了-XX:UseContainerSupport默認(rèn)開啟來自動感知容器配額。所以如果你用低版本JDK跑容器切記升級版本或手動設(shè)置合理的堆內(nèi)存參數(shù)否則會出現(xiàn)應(yīng)用沒報OOM但容器反復(fù)被殺重啟的詭異現(xiàn)象。6. 聊聊我整理這套JVM筆記踩過的一些坑最后這部分不按知識體系來就說幾個我在實際整理和學(xué)習(xí)過程中印象最深的教訓(xùn)希望你能繞開。第一個教訓(xùn)是參數(shù)別照抄網(wǎng)上配置。網(wǎng)上那些-Xms8g -Xmx8g -Xmn4g的配置看著大氣但你的應(yīng)用根本用不了那么大堆內(nèi)存時反而會帶來問題。我見過一個小應(yīng)用被設(shè)置了8G堆結(jié)果GC掃描的Region數(shù)量比正常情況多好幾倍停頓時間更長性能不升反降。JVM參數(shù)沒有銀彈一切以你的壓測數(shù)據(jù)和監(jiān)控數(shù)據(jù)為準(zhǔn)。第二個教訓(xùn)是JDK版本之間的坑。網(wǎng)上很多文章寫于JDK 8時代里面的默認(rèn)垃圾收集器、永久代這些說法放到JDK 17上早就不成立了。整理筆記時我特意對照了多個版本的官方文檔確保每個知識點都標(biāo)明了適用的JDK版本范圍。你自己學(xué)習(xí)時也要養(yǎng)成看官方文檔的習(xí)慣尤其是JEP里關(guān)于垃圾回收器的描述比任何二手資料都可靠。第三個教訓(xùn)是學(xué)會看原始GC日志別只看監(jiān)控大屏。監(jiān)控面板上的GC曲線很好用但很多細(xì)節(jié)必須回看原始日志才能定位比如對象晉升的年齡分布、每次GC前后各區(qū)域的使用量變化、GC導(dǎo)致的用戶線程停頓耗時。這些信息在匯總面板里往往被壓縮成平均值真實的問題反而被平滑掉了。有一次定位頻繁Young GC問題我就是在原始日志里發(fā)現(xiàn)Survivor區(qū)在每次GC前都已經(jīng)滿了屬于典型的Survivor空間配置過小這種信息光看監(jiān)控面板很難推斷出來。第四個教訓(xùn)是心態(tài)層面的JVM調(diào)優(yōu)不是炫技是拿數(shù)據(jù)說話。不要為了調(diào)而調(diào)先看業(yè)務(wù)有沒有問題再看監(jiān)控數(shù)據(jù)有沒有異常最后才動手改參數(shù)。很多應(yīng)用默認(rèn)參數(shù)就能跑得很好亂調(diào)參數(shù)反而制造新問題。這套筆記整理下來我自己最大的收獲其實不是記住了多少個參數(shù)而是形成了一套先測量、再分析、最后調(diào)整的思維方式這套方式在做任何性能優(yōu)化時都通用。我目前還在持續(xù)完善這份JVM筆記比如GC日志里那些詳細(xì)字段的含義、ZGC在JDK 17下的實際表現(xiàn)、GraalVM原生鏡像的優(yōu)缺點對比后續(xù)有新的實測數(shù)據(jù)也會繼續(xù)回來更新這篇文章。如果你在照著配置參數(shù)或者排查問題時遇到了別的怪問題歡迎在評論區(qū)和我說說具體情況我們一起把這份實操經(jīng)驗庫補得更全。