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