開頭先給結(jié)論JVM 這塊內(nèi)容大廠面試真正要考察的并不是你能背出幾條命令而是你能否把內(nèi)存模型、GC、STW、線上診斷工具和高并發(fā)場景串成一條完整鏈路。比如面試官問你 G1 和 CMS 的區(qū)別不是等你背參數(shù)而是想聽你判斷“什么場景下選誰、STW 壓到多少算合理、線上 OOM 之后第一步做什么”。這篇文章會圍繞 JVM 內(nèi)存模型、GC 收集器、STW 問題、Arthas 調(diào)優(yōu)和高并發(fā)電商項目實戰(zhàn)把大廠面試題里最容易卡人的點拆開講清楚。我自己見過不少準(zhǔn)備 JVM 面試的人堆棧溢出、類加載、可達(dá)性分析這些概念背得很熟但一碰到“線上系統(tǒng)頻繁 Full GC 怎么排查”“Docker 里部署的 Java 程序異常重啟后日志去哪找”這類場景題就接不住。原因很簡單沒有把知識點變成排錯動作。所以這篇內(nèi)容我會按“概念 → 參數(shù) → 實戰(zhàn) → 排錯”的順序來寫適合正在準(zhǔn)備大廠面試的 Java 工程師也適合工作中需要處理線上 JVM 問題的后端開發(fā)。1. 先分清 JDK、JRE、JVM再談內(nèi)存模型1.1 這道“送分題”為什么總有人答錯很多面試資料把 JDK、JRE、JVM 的區(qū)別列為最基礎(chǔ)的一題但真到面試時反而有不少人說不清楚。JVM 是 Java Virtual MachineJava 虛擬機負(fù)責(zé)把字節(jié)碼解釋或編譯成機器指令來執(zhí)行。JRE 是 Java Runtime EnvironmentJava 運行時環(huán)境包含 JVM 和 Java 核心類庫。JDK 是 Java Development KitJava 開發(fā)工具包包含 JRE還額外包含編譯器 javac、診斷工具 jstack、jmap、jstat、可視化工具 JConsole 等。簡單說JDK 是給開發(fā)者用的JRE 是給運行 Java 程序的人用的JVM 是真正執(zhí)行字節(jié)碼的那一層。面試?yán)锖苋菀鬃冃螁柗ū热纭耙粋€只需要運行 Java 程序的服務(wù)器應(yīng)該裝 JDK 還是 JRE”“為什么生產(chǎn)環(huán)境直接用 JDK 而不是精簡 JRE”。前者答案明確后者要結(jié)合實際情況很多中間件、Agent 工具、動態(tài)編譯場景會用到 JDK 自帶工具所以生產(chǎn)環(huán)境裝完整 JDK 更省事。不過 Oracle JDK 和 OpenJDK 在發(fā)行版上有授權(quán)和更新策略差別這塊要以實際使用的版本和公司規(guī)定為準(zhǔn)。1.2 JVM 內(nèi)存模型和 Java 內(nèi)存模型 JMM 是兩回事這是高頻混淆點。JVM 內(nèi)存模型指的是運行時數(shù)據(jù)區(qū)包括堆、虛擬機棧、本地方法棧、方法區(qū)HotSpot 里叫元空間 Metaspace和程序計數(shù)器。JMM 是 Java Memory ModelJava 內(nèi)存模型它定義的是多線程場景下共享變量的可見性、有序性和原子性規(guī)則核心是 happens-before 原則和主內(nèi)存、工作內(nèi)存的交互。面試時如果只把 JVM 內(nèi)存模型和 JMM 混在一起說會被認(rèn)為概念不清晰。正確答法是JVM 內(nèi)存模型回答“對象存在哪、線程棧在哪、元空間在哪”JMM 回答“多線程讀寫共享變量時一個線程的修改什么時候?qū)α硪粋€線程可見”。1.3 初始啟動參數(shù)里最常用的幾個堆內(nèi)存配置不管面試還是調(diào)優(yōu)堆內(nèi)存參數(shù)都繞不開。常見配置如下-Xms堆初始大小一般和-Xmx設(shè)成一樣避免運行時擴(kuò)容引起抖動。-Xmx堆最大大小。-Xmn年輕代大小。-XX:MetaspaceSize元空間初始大小。-XX:MaxMetaspaceSize元空間最大大小。-XX:HeapDumpOnOutOfMemoryErrorOOM 時自動導(dǎo)出堆快照。-XX:HeapDumpPath堆快照輸出路徑。-XX:CompileThreshold方法調(diào)用多少次后觸發(fā) JIT 編譯這是一個容易被忽略的參數(shù)。之前看過一個線上問題服務(wù)在啟動后頻繁卡頓日志里沒有明顯異常后來用 jstat 看編譯狀態(tài)才發(fā)現(xiàn)-XX:CompileThreshold被調(diào)得很低方法調(diào)用次數(shù)很容易觸發(fā) JIT 編譯導(dǎo)致 CPU 飆升。這種參數(shù)平時不會被注意到但面試官如果問起“JIT 和解釋執(zhí)行你怎么調(diào)優(yōu)”它就是一個得分點。2. 運行時數(shù)據(jù)區(qū)內(nèi)存模型里的每一步都對應(yīng)參數(shù)2.1 堆、棧、方法區(qū)的真實分工運行時數(shù)據(jù)區(qū)是 JVM 面試的第一道主菜。要理解它不能只背名字得知道每個區(qū)域存什么什么情況下報錯。程序計數(shù)器占內(nèi)存很小記錄當(dāng)前線程執(zhí)行的字節(jié)碼行號線程私有不會 OOM。虛擬機棧描述 Java 方法執(zhí)行的內(nèi)存模型每次方法調(diào)用創(chuàng)建一個棧幀棧幀里有局部變量表、操作數(shù)棧、動態(tài)鏈接、方法返回地址。棧深度超過限制拋 StackOverflowError棧擴(kuò)展申請不到內(nèi)存拋 OutOfMemoryError。本地方法棧服務(wù)于 native 方法HotSpot 把本地方法棧和虛擬機棧合在一起。堆是所有線程共享的區(qū)域存放對象實例GC 的主要回收區(qū)域。方法區(qū)在 JDK 8 之后被元空間替代存放類元信息、靜態(tài)變量、常量池等默認(rèn)使用本地內(nèi)存?；卮饡r要能說出關(guān)鍵變化JDK 8 之后字符串常量池移到了堆永久代沒有了類元數(shù)據(jù)放到元空間。2.2 對象創(chuàng)建過程和高頻面試題“對象怎么分配”對象創(chuàng)建流程通常是類加載檢查 → 分配內(nèi)存 → 初始化零值 → 設(shè)置對象頭 → 執(zhí)行構(gòu)造方法。內(nèi)存分配方式有指針碰撞和空閑列表兩種取決于堆是否規(guī)整CMS 使用空閑列表Serial、Parallel 等使用指針碰撞。并發(fā)環(huán)境下分配內(nèi)存要有同步手段CAS 加失敗重試或本地線程分配緩沖 TLAB。大對象直接進(jìn)入老年代可以通過-XX:PretenureSizeThreshold設(shè)置閾值。長期存活的對象達(dá)到-XX:MaxTenuringThreshold指定年齡后進(jìn)入老年代。動態(tài)年齡判定則是 Survivor 中同年齡對象大小總和超過 Survivor 空間一半時大于等于該年齡的對象直接進(jìn)入老年代。面試官經(jīng)常追問為什么大對象直接進(jìn)老年代因為大對象在年輕代里復(fù)制成本高來回在 Eden 和 Survivor 之間拷貝容易觸發(fā) Minor GC直接放到老年代更省事。但又要注意如果對象本身是短期大對象直接進(jìn)老年代會加速 Full GC。2.3 從參數(shù)看堆分區(qū)Eden、Survivor、老年代年輕代默認(rèn)由 Eden 加兩個 Survivor 組成比例通常通過-XX:SurvivorRatio控制默認(rèn) 8:1:1。但不要盲目相信默認(rèn)值需要實際驗證因為不同 JVM 版本和 GC 策略下可能不同。Minor GC 發(fā)生在年輕代Major GC 清理老年代Full GC 一般指回收整個堆和方法區(qū)。這里有一個常見誤解Major GC 和 Full GC 經(jīng)常被混用但 Full GC 通常會伴隨 STW 且停頓更長。G1 出現(xiàn)后又有了 Young GC、Mixed GC、Full GC 三種動作必須按收集器分開講。3. GC 和 STW從判定垃圾到一次完整回收3.1 引用計數(shù)和可達(dá)性分析怎么選判斷對象是否可回收最?？嫉氖强蛇_(dá)性分析算法。從 GC Roots 出發(fā)沿著引用鏈往下找能被找到的對象就是存活對象找不到的就是垃圾。GC Roots 包括虛擬機棧中引用的對象、靜態(tài)屬性引用的對象、常量引用的對象、本地方法棧中 native 方法引用的對象以及處于同步鎖中的對象等。引用計數(shù)算法因為無法解決循環(huán)引用問題主流 JVM 不用它。比如對象 A 引用了 BB 又引用了 A兩個對象都被外部斷開后引用計數(shù)仍不為零就永遠(yuǎn)不會被回收。引用類型也是必考項強引用、軟引用、弱引用、虛引用。軟引用在內(nèi)存不足時回收適合做緩存弱引用每次 GC 都會被回收虛引用主要用來跟蹤對象回收狀態(tài)比如堆外內(nèi)存的回收通知。3.2 年輕代到老年代的晉升鏈路一次對象回收過程可以這樣描述對象先分配在 Eden 區(qū)Eden 滿時觸發(fā) Minor GC。Minor GC 采用復(fù)制算法把存活對象復(fù)制到 Survivor 區(qū)同時年齡加 1。對象在 Survivor 區(qū)里每經(jīng)過一次 Minor GC 年齡加 1默認(rèn)到 15 歲進(jìn)入老年代。Survivor 不夠時會通過分配擔(dān)保直接進(jìn)入老年代。需要記住年齡閾值可以通過-XX:MaxTenuringThreshold調(diào)整但動態(tài)年齡判定優(yōu)先。如果 Survivor 里同年齡對象總大小超過一半就提前晉升不一定非得等到 15 歲。3.3 STW 到底是什么能不能完全消除STWStop The World指的是 GC 發(fā)生時JVM 必須暫停所有業(yè)務(wù)線程讓 GC 線程執(zhí)行回收。為什么必須暫停因為如果業(yè)務(wù)線程繼續(xù)修改對象引用可達(dá)性分析會一直處于變化狀態(tài)無法確定哪些對象是真正可回收的。STW 不是越短越好但也不是越長越好關(guān)鍵是業(yè)務(wù)能否接受。CMS 和 G1 都在壓縮 STWZGC 的目標(biāo)是把停頓控制在毫秒級甚至更低。但所謂“并發(fā)”只是把一部分標(biāo)記、清理動作和業(yè)務(wù)線程并發(fā)執(zhí)行最終停頓還是存在只是停頓范圍變小了。線上有印象很深的案例某接口平時 50ms 返回一天內(nèi)偶爾出現(xiàn) 2 到 3 秒的尖峰查日志發(fā)現(xiàn)每次尖峰都伴隨 Full GC。后來發(fā)現(xiàn)是緩存對象在高峰期集中過期老年代被大量一次性對象塞滿頻繁觸發(fā) Full GC。處理辦法是拆大緩存、錯開過期時間、適當(dāng)調(diào)大堆內(nèi)存并切到 G1。這類問題就是“STW 導(dǎo)致接口卡頓”的典型。3.4 GC Overhead Limit Exceeded 到底指什么熱搜詞里有一條java.lang.OutOfMemoryError: GC overhead limit exceeded這是線上非常常見的 OOM 類型。意思是 GC 一直在執(zhí)行但回收效果太差JVM 擔(dān)心繼續(xù)跑下去只是空轉(zhuǎn)于是在 GC 時間占比超過 98% 且回收不到 2% 堆內(nèi)存時直接拋出 OOM。遇到這個錯誤不要先去加堆內(nèi)存而是先導(dǎo)出堆快照分析對象占用。常見原因有代碼里存在大量臨時對象循環(huán)創(chuàng)建、緩存未設(shè)置過期時間、內(nèi)存泄漏導(dǎo)致老年代不斷增長、批處理任務(wù)一次性加載太多數(shù)據(jù)。排查順序是先看堆快照再查大對象和線程堆棧最后定位到具體方法和接口。4. CMS、G1、ZGC大廠面試如何對比收集器4.1 CMS 為什么被稱為“并發(fā)收集但也會 STW”CMSConcurrent Mark Sweep目標(biāo)是減少停頓。它分為初始標(biāo)記、并發(fā)標(biāo)記、重新標(biāo)記、并發(fā)清除四個階段。初始標(biāo)記需要 STW但只標(biāo)記 GC Roots 直接引用的對象很快并發(fā)標(biāo)記和業(yè)務(wù)線程并發(fā)執(zhí)行重新標(biāo)記需要 STW用于修正并發(fā)標(biāo)記期間業(yè)務(wù)線程修改的引用并發(fā)清除回收垃圾對象。CMS 的缺點很明顯使用標(biāo)記清除算法會產(chǎn)生內(nèi)存碎片并發(fā)階段占用 CPU不能處理浮動垃圾可能觸發(fā) Concurrent Mode Failure 然后退化為 Serial Old 的 Full GC。面試官問到 CMS通常希望你提到碎片問題和退化風(fēng)險而不只是背四個階段。4.2 G1 如何把堆切成 RegionG1 把堆劃分為多個大小相等的 Region 區(qū)域每個 Region 可以是年輕代、老年代或者大對象區(qū)邏輯上不再要求物理連續(xù)。G1 的回收過程包含 Young GC 和 Mixed GC。Young GC 回收年輕代 RegionMixed GC 同時回收部分老年代 Region目標(biāo)是控制停頓時間。G1 通過-XX:MaxGCPauseMillis參數(shù)指定期望停頓時間默認(rèn) 200ms 左右。但要注意這只是一個軟目標(biāo)不是硬保證。G1 會優(yōu)先回收垃圾最多的 Region這就是所謂的 Garbage First 策略既控制停頓又能提升回收效率。大廠面試考察 G1 時喜歡問“什么場景下選 G1 而不是 CMS”。如果堆很大比如 16G 以上且對停頓時間有要求G1 通常更合適。如果堆只有 4G應(yīng)用本身對停頓不敏感繼續(xù)用默認(rèn)收集器也未必有問題。關(guān)鍵是結(jié)合堆大小、停頓訴求和 CPU 資源綜合判斷。4.3 ZGC 為什么能把 STW 壓到毫秒級ZGC 是 JDK 11 引入的實驗性收集器JDK 15 開始正式支持。它把停頓時間控制在極低水平核心手段是染色指針和讀屏障。ZGC 的標(biāo)記、轉(zhuǎn)移階段大部分和業(yè)務(wù)線程并發(fā)執(zhí)行GC 線程通過讀屏障處理對象訪問引用減少業(yè)務(wù)線程停頓。ZGC 也有代價它更依賴內(nèi)存帶寬CPU 占用比 G1 高而且對大堆場景更友好。小堆場景用 ZGC 不一定會比 G1 好因為并發(fā)處理本身有額外開銷。面試被問到 ZGC可以說“低停頓、適合大堆和追求響應(yīng)延遲的互聯(lián)網(wǎng)服務(wù)但需要額外評估 CPU 成本和兼容性”。4.4 三款收集器對比表下面這份表格適合直接記憶但面試時要展開講原因。收集器回收算法是否并發(fā)標(biāo)記STW 特點適用場景CMS標(biāo)記清除是初始標(biāo)記和重新標(biāo)記需要 STW堆中等大小追求低停頓G1Region 復(fù)制是停頓可預(yù)測按 Region 回收大堆停頓敏感JDK 8 后期版本常用ZGC染色指針 讀屏障是停頓極短毫秒級超大堆極低延遲要求需要特別說明CMS 在 JDK 9 開始廢棄JDK 14 被移除。現(xiàn)在很多老項目還在用 JDK 8所以 CMS 依然會被面試官問但真正新項目已經(jīng)不太可能選它了。G1 從 JDK 9 開始是默認(rèn)收集器JDK 8 環(huán)境下需要顯式開啟。5. Arthas 實戰(zhàn)線上 JVM 問題不能全靠猜5.1 Arthas 是什么怎么下載和啟動Arthas 是阿里巴巴開源的一款 Java 在線診斷工具不需要重啟服務(wù)就能查看類加載、方法調(diào)用、參數(shù)值、異常、線程狀態(tài)和 CPU 占用。它特別適合處理“本地復(fù)現(xiàn)不了只能線上看”的問題。Arthas 下載可以直接去 GitHub Releases 拿arthas-boot.jar日常用法是java -jar arthas-boot.jar啟動后會出現(xiàn)一個進(jìn)程列表輸入對應(yīng)序號就可以 attach 到目標(biāo) Java 進(jìn)程。如果機器上只有一個 Java 進(jìn)程通常直接連接。需要注意Arthas 需要和目標(biāo)進(jìn)程有相同用戶權(quán)限普通用戶 attach 其他用戶的進(jìn)程可能失敗。5.2 Arthas 啟動時無法獲取 jps 進(jìn)程怎么辦熱搜里有一條“arthas 啟動無法獲取 jps 進(jìn)程”這個很常見。原因通常是當(dāng)前用戶看不到目標(biāo)進(jìn)程或者目標(biāo)進(jìn)程不在當(dāng)前用戶會話下又或者 JDK 的 jps 和實際運行環(huán)境不一致。排查順序是先用jps -l看看能不能列出進(jìn)程如果 jps 都看不到確認(rèn) JAVA_HOME 和 PATH 是否配置正確進(jìn)程是不是跑在 Docker 容器里容器內(nèi)有沒有安裝完整 JDK如果 jps 能看到但 Arthas 列不出嘗試直接指定 pid使用java -jar arthas-boot.jar pid。還有一種情況是權(quán)限問題容器內(nèi)以 root 跑的 Java 進(jìn)程外部普通用戶 attach 會被拒絕。如果是 Docker 容器部署的 Java 程序需要先進(jìn)入容器再執(zhí)行 Arthas或者把 Arthas 提前放到容器鏡像里。容器內(nèi)沒有 jps 時可以手動找進(jìn)程號ps -ef | grep java # 或 cat /proc/進(jìn)程號/cmdline用jstack抓線程棧也可以但要先確認(rèn)有權(quán)限。5.3 用 dashboard、thread、heapdump 定位線上問題Arthas 里最常用的命令是dashboard它展示當(dāng)前進(jìn)程的整體狀態(tài)CPU 占用、內(nèi)存、GC 次數(shù)、線程數(shù)量。執(zhí)行方式是在 Arthas 交互環(huán)境中輸入dashboard按q退出。thread命令可以查看所有線程的狀態(tài)和 CPU 占用。比如thread -n 3這條命令會顯示 CPU 占用最高的前三個線程。如果某個線程一直處于 BLOCKED 狀態(tài)基本能判斷存在鎖競爭。再加參數(shù)thread -b可以找出當(dāng)前阻塞其他線程的鎖這對排查死鎖和鎖競爭非常有用。堆內(nèi)存方面Arthas 也提供了heapdump命令可以先執(zhí)行heapdump /tmp/heap.hprof然后導(dǎo)入 MAT 或 JProfiler 分析。不過我一般建議先用vmmap或jmap導(dǎo)出堆快照Arthas 的heapdump更適合已經(jīng)進(jìn)入 Arthas 交互環(huán)境后快速導(dǎo)出。5.4 用 trace、watch 跟蹤方法調(diào)用和 URL 路徑熱搜詞里有一句“Arthas 可以跟蹤 url 的調(diào)用路徑嗎”。可以直接說Arthas 不能直接像網(wǎng)關(guān)一樣從 URL 維度跟蹤整個調(diào)用鏈但可以借助trace和watch組合做到方法級鏈路追蹤。思路是先用trace跟蹤 Controller 方法的調(diào)用路徑看每個內(nèi)部方法的耗時trace com.example.controller.OrderController createOrder如果只關(guān)心某個方法的入?yún)⒑头祷刂涤脀atch com.example.service.OrderService createOrder {params, returnObj} -x 3如果想知道某個異常在哪個 URL 下被拋出可以 watch 異常watch com.example.service.OrderService createOrder throwExp {params, throwExp} -x 3這種方式可以把“某個 URL 請求”和“具體方法參數(shù)、異常、耗時”對應(yīng)起來前提是你能定位到入口方法。如果項目里用的是 Dubbo配合 Arthas 的trace也能看到 RPC 調(diào)用路徑。6. 大廠面試原題從 OOM 到高并發(fā)調(diào)優(yōu)6.1 GC 頻繁發(fā)生在哪個區(qū)怎么定位面試題常見問法“線上系統(tǒng) GC 頻繁你怎么定位?！被卮鹨袑哟蜗扔胘stat -gcutil pid 1000看各代 GC 次數(shù)和耗時。再用jmap -dump:formatb,file/tmp/heap.hprof pid導(dǎo)出堆快照。用 MAT 分析對象大小查找是大對象、緩存增長還是內(nèi)存泄漏。同時看線程堆棧確認(rèn)是不是大量并發(fā)請求導(dǎo)致對象激增。如果是 Full GC 頻繁重點看老年代占用率是否持續(xù)高位。老年代一直不降基本可以懷疑兩類問題長期存活對象過多或者存在內(nèi)存泄漏。前者通過調(diào)整堆比例或回收策略后者必須查代碼。6.2 億級電商高并發(fā)場景下JVM 怎么優(yōu)化大廠面試喜歡結(jié)合“億級電商、高并發(fā)”來問比如“雙十一大促前你會怎么調(diào) JVM”。不要直接說堆越大越好。高并發(fā)場景下核心不是堆大小而是減少 GC 停頓和分配壓力。常見優(yōu)化思路有合理設(shè)置-Xms和-Xmx避免運行時擴(kuò)容。根據(jù)對象生命周期設(shè)置-Xmn讓大部分短期對象在年輕代就回收減少老年代被塞滿的概率。開啟-XX:UseG1GC設(shè)置合理的-XX:MaxGCPauseMillis。對緩存類對象設(shè)置 TTL防止過期對象長期堆積。高峰期前做壓測觀察 GC 次數(shù)和 STW 時間。避免代碼里頻繁創(chuàng)建大對象、避免在循環(huán)里做字符串拼接、避免用同步鎖保護(hù)熱點短操作。面試官可能追問“為什么高并發(fā)下不宜把年輕代調(diào)太大”。因為年輕代太大會導(dǎo)致 Minor GC 頻率降低但單次 GC 停頓時間變長而且老年代空間被壓縮Full GC 風(fēng)險升高。這需要根據(jù)對象存活率動態(tài)調(diào)整而不是拍腦袋給一個數(shù)字。6.3 異常重啟后 JVM 日志去哪看熱搜詞里“異常重啟 jvm 日志在哪兒”是一條實戰(zhàn)問題出現(xiàn)頻率很高。日志要看三類第一類是應(yīng)用日志包括 logback、log4j2 輸出的業(yè)務(wù)日志路徑由應(yīng)用配置決定。第二類是 GC 日志需要用 JVM 參數(shù)顯式開啟比如-Xlog:gc*:/opt/logs/gc.log:time,uptime,level,tagsJDK 8 的寫法是-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/logs/gc.log第三類是 JVM 錯誤日志通常由-XX:ErrorFile指定比如-XX:ErrorFile/opt/logs/hs_err_pid%p.log。當(dāng) JVM 發(fā)生致命錯誤時這里會記錄崩潰原因、線程狀態(tài)和本地調(diào)用棧。容器部署場景要特別留意Docker 容器如果被 OOM Killer 殺掉JVM 本身可能來不及寫日志這時要查系統(tǒng)日志或 dmesg確認(rèn)是不是容器內(nèi)存超限被內(nèi)核殺掉了。如果 JVM 只是異常退出先看應(yīng)用啟動腳本確認(rèn)日志路徑和容器掛載目錄是否一致。7. 可復(fù)用的 JVM 排查清單和相關(guān)參數(shù)7.1 一個相對穩(wěn)妥的線上排查順序我自己排查 JVM 問題時會遵循這個順序先看現(xiàn)象是服務(wù)卡頓、接口超時、進(jìn)程重啟還是 CPU 100%。再看日志應(yīng)用日志、GC 日志、JVM 錯誤日志按時間對齊?？促Y源CPU、內(nèi)存、磁盤 IO、網(wǎng)絡(luò)連接數(shù)用top、free、df確認(rèn)?？?JVM 內(nèi)部jps、jstat、jstack、jmap配合 Arthas dashboard。定位代碼根據(jù)線程堆棧和方法調(diào)用鏈回到具體業(yè)務(wù)代碼。驗證修復(fù)小流量、灰度發(fā)布、壓測對比。這個順序的核心是先確認(rèn)問題是不是 JVM 引起的再考慮怎么調(diào)參。很多情況下接口慢不是 JVM 的問題而是數(shù)據(jù)庫慢查詢、Redis 超時、網(wǎng)絡(luò)延遲。7.2 常見參數(shù)記錄表建議把常用的 JVM 參數(shù)整理成一份模板每次上線前檢查一遍。參數(shù)含義建議-Xms堆初始大小和 -Xmx 保持一致-Xmx堆最大大小根據(jù)容器內(nèi)存預(yù)留-Xmn年輕代大小結(jié)合對象存活率設(shè)置-XX:MetaspaceSize元空間初始大小避免動態(tài)擴(kuò)容-XX:MaxMetaspaceSize元空間最大大小防止類加載泄漏-XX:UseG1GC使用 G1 收集器JDK 9 之后默認(rèn)-XX:MaxGCPauseMillisG1 期望停頓時間默認(rèn) 200ms-XX:HeapDumpOnOutOfMemoryErrorOOM 時導(dǎo)出堆快照生產(chǎn)環(huán)境必開-Xlog:gc開啟 GC 日志不同版本語法不同-XX:CompileThresholdJIT 編譯閾值不輕易修改7.3 一些容易踩的坑先說 GC 日志版本問題。JDK 8 的 GC 日志參數(shù)和 JDK 11 以后不一樣。JDK 8 常用-XX:PrintGCDetailsJDK 11 以后推薦-Xlog:gc*。如果你在更新 JDK 版本后沒有同步改參數(shù)會看到“Unrecognized VM option”之類的報錯服務(wù)根本起不來。再說不建議直接修改-XX:CompileThreshold。這個參數(shù)控制方法調(diào)用多少次后觸發(fā) JIT 編譯改小了會讓 JIT 更早介入可能提升峰值性能但也會增加編譯線程壓力。生產(chǎn)環(huán)境沒有明確依據(jù)時保持默認(rèn)即可。最后是 Arthas 的權(quán)限問題。線上生產(chǎn)環(huán)境使用 Arthas必須走審批流程注意賬號權(quán)限和審計。attach 進(jìn)程時不要隨意使用 root避免診斷過程引入新的風(fēng)險。如果是容器環(huán)境記得確認(rèn)容器內(nèi)有沒有/proc權(quán)限這是 Arthas 獲取進(jìn)程信息的關(guān)鍵。7.4 學(xué)習(xí)路線建議準(zhǔn)備 JVM 面試不必一開始就盯著 ZGC 源碼先把基礎(chǔ)鏈路打通類加載機制 → 運行時數(shù)據(jù)區(qū) → 對象分配 → GC 算法 → 收集器對比 → STW 影響 → 線上診斷工具 → 項目實戰(zhàn)調(diào)優(yōu)。源碼對比可以作為加分項。比如 G1 的 Region 劃分、ZGC 的染色指針理解原理后面試官問到“ZGC 相對 G1 的改動點”你就能說清楚。但如果基礎(chǔ)概念還不牢先不要強啃源碼。大廠面試更看重的是你能不能把問題講成一條完整閉環(huán)而不是零散記憶。項目實戰(zhàn)部分是拉開差距的關(guān)鍵。如果你做過高并發(fā)項目可以準(zhǔn)備一個真實案例系統(tǒng)之前用 CMS每天大促時 Full GC 頻繁通過調(diào)整堆內(nèi)存、切換 G1、優(yōu)化緩存和對象創(chuàng)建把 Full GC 次數(shù)降到多少接口 99 分位耗時下降多少。這里的數(shù)字要真實沒數(shù)據(jù)就不要編面試官追問細(xì)節(jié)很容易露餡。我現(xiàn)在給大多數(shù)人的建議是把內(nèi)存模型、GC、STW、Arthas 這四個點串成一條排錯主線再準(zhǔn)備一兩個自己經(jīng)手或復(fù)現(xiàn)過的真實案例。刷題只能幫你過第一輪真正決定面試深度的是你對線上問題的判斷力和調(diào)優(yōu)思路。