JVM這詞兒Java程序員基本天天見但說實(shí)話很多人對(duì)它的理解就停在“Java虛擬機(jī)”這個(gè)字面意思上。前陣子有個(gè)工作五年的朋友問我“JRE和JVM到底啥區(qū)別我裝JDK是不是就帶JRE了”我當(dāng)場有點(diǎn)愣住。后來想想這東西確實(shí)挺擰巴的——我們每天都在跟堆內(nèi)存、GC日志打交道可真要刨根問底能把JVM的內(nèi)存模型、編譯器種類、參數(shù)調(diào)優(yōu)串成一條完整邏輯鏈的人其實(shí)不多。面試題問來問去就那幾道但背后牽著的是一整套運(yùn)行時(shí)體系。這篇我打算從JVM的身份定位講起一路聊到內(nèi)存模型、字節(jié)碼與編譯器的關(guān)系、Tomcat里怎么實(shí)際配參數(shù)、線上調(diào)優(yōu)該看哪些指標(biāo)最后把面試?yán)镒钊菀撞瓤拥膸讉€(gè)點(diǎn)也扒一扒。內(nèi)容盡量貼著實(shí)戰(zhàn)走該給參數(shù)給參數(shù)該上命令上命令看完你能在項(xiàng)目中直接照著做的那種。1. JVM到底是個(gè)啥它跟JRE、JDK的關(guān)系為什么總有人繞暈先說那個(gè)經(jīng)典問題JRE和JVM之間的關(guān)系。很多教程會(huì)給你畫一個(gè)三層套娃圖——JDK包含JREJRE包含JVM然后讓你背下來。背是能背可真到了實(shí)際環(huán)境里還是容易搞混。我用一句話給你捋清楚JVM是Java程序真正運(yùn)行的地方它是一個(gè)“進(jìn)程級(jí)”的虛擬機(jī)JRE是運(yùn)行Java程序所需要的整套環(huán)境JDK是開發(fā)Java程序所需要的整套工具集。你寫了一個(gè)Main.class在命令行敲下java Main的時(shí)候操作系統(tǒng)會(huì)啟動(dòng)一個(gè)新的進(jìn)程這個(gè)進(jìn)程就是JVM。JVM加載你的字節(jié)碼解釋或者編譯成機(jī)器碼然后執(zhí)行。而JRE呢它是JVM加上Java基礎(chǔ)類庫rt.jar、jce.jar那些和運(yùn)行時(shí)依賴的文件的集合體。為什么需要這些類庫因?yàn)槟愕拇a里用到System.out.println這個(gè)System類不是你自己寫的是JRE幫你提供的。JVM負(fù)責(zé)“怎么跑”基礎(chǔ)類庫負(fù)責(zé)“跑的時(shí)候能用到什么”。那JDK就更往外一層了——它包含了JRE的全部內(nèi)容再加上編譯器javac、診斷工具jmap/jstat/jstack、打包工具jar這些開發(fā)用的東西。這里有個(gè)實(shí)操中很容易犯迷糊的點(diǎn)你裝了JDK是不是就一定自帶JRE得看版本。JDK 8及以前JDK安裝目錄下確實(shí)直接帶了一個(gè)jre文件夾。但從JDK 9開始Oracle搞了模塊化Project Jigsaw安裝目錄下就不再有獨(dú)立的jre目錄了。你用java命令跑程序的時(shí)候它用的是JDK內(nèi)置的運(yùn)行時(shí)。所以現(xiàn)在面試要是有人說“JDK里一定包含獨(dú)立的JRE目錄”這觀點(diǎn)在JDK 9之后是不成立的。還有一層關(guān)系是更底層的——JVM本身不是一個(gè)軟件而是一份規(guī)范。Oracle的HotSpot只是這份規(guī)范最流行的實(shí)現(xiàn)除此之外還有OpenJ9、GraalVM、Zing等等。規(guī)范規(guī)定了JVM該有哪些區(qū)域比如堆、棧、方法區(qū)、該支持哪些指令集字節(jié)碼指令、類加載機(jī)制大概是什么流程但具體內(nèi)存布局怎么優(yōu)化、垃圾收集器怎么設(shè)計(jì)都是各個(gè)實(shí)現(xiàn)自己發(fā)揮。這也是為什么JVM只認(rèn)字節(jié)碼不認(rèn)語言——只要你能把源代碼編譯成符合規(guī)范的class文件就能跑在JVM上。理解到這層你才算把一個(gè)最關(guān)鍵的問題想明白了JVM調(diào)優(yōu)調(diào)的從來不是Java本身而是一個(gè)字節(jié)碼執(zhí)行環(huán)境。Kotlin、Scala、Groovy這些語言最后都編譯成class文件它們跑在JVM上的內(nèi)存模型、GC行為跟Java是一模一樣的。2. JVM內(nèi)存模型拆解堆、棧、方法區(qū)到底各自管什么JVM的內(nèi)存模型是面試必考也是調(diào)優(yōu)必懂的基礎(chǔ)。很多人一上來就背“堆存對(duì)象、棧存引用、方法區(qū)存類信息”聽起來對(duì)可真遇到線上OOM還是不知道該查哪塊。我?guī)惆堰@個(gè)區(qū)域地圖畫得細(xì)一點(diǎn)。2.1 線程私有區(qū)程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法棧程序計(jì)數(shù)器Program Counter Register是JVM里最迷你的區(qū)域它存的只是“當(dāng)前線程執(zhí)行到哪一條字節(jié)碼指令”的地址。這塊區(qū)域不需要調(diào)優(yōu)也不會(huì)OOM面試官問到它你答“用于記錄字節(jié)碼執(zhí)行位置、分支、循環(huán)、跳轉(zhuǎn)、異常處理等”就夠了。虛擬機(jī)棧VM Stack才是真正跟“方法調(diào)用”強(qiáng)相關(guān)的區(qū)域。每次調(diào)用一個(gè)方法JVM就壓入一個(gè)棧幀棧幀里保存著局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接和方法出口。局部變量表里存的是基本類型int、boolean、double這類和對(duì)象引用不是對(duì)象本身。這是個(gè)高頻考點(diǎn)也是初學(xué)者的重災(zāi)區(qū)后面我會(huì)專門再提。本地方法棧Native Method Stack跟虛擬機(jī)棧類似區(qū)別只在于它是給native方法用的。HotSpot的實(shí)現(xiàn)里把這兩個(gè)棧合并成了一個(gè)所以日常排查基本不用單獨(dú)區(qū)分。這兩塊區(qū)域該關(guān)注什么棧的容量是固定的或者動(dòng)態(tài)的固定容量超了會(huì)拋StackOverflowError動(dòng)態(tài)擴(kuò)展內(nèi)存不夠了會(huì)拋OutOfMemoryError。最常見的場景就是無限遞歸——你寫了個(gè)沒有終止條件的遞歸方法跑幾千層之后棧就爆了。2.2 線程共享區(qū)堆、方法區(qū)、運(yùn)行時(shí)常量池堆Heap是JVM管理的內(nèi)存中最大的一塊所有通過new創(chuàng)建出來的對(duì)象實(shí)例和數(shù)組都在這上面分配。堆內(nèi)部又劃分成新生代Eden、From Survivor、To Survivor和老年代這是為了配合分代垃圾回收策略。新生代里絕大多數(shù)對(duì)象活不過第一輪GC朝生夕滅老年代則存放長期存活的對(duì)象。方法區(qū)Method Area在JDK 8之前叫永久代PermGen從JDK 8開始改成了元空間Metaspace。這里面存的是類元信息類的結(jié)構(gòu)、字段描述、方法描述、靜態(tài)變量、常量池等。切換的動(dòng)機(jī)很實(shí)際永久代的大小是固定的-XX:MaxPermSize很容易因?yàn)榧虞d的類太多而OOM而且跟堆共用一個(gè)內(nèi)存區(qū)域?qū)е禄ハ鄶D兌。元空間直接使用本地內(nèi)存native memory默認(rèn)情況下只受操作系統(tǒng)可用內(nèi)存限制大大減少了類過多導(dǎo)致的OOM問題。運(yùn)行時(shí)常量池Runtime Constant Pool是方法區(qū)的一部分存放編譯期生成的字面量和符號(hào)引用。比如字符串hello字面量、類的符號(hào)引用都在這。2.3 直接內(nèi)存JVM調(diào)優(yōu)經(jīng)常忽略的一塊直接內(nèi)存Direct Memory不在JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)的規(guī)范里但在JDK 1.4引入NIO之后它變得特別重要。ByteBuffer.allocateDirect()分配的就是堆外內(nèi)存它的優(yōu)勢是省掉了“內(nèi)核態(tài)到用戶態(tài)”的數(shù)據(jù)拷貝I/O性能更高。但副作用是你得自己管理GC管不到它很多細(xì)節(jié)分配過多一樣會(huì)拋OutOfMemoryError。我在實(shí)際項(xiàng)目里排查過一個(gè)詭異的問題程序堆內(nèi)存占用很低可整個(gè)進(jìn)程的RSS物理內(nèi)存占用一直漲最后被操作系統(tǒng)OOM Killer干掉了。查到最后就是Netty框架大量用了直接內(nèi)存默認(rèn)的-XX:MaxDirectMemorySize又沒設(shè)。這是個(gè)非常經(jīng)典的“堆沒事、直接內(nèi)存爆了”案例調(diào)優(yōu)的時(shí)候一定別漏掉它。2.4 一個(gè)對(duì)象創(chuàng)建的全流程分配到老年代的路徑是怎樣的為了把上面的知識(shí)點(diǎn)串起來我給了自己團(tuán)隊(duì)一個(gè)小練習(xí)new一個(gè)對(duì)象它在JVM里到底經(jīng)歷了什么這個(gè)練習(xí)對(duì)理解GC很有幫助。類加載檢查JVM先確認(rèn)這個(gè)類是否已被加載、解析、初始化過。如果沒有先走類加載流程——加載、驗(yàn)證、準(zhǔn)備、解析、初始化。分配內(nèi)存對(duì)象所需的內(nèi)存在堆上必須是連續(xù)的。分配方式有兩種一種是指針碰撞Bump the Pointer用于內(nèi)存規(guī)整的時(shí)候另一種是空閑列表Free List用于內(nèi)存碎片化的時(shí)候。初始化零值將分配到的內(nèi)存區(qū)域除對(duì)象頭外全部清零保證不賦值的情況下字段默認(rèn)值是0或者null。設(shè)置對(duì)象頭存對(duì)象屬于哪個(gè)類的元數(shù)據(jù)指針、對(duì)象的哈希碼、GC分代年齡、鎖狀態(tài)標(biāo)志等。執(zhí)行構(gòu)造方法也就是init方法把對(duì)象的字段按代碼真正初始化。晉升老年代的路徑大概是對(duì)象先在Eden區(qū)分配Minor GC之后存活且年齡1在Survivor區(qū)來回倒騰年齡達(dá)到閾值默認(rèn)15就晉升老年代。但有幾個(gè)特殊情況大對(duì)象超過-XX:PretenureSizeThreshold設(shè)置的值直接進(jìn)老年代Survivor區(qū)放不下存活對(duì)象了也會(huì)直接晉升還有動(dòng)態(tài)年齡判定——如果Survivor中相同年齡所有對(duì)象大小的總和大于Survivor空間的一半年齡大于等于該年齡的對(duì)象直接進(jìn)入老年代。3. Java的“編譯器”不是只有javac前端、JIT、AOT一條鏈路看完熱搜詞里有個(gè)“java jvm編譯器有幾種”的問題。很多人以為編譯器就是javac其實(shí)JVM體系里至少有三層編譯關(guān)系前端編譯器javac、即時(shí)編譯器JIT、提前編譯器AOT。這三者管的事完全不同。3.1 javac把Java源碼翻譯成字節(jié)碼的前端編譯器javac干的事是把.java文件翻譯成.class文件也就是字節(jié)碼。它不會(huì)直接生成機(jī)器碼。為什么要有這么一層中間產(chǎn)物因?yàn)镴VM只看得懂字節(jié)碼。字節(jié)碼是一套很精巧的指令集比如iload是加載int類型局部變量invokevirtual是調(diào)用實(shí)例方法new是創(chuàng)建對(duì)象。每條指令都有對(duì)應(yīng)的操作碼opcodeclass文件里全是這些緊湊的二進(jìn)制指令。前端編譯器的執(zhí)行過程大致是詞法分析、語法分析、語義分析、生成字節(jié)碼。這跟其他語言的前端編譯沒什么本質(zhì)區(qū)別值得注意的是一些語法糖在這里被拆解比如泛型的類型擦除就是javac階段干的。你用ListString編譯出來的字節(jié)碼跟List沒區(qū)別這就是類型擦除——泛型只在編譯期做類型檢查運(yùn)行期就沒了。3.2 JIT即時(shí)編譯器熱點(diǎn)代碼的機(jī)器碼加速JVM運(yùn)行class文件時(shí)不是從頭到尾純解釋執(zhí)行。HotSpot的名字本身就點(diǎn)出了關(guān)鍵機(jī)制——它會(huì)找到“熱點(diǎn)代碼”Hot Spot Code把高頻執(zhí)行的方法直接編譯成本地機(jī)器碼然后緩存起來后續(xù)調(diào)用直接跑機(jī)器碼速度大幅提升。HotSpot里有兩款主力JIT編譯器C1編譯器Client Compiler編譯速度快但優(yōu)化程度低適合桌面應(yīng)用追求啟動(dòng)速度。C2編譯器Server Compiler編譯速度慢但優(yōu)化程度高適合服務(wù)端應(yīng)用追求峰值性能?，F(xiàn)代JDK默認(rèn)是分層編譯Tiered Compilation——先用解釋器快速響應(yīng)然后C1編譯做第一層優(yōu)化如果某個(gè)方法調(diào)用頻率進(jìn)一步增加C2再上場做更激進(jìn)的優(yōu)化包括方法內(nèi)聯(lián)、循環(huán)展開、逃逸分析、鎖消除等。逃逸分析值得單獨(dú)說一下因?yàn)樗苯佑绊懳覀儗懙拇a。如果JVM能確認(rèn)一個(gè)對(duì)象不會(huì)“逃逸”出方法比如只在方法內(nèi)部new出來用一下沒有返回也沒有賦給全局變量它可能直接在棧上分配對(duì)象對(duì)象隨著方法結(jié)束自動(dòng)銷毀根本不用進(jìn)堆也就沒有GC壓力。這也是為什么局部對(duì)象別動(dòng)不動(dòng)就塞進(jìn)全局容器——你是在破壞JVM優(yōu)化它的機(jī)會(huì)。3.3 AOT提前編譯GraalVM Native Image帶來的新思路除了JIT現(xiàn)在還有一個(gè)方向是AOTAhead Of Time編譯。GraalVM的Native Image工具可以把你的Java/Kotlin應(yīng)用連同JVM運(yùn)行時(shí)一起提前編譯成原生可執(zhí)行文件。好處非常明顯啟動(dòng)速度極快毫秒級(jí)、內(nèi)存占用低、沒有JIT預(yù)熱過程非常適合云原生場景的Serverless函數(shù)、微服務(wù)小實(shí)例。代價(jià)也很實(shí)在不支持運(yùn)行時(shí)動(dòng)態(tài)生成類反射要額外配置reflect-config、不支持頻繁的JIT優(yōu)化、GC選擇受限。所以我的建議是常規(guī)業(yè)務(wù)系統(tǒng)別盲目上AOT等你的痛點(diǎn)真的是“啟動(dòng)太慢”或者“內(nèi)存太小”了再考慮。3.4 Kotlin在JVM上跑Agent字節(jié)碼面前眾生平等熱搜詞里有條“adk.dev的kotlin快速上手在jvm上跑通一個(gè)agent”這正好能用來解釋字節(jié)碼的通用性。Java Agent技術(shù)通過premain或者agentmain方式掛載本質(zhì)上是依賴java.lang.instrument接口在類加載的時(shí)候?qū)ψ止?jié)碼做增強(qiáng)比如加日志、加監(jiān)控、做鏈路追蹤。既然JVM只認(rèn)字節(jié)碼那你用Kotlin寫的Agent邏輯只要最后編譯成class文件跟Java寫的Agent沒有任何區(qū)別。實(shí)際操作起來你只需要在Kotlin項(xiàng)目里定義一個(gè)類里面加上class MyAgent { companion object { JvmStatic fun premain(agentArgs: String?, inst: Instrumentation) { inst.addTransformer(MyTransformer()) println(Agent attached.) } } }然后打包成帶Premain-Class屬性的jar包運(yùn)行時(shí)加上-javaagent:my-agent.jar就能掛載。這里有個(gè)細(xì)節(jié)Kotlin的頂層函數(shù)和companion object默認(rèn)生成的static方法跟Java的調(diào)用方式不太一樣如果不加JvmStatic注解JVM平臺(tái)上就找不到對(duì)應(yīng)的static入口Agent啟動(dòng)會(huì)直接失敗。這種跨語言細(xì)節(jié)只有把“JVM只認(rèn)字節(jié)碼”這個(gè)底層邏輯吃透了才能理解。4. Tomcat啟動(dòng)設(shè)置JVM參數(shù)從配JAVA_OPTS到驗(yàn)證一次到位線上最常見的實(shí)操場景就是給Tomcat調(diào)JVM參數(shù)。這個(gè)活兒看起來簡單就是改個(gè)環(huán)境變量但真正踩過坑的人都知道設(shè)置位置、參數(shù)生效順序、大小核數(shù)適配處處有講究。4.1 參數(shù)到底寫在哪catalina.sh和setenv.sh的分工Tomcat啟動(dòng)腳本核心是catalina.sh它會(huì)去讀取環(huán)境變量JAVA_OPTS、CATALINA_OPTS。兩者的區(qū)別是JAVA_OPTS在Tomcat啟動(dòng)、關(guān)閉、執(zhí)行各種命令時(shí)都會(huì)被讀取。CATALINA_OPPS只在啟動(dòng)Tomcat主進(jìn)程的時(shí)候讀取執(zhí)行關(guān)閉操作時(shí)不會(huì)加載。所以如果你要設(shè)置的是JVM運(yùn)行參數(shù)堆大小、GC算法建議放CATALINA_OPTS這樣執(zhí)行shutdown.sh的時(shí)候不會(huì)因?yàn)槟硞€(gè)參數(shù)不對(duì)導(dǎo)致關(guān)不掉進(jìn)程。不過生產(chǎn)環(huán)境很多團(tuán)隊(duì)的腳本是直接用JAVA_OPTS一把梭也能用但不夠嚴(yán)謹(jǐn)。更推薦的做法是使用專門的環(huán)境變量文件setenv.sh。Tomcat啟動(dòng)時(shí)catalina.sh會(huì)自動(dòng)檢查$CATALINA_BASE/bin/setenv.sh是否存在存在就source它。這樣你就不用去改Tomcat自帶的catalina.sh升級(jí)Tomcat版本的時(shí)候不會(huì)被覆蓋。具體操作是在Tomcat的bin目錄下新建setenv.sh內(nèi)容大致如下export JAVA_HOME/usr/local/jdk17 export CATALINA_OPTS-Xms2048m -Xmx2048m -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m然后記得給腳本加執(zhí)行權(quán)限chmod x setenv.sh不要小看setenv.sh這種“約定優(yōu)于配置”的做法它最大的好處是升級(jí)Tomcat、遷移環(huán)境的時(shí)候你的JVM參數(shù)配置跟Tomcat自身配置是解耦的。4.2 核心參數(shù)解讀別只認(rèn)得Xmx和Xms很多人在線上只敢設(shè)置-Xmx和-Xms其他參數(shù)一概不加。我理解這種保守但有些默認(rèn)值真的需要看一下。堆大小相關(guān)-Xms初始堆大小推薦設(shè)置為跟-Xmx一樣大避免JVM啟動(dòng)后因?yàn)槎褦U(kuò)容觸發(fā)多次Full GC擴(kuò)容本身是重操作而且發(fā)生在舊GC體系里會(huì)更明顯。-Xmx最大堆大小。設(shè)太大會(huì)浪費(fèi)內(nèi)存設(shè)太小會(huì)頻繁GC甚至OOM。建議設(shè)置前先監(jiān)控一下應(yīng)用常態(tài)下的堆占用峰值在這個(gè)基礎(chǔ)上加30%緩沖。元空間相關(guān)-XX:MetaspaceSize觸發(fā)Full GC的元空間閾值。很多人以為這個(gè)是最大值其實(shí)不是它是“達(dá)到這個(gè)值就觸發(fā)GC來嘗試回收類元數(shù)據(jù)”的閾值。-XX:MaxMetaspaceSize元空間上限超過會(huì)OOM。線程棧和直接內(nèi)存-Xss每個(gè)線程的棧大小一般默認(rèn)1MB就夠了別亂調(diào)小調(diào)小會(huì)導(dǎo)致遞歸深度變淺、容易StackOverflow調(diào)大則線程數(shù)會(huì)變少因?yàn)榫€程棧內(nèi)存是從操作系統(tǒng)層面申請的。-XX:MaxDirectMemorySize直接內(nèi)存上限用Netty、Vert.x這類框架的必須顯式配置。GC日志相關(guān)JDK 8的寫法JDK 11用-Xlog:gc*-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/app/logs/gc.log4.3 配置完怎么確認(rèn)生效三個(gè)小命令配了參數(shù)最怕的就是“以為生效了”。我先教你一個(gè)最直接的驗(yàn)證方法ps -ef | grep tomcat看啟動(dòng)命令行里有沒有帶-Xmx2048m。如果你的參數(shù)是通過環(huán)境變量傳進(jìn)去的命令行里會(huì)直接顯示出來。更準(zhǔn)確的驗(yàn)證方式是啟動(dòng)后看實(shí)際使用的GC器和堆大小jcmd pid -XX:PrintFlagsFinal | grep -E MaxHeapSize|UseG1GC或者用jhsdb jinfo --flags pid。這些工具的優(yōu)先級(jí)是別信配置文件要看JVM運(yùn)行時(shí)刻的最終值。還有個(gè)隱藏很深的坑如果你在Tomcat的catalina.sh里改了JAVA_OPTS但系統(tǒng)里的CATALINA_OPTS環(huán)境變量優(yōu)先級(jí)更高兩個(gè)同名變量沖突時(shí)環(huán)境變量會(huì)覆蓋腳本里的賦值。排查這種詭異問題第一反應(yīng)就是打印完整的JVM啟動(dòng)命令看看實(shí)際生效的值到底是什么。5. JVM調(diào)優(yōu)不是調(diào)參大賽從現(xiàn)象到結(jié)論的一次完整排查“JVM調(diào)優(yōu)”這四個(gè)字在很多人腦子里約等于“改Xmx”。但真正有經(jīng)驗(yàn)的開發(fā)會(huì)告訴你調(diào)優(yōu)的第一步永遠(yuǎn)是觀察第二步才是動(dòng)手改參數(shù)。5.1 先搞懂指標(biāo)GC頻率、停頓時(shí)間、吞吐量線上調(diào)優(yōu)最常見的目標(biāo)是解決這幾類問題Full GC頻繁CPU飆高、接口偶爾突然卡頓幾秒。OOM進(jìn)程直接掛掉或者報(bào)錯(cuò)。內(nèi)存泄漏堆內(nèi)存持續(xù)上漲GC后回收不掉。關(guān)于GC你要看的核心指標(biāo)有三個(gè)吞吐量Throughput應(yīng)用運(yùn)行時(shí)間占總的可用時(shí)間的比例。吞吐量低說明大量時(shí)間耗在GC上。延遲LatencyGC停頓Stop The World時(shí)間。停頓時(shí)間越長接口毛刺越明顯。頻率GC多久發(fā)生一次。有時(shí)候一次GC停頓只有幾十毫秒但每分鐘幾十次累積起來對(duì)CPU的消耗也不小。這三個(gè)指標(biāo)存在競爭關(guān)系——你想通過增大堆來降低GC頻率結(jié)果每次GC掃描的區(qū)域變大了停頓時(shí)間反而上升。調(diào)優(yōu)就是在這三者之間找到平衡點(diǎn)。5.2 排查工具鏈怎么用jstat、jmap、jstack各管一攤我常用的排查組合是下面這一套jstat -gcutil pid 1000每秒輸出一次各代的占用百分比和GC次數(shù)。這能快速判斷是否在頻繁GC、老年代占用率是不是居高不下。jmap -heap pid看堆的當(dāng)前配置和實(shí)際使用情況確認(rèn)各個(gè)參數(shù)有沒有生效。jmap -histo:live pid觸發(fā)一次Full GC然后列出占用內(nèi)存最大的對(duì)象Top列表定位大對(duì)象或疑似泄漏對(duì)象。jstack pid打線程棧查死鎖、阻塞、長時(shí)間停頓的線程。再往下還有jcmd命令能執(zhí)行診斷指令比如jcmd pid GC.heap_dump heap.hprof可以導(dǎo)出堆轉(zhuǎn)儲(chǔ)文件比老的jmap -dump更簡潔。5.3 一個(gè)真實(shí)案例Full GC頻繁但堆不算大前不久我處理過一個(gè)應(yīng)用現(xiàn)象是每幾分鐘一次Full GC每次停頓1秒多接口響應(yīng)明顯變慢。查的第一步是jstat -gcutil輸出里老年代O列長期在90%以上而且Full GC之后下降不明顯。這就指向老年代里有大量長期存活的對(duì)象而且回收效率很差。接著用jmap -histo:live看前幾個(gè)對(duì)象類型發(fā)現(xiàn)有一批byte[]占了堆的40%。再配合線程棧檢查發(fā)現(xiàn)是一個(gè)定時(shí)任務(wù)在不停地往一個(gè)全局Listbyte[]里塞數(shù)據(jù)從沒清理。這就是典型的內(nèi)存泄漏——對(duì)象有引用GC根可達(dá)但業(yè)務(wù)上已經(jīng)沒用了。修復(fù)方案不是調(diào)JVM參數(shù)而是在代碼里加上清理邏輯和容量上限。所以我想強(qiáng)調(diào)一句很多“JVM調(diào)優(yōu)”問題的答案不在JVM里在代碼里。調(diào)參永遠(yuǎn)是最后一步而且是在確認(rèn)代碼沒問題之后才做。5.4 參數(shù)到底怎么調(diào)一個(gè)相對(duì)穩(wěn)妥的思路如果你的系統(tǒng)確實(shí)需要?jiǎng)訁?shù)我的建議路徑是這樣的保持-Xms和-Xmx一致避免堆動(dòng)態(tài)擴(kuò)容帶來的估值波動(dòng)。如果JDK 8且能升級(jí)直接用G1JDK 9默認(rèn)GC就是G1。G1用-XX:MaxGCPauseMillis來控制停頓初始可以設(shè)200ms跑一個(gè)周期看日志再微調(diào)。設(shè)置一個(gè)合理的-XX:MaxMetaspaceSize避免元空間無限漲。打開GC日志保留最近一輪數(shù)據(jù)為后續(xù)調(diào)優(yōu)留依據(jù)。一次只改一個(gè)參數(shù)改完觀察至少一個(gè)業(yè)務(wù)高峰周期比如一天別一次性堆四五個(gè)參數(shù)上去。如果你還在用JDK 8的ParallelGC且堆不超過4G其實(shí)默認(rèn)參數(shù)通常就能扛得住。真正需要調(diào)優(yōu)的場景通常是堆很大比如8G以上、要求低停頓如線上交易系統(tǒng)、或者有明確響應(yīng)時(shí)間SLA這時(shí)候再花精力研究G1/ZGC也不遲。6. JVM面試題考點(diǎn)解讀把八股文變成真理解最后聊點(diǎn)實(shí)際的——JVM相關(guān)的面試題。很多人靠背題過面試但面試官只要深挖一下就露餡了。其實(shí)JVM的知識(shí)體系是成網(wǎng)的你只要把幾個(gè)核心模型打通了題目怎么變形都能接住。6.1 高頻題強(qiáng)引用、軟引用、弱引用、虛引用各自在哪回收這題考的是你對(duì)GC Roots和引用類型的理解。我直接用一句話給你區(qū)分強(qiáng)引用Strong ReferenceObject obj new Object()這種只要存在強(qiáng)引用GC永不回收。軟引用Soft ReferenceSoftReferenceUser包裹的對(duì)象內(nèi)存充足時(shí)不回收內(nèi)存不足時(shí)即將OOM前回收。適合做緩存。弱引用WeakReferenceWeakReferenceUser包裹的對(duì)象只要發(fā)生GC就會(huì)被回收不管內(nèi)存夠不夠。典型應(yīng)用是ThreadLocal的ThreadLocalMap的key。虛引用PhantomReference最弱甚至你從它那里都拿不到對(duì)象的引用它存在的唯一意義是在對(duì)象被回收時(shí)收到一個(gè)系統(tǒng)通知用來追蹤對(duì)象銷毀時(shí)間。實(shí)戰(zhàn)里我最常遇到的是軟引用和弱引用的選擇。做緩存設(shè)計(jì)時(shí)如果緩存里放了大量數(shù)據(jù)不建議用強(qiáng)引用持有否則堆很容易爆掉。這時(shí)候軟引用就是一個(gè)折中方案——平時(shí)能用內(nèi)存緊張時(shí)自動(dòng)騰地方。6.2 高頻題String到底在堆里還是常量池里這個(gè)問題特別容易答錯(cuò)因?yàn)樗鶭DK版本強(qiáng)相關(guān)。JDK 7之前字符串常量放在方法區(qū)永久代的常量池里。JDK 7開始字符串常量池移到了堆中而字符串對(duì)象本身也是一直在堆里的。所以準(zhǔn)確的說法是通過new String(hello)創(chuàng)建的對(duì)象在堆上通過雙引號(hào)字面量hello創(chuàng)建的字符串JVM會(huì)先去字符串常量池現(xiàn)在在堆里查找如果已存在就直接返回池中的引用不存在則在池中創(chuàng)建。而intern()方法的作用就是把一個(gè)堆上的String對(duì)象設(shè)法加入常量池返回池中的引用。面試題常考的對(duì)比String s1 hello; String s2 new String(hello); System.out.println(s1 s2); // falses1指向常量池s2指向堆 System.out.println(s1 s2.intern()); // trueintern后s2回到常量池6.3 高頻題對(duì)象什么時(shí)候進(jìn)入老年代為什么默認(rèn)晉升年齡是15晉升老年代的幾個(gè)條件我在前面已經(jīng)寫過了年齡達(dá)到閾值、大對(duì)象直接進(jìn)入、Survivor空間不足。默認(rèn)晉升年齡15這個(gè)數(shù)字本質(zhì)上是因?yàn)閷?duì)象頭里記錄GC年齡的字段只分配了4個(gè)bit能表示的最大值就是15。你要是為了減少Young GC次數(shù)把這個(gè)閾值調(diào)大比如調(diào)到30JVM其實(shí)只能用4bit存儲(chǔ)超過15后面就不再記了這是個(gè)物理限制。這里可以延伸出一個(gè)面試官喜歡問的點(diǎn)為什么Survivor要分From和To兩塊因?yàn)闃?biāo)記-復(fù)制算法需要一塊空閑區(qū)域作為對(duì)象交換的中轉(zhuǎn)站。每次Minor GC把Eden和From里存活的對(duì)象復(fù)制到To然后清空Eden和From下一輪再交換From和To的語義。如果沒有這塊“To”空間就只能標(biāo)記-清理會(huì)產(chǎn)生碎片且回收效率變低。6.4 高頻題什么是Stop The World為什么會(huì)發(fā)生STWStop The World指的是GC發(fā)生時(shí)所有用戶線程必須暫停等GC完成后再恢復(fù)。為什么必須暫停因?yàn)镴VM要保證在回收對(duì)象期間堆里的對(duì)象引用關(guān)系不能被用戶線程同時(shí)修改否則會(huì)把活對(duì)象當(dāng)垃圾清理掉或者標(biāo)記過程中引用關(guān)系錯(cuò)亂。很多人覺得STW是G1、ZGC才有的問題其實(shí)Minor GC也會(huì)有STW只是時(shí)間短幾毫秒到幾十毫秒。ZGC和Shenandoah嘗試用染色指針、讀屏障之類的技術(shù)把STW時(shí)間壓到極低毫秒級(jí)別甚至接近零但代價(jià)是CPU的額外消耗和更高的內(nèi)存占用。線上系統(tǒng)選GC器沒有銀彈還是那句話在吞吐量、停頓時(shí)間、內(nèi)存占用三者之間做取舍。6.5 面試之外的提醒別把JVM當(dāng)黑盒要當(dāng)工具箱順便給準(zhǔn)備面試的朋友提個(gè)醒現(xiàn)在面試官幾乎人手一個(gè)線上問題當(dāng)追問。你說你懂G1他大概率會(huì)接著問“線上G1的Mixed GC階段是什么RSet是干嘛的”你說你設(shè)置過-Xmx2g他可能問“線上OOM了你怎么確認(rèn)報(bào)的是堆OOM還是直接內(nèi)存OOM”我的建議是與其死磕冷門題不如把jstat、jmap、jstack這些工具練熟把一次真實(shí)的線上排查流程完完整整走一遍這比背二十道八股文都管用。寫了這么多最后分享一點(diǎn)我個(gè)人的體會(huì)JVM不是一個(gè)需要“精通”的黑盒它更像一個(gè)工具箱——你不需要記住每個(gè)參數(shù)的默認(rèn)值但一定得知道工具在哪、什么時(shí)候該調(diào)用、調(diào)用了之后怎么看結(jié)果。很多人在JVM上花了大把時(shí)間研究ZGC的參數(shù)其實(shí)連jstat的輸出都還沒看明白這屬于本末倒置。先把內(nèi)存模型和GC的基礎(chǔ)鏈路吃透再按需去查參數(shù)、做實(shí)驗(yàn)?zāi)銜?huì)發(fā)現(xiàn)自己對(duì)JVM的掌控感完全不一樣。真要遇到線上疑難雜癥第一步永遠(yuǎn)是先完整保留現(xiàn)場GC日志、堆轉(zhuǎn)儲(chǔ)、線程快照而不是急著改參數(shù)重啟。