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