優(yōu)與GC實戰(zhàn)：回收器選型、參數(shù)模板及OOM排查)
現(xiàn)在團隊里只要有人問“線上接口偶爾卡個幾百毫秒是什么原因”十有八九最后都會落到 JVM 調(diào)優(yōu)和垃圾回收器這個話題上尤其是還在跑 JDK8 的項目。JDK8 是個很特殊的分水嶺它既有成熟的 Parallel Scavenge 和 CMS又帶來了 G1還徹底刪掉了永久代改用元空間。這意味著同樣一段“加大堆內(nèi)存、調(diào)小新生代”的老經(jīng)驗放在 JDK8 上可能反而把系統(tǒng)推向頻繁 Full GC。這篇內(nèi)容我打算按自己的實戰(zhàn)路徑來寫——先把內(nèi)存模型和對象生命周期講透再逐個拆解 JDK8 里能用的垃圾回收器然后給出可以直接抄的參數(shù)模板、工具鏈用法、GC 日志判讀方法最后落到 OOM 的各種現(xiàn)場。適合正在做服務端開發(fā)、需要處理線上性能問題或者準備面試想真正搞懂 JVM 工作原理的人。1. 先把 JVM 內(nèi)存模型捋直調(diào)優(yōu)才有坐標系我見過太多“調(diào)優(yōu)”是這么做的上來就-Xmx4g然后看 GC 日志里 Full GC 次數(shù)少了就完事。這種做法能碰對是運氣碰不對就是埋雷。真正動手前必須把內(nèi)存模型這張地圖在腦子里畫出來否則你連參數(shù)改的是哪塊區(qū)域都不知道。1.1 運行時數(shù)據(jù)區(qū)到底分幾塊JDK8 改了什么JVM 在運行時會把自己管的內(nèi)存切成幾塊每塊職責不同回收策略也完全不同。按線程私有和線程共享來分理解起來最快。線程私有的三塊程序計數(shù)器記錄當前線程執(zhí)行到哪條字節(jié)碼指令。唯一不會拋 OOM 的區(qū)域占用的內(nèi)存可以忽略不計。虛擬機棧每個方法調(diào)用創(chuàng)建一個棧幀棧幀里放局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口。平時說的“棧溢出”絕大多數(shù)就是這里由-Xss控制單個線程棧大小。本地方法棧給 native 方法用的HotSpot 里和虛擬機棧合并實現(xiàn)一般不單獨關心。線程共享的兩塊堆對象實例和數(shù)組的主要存放地也是垃圾回收的主戰(zhàn)場。調(diào)優(yōu) 90% 的參數(shù)都在動這塊。方法區(qū)存放類元信息、常量、靜態(tài)變量、即時編譯后的代碼緩存。JDK7 及以前叫永久代PermGen由 JVM 堆管理JDK8 開始改成元空間Metaspace挪到了本地內(nèi)存由操作系統(tǒng)管。這個改動的影響被嚴重低估了。以前永久代容易OutOfMemoryError: PermGen space因為類加載多了會把堆里那塊固定區(qū)域撐爆JDK8 換成元空間之后元空間默認不設上限能一直吃到操作系統(tǒng)內(nèi)存耗盡報錯變成OutOfMemoryError: Metaspace而且更容易連帶觸發(fā)機器層面的不穩(wěn)定。所以-XX:MaxMetaspaceSize在 JDK8 里是必須顯式設置的參數(shù)不能放任不管。除了這幾塊還有兩塊容易被忽略但很要命的區(qū)域直接內(nèi)存Direct Memory通過-XX:MaxDirectMemorySize限制NIO 的DirectByteBuffer就住在這它不受堆大小約束以及JVM 自身的開銷包括 GC 元數(shù)據(jù)、JIT 編譯線程、線程?？偭?、代碼緩存等。這兩塊加起來經(jīng)常占到堆內(nèi)存的 30% 以上算容器內(nèi)存配額時漏掉就會被打死。1.2 對象從分配到回收的完整路徑理解對象的一生比背參數(shù)有用得多。新建對象優(yōu)先在Eden 區(qū)分配。如果開啟 TLAB-XX:UseTLAB默認開啟線程會先在 Eden 里劃一小塊私有區(qū)域避免多線程分配時爭搶指針。這塊優(yōu)化不顯眼但對高并發(fā)分配的影響很大。Eden 滿了觸發(fā)Minor GC。存活對象被復制到 Survivor 區(qū)From 到 To 來回復制對象年齡加 1。年齡達到閾值后晉升老年代閾值由-XX:MaxTenuringThreshold控制Parallel 和 G1 下默認是 15。這里有個很多人不知道的機制動態(tài)年齡判定。不是非得熬到 15 歲才能晉升。如果 Survivor 區(qū)中某一批同齡對象的總大小超過了 Survivor 空間的一半那么年齡大于等于這批對象年齡的所有對象會直接晉升老年代。這就是為什么有時候你把MaxTenuringThreshold調(diào)到 15實際對象三四歲就進老年代了——參數(shù)沒生效是動態(tài)判定提前觸發(fā)了。還有兩個特殊通道大對象直接進老年代。-XX:PretenureSizeThreshold可以設置這個閾值但它只對 Serial 和 ParNew 生效Parallel Scavenge 不認這個參數(shù)G1 里則用 Humongous Region 處理一個對象超過單個 Region 大小的一半就算大對象。長期存活對象。老年代滿了觸發(fā) Full GC這個代價通常比 Minor GC 高一到兩個數(shù)量級。反向看回收一個對象要經(jīng)過兩次標記第一次可達性分析從 GC Roots 出發(fā)掃描引用鏈不可達的對象被標記第二次檢查對象是否重寫了finalize()且未被調(diào)用過如果是就放進 F-Queue 等待執(zhí)行執(zhí)行完還沒被引用才真正回收。finalize()這個方法在實際項目里基本不該用它的執(zhí)行時機不確定還容易拖慢 GC。1.3 一次 Minor GC 的現(xiàn)場還原假設堆是 4G用 Parallel Scavenge默認新生代和老年代是 1:2那新生代約 1.33GEden 和兩個 Survivor 按 8:1:1 分Eden 約 1.06G每個 Survivor 約 133M。當 Eden 被填滿觸發(fā) Minor GC暫停所有應用線程Stop-The-World。從 GC Roots 出發(fā)標記 Eden 和當前 From Survivor 里的存活對象。把存活對象復制到 To Survivor年齡 1。清空 Eden 和 From Survivor然后 From 和 To 角色互換。關鍵點來了如果 To Survivor 裝不下所有存活對象多余的對象會通過“分配擔?！睓C制直接進老年代。這是最隱蔽的問題來源之一很多人看到老年代莫名其妙漲得快其實就是 Survivor 太小導致的提前晉升。提示如果你觀察到 Minor GC 之后老年代占用明顯上升先別急著調(diào) GC 策略先把-XX:SurvivorRatio和新生代大小重新算一遍。Survivor 太小是提前晉升最常見的原因。2. JDK8 里的垃圾回收器怎么挑JDK8 這個版本的好處是選擇多壞處也是選擇多。很多人上手就查“哪個回收器最好”這個問題問法本身就錯了——沒有最好的只有適配當前內(nèi)存規(guī)模、延遲要求和吞吐要求的。2.1 分代收集器的組合關系與適用邊界先搞清楚哪些回收器能配對。新生代和老年代各有各的實現(xiàn)必須成對使用。新生代回收器老年代回收器啟用方式特點SerialSerial Old-XX:UseSerialGC單線程客戶端模式或小內(nèi)存場景ParNewCMS-XX:UseConcMarkSweepGC低延遲響應優(yōu)先Parallel ScavengeParallel Old-XX:UseParallelGC吞吐優(yōu)先JDK8 默認G1自身管理整堆-XX:UseG1GC可預測停頓大堆首選補充一點容易搞混的JDK8 的默認回收器在服務端機器上CPU 大于 2 核、內(nèi)存大于 2G是 Parallel Scavenge Parallel Old在客戶端機器上是 Serial。所以很多項目其實一直跑在 Parallel 上從沒動過參數(shù)。Serial 系列現(xiàn)在基本只在嵌入式或者內(nèi)存極小的場景用得上。它的優(yōu)勢是簡單、沒有線程交互開銷、沒有額外內(nèi)存占用單核環(huán)境下反而比并行版本快。但如果你的堆有 8G 以上單線程回收一次全堆能卡秒級直接排除。2.2 Parallel、CMS、G1 的取舍邏輯Parallel Scavenge Parallel Old的核心目標是吞吐量也就是用戶代碼運行時間 / (用戶代碼時間 GC 時間)。它的設計取向是少停頓次數(shù)、多干活適合后臺批處理、離線計算、數(shù)據(jù)同步這類對單次停頓不敏感、但對整體算力敏感的場景。可調(diào)參數(shù)主要是兩個-XX:MaxGCPauseMillis設置最大停頓時間-XX:GCTimeRatio設置吞吐量目標默認 99即 GC 時間不超過 1%。注意MaxGCPauseMillis調(diào)小之后JVM 會自動縮小新生代代價是 GC 更頻繁、吞吐量下降。這是個蹺蹺板不能兩頭都要。CMS是 JDK8 時代低延遲的代表目標是縮短停頓代價是犧牲吞吐量并占用額外 CPU。它把老年代回收拆成四個階段初始標記STW很短、并發(fā)標記、重新標記STW、并發(fā)清除。最長的并發(fā)標記和并發(fā)清除階段是和應用線程同時跑的所以停頓短。但 CMS 有幾個硬傷這也是它后來被 G1 取代的原因浮動垃圾并發(fā)清理期間應用還在產(chǎn)生新垃圾這些只能等下一次。所以 CMS 不能等老年代滿了才動手默認老年代使用到 92% 就觸發(fā)-XX:CMSInitiatingOccupancyFraction通常要調(diào)到 70 到 80 留出余量。并發(fā)模式失敗Concurrent Mode Failure如果在并發(fā)清理期間老年代就被填滿了CMS 會退化成 Serial Old 做一次單線程 Full GC那個停頓就是災難級的。這是 CMS 線上事故的第一大來源。內(nèi)存碎片CMS 用的是標記-清除不做壓縮跑久了老年代全是碎片大對象分配不下又觸發(fā) Full GC。G1是 JDK8 里唯一兼顧吞吐和停頓、并且能處理大堆的通用回收器。JDK9 之后它成了默認但 JDK8 里需要手動開啟。它的整體思路是把堆切成很多等大的 Region每個 Region 可以動態(tài)扮演 Eden、Survivor、Old 或 Humongous然后基于“哪個 Region 垃圾最多”來優(yōu)先回收這就是 Garbage First 名字的由來。選型上我一般這么定堆小于 4G、追求吞吐、能接受百毫秒級停頓Parallel。堆 4G 到 8G、延遲敏感、有調(diào)優(yōu)經(jīng)驗CMS 或者 G1。CMS 需要精細調(diào)參G1 相對省心。堆大于 8G直接 G1別猶豫。CMS 在這個量級上的碎片和并發(fā)失敗風險太高。堆超過 16G、停頓要求 10ms 級JDK8 里 G1 也吃力這時候應該考慮升級 JDK 版本用 ZGC。2.3 G1 的 Region 模型與停頓預測原理G1 的參數(shù)里有個容易被忽略的-XX:G1HeapRegionSize。如果不設JVM 會自動推算規(guī)則大致是把整堆除以 2048 得到一個目標值然后向上取到 2 的冪且限制在 1M 到 32M 之間。比如 4G 堆4G/2048 2M那 Region 就是 2M16G 堆是 8M32G 堆是 16M。這個值為什么重要因為它決定了大對象的標準。超過 Region 一半的對象會被標記為 Humongous直接分配在連續(xù)的 Region 里且回收時機比較尷尬——如果它被判定為全垃圾會立刻回收否則要等并發(fā)標記周期結(jié)束。所以如果應用里有大量 1M 到幾 M 的緩存對象Region 設小了會產(chǎn)生一堆 HumongousGC 效率反而下降。我遇到過一個案例16G 堆沒設 Region 大小推算出來是 8M但業(yè)務里有大量 6M 左右的圖片緩存對象每個都觸發(fā) Humongous 分配GC 日志里全是Humongous字樣調(diào)大-XX:G1HeapRegionSize16m之后問題就沒了。G1 的停頓預測靠的是-XX:MaxGCPauseMillis默認 200ms。這里必須提醒一句這個值是目標不是承諾。G1 通過歷史回收數(shù)據(jù)估算哪些 Region 值得回收選出能在目標時間內(nèi)搞定的集合Collection Set。如果你把目標設成 10msG1 會幾乎收不動老年代最后堆積到并發(fā)模式失敗。經(jīng)驗值3 到 8G 堆設 100 到 200ms8G 以上設 200ms 就夠了別貪心。3. 參數(shù)怎么定從機器規(guī)格倒推 JVM 參數(shù)參數(shù)不是背下來的是算出來的。而且必須從機器規(guī)格和容器限制倒推不能拍腦袋設個大值。3.1 堆內(nèi)存、元空間、線程棧的賬要算清楚先說默認值很多人不知道默認堆是多少。JDK8 里-Xms默認是物理內(nèi)存的 1/64-Xmx默認是 1/4。真跑在生產(chǎn)上8G 的機器默認堆上限只有 2G而且初始堆小會經(jīng)歷一段不斷擴堆的過程每次都觸發(fā) Full GC。關于-Xms和-Xmx是否要一樣我的觀點很明確生產(chǎn)環(huán)境必須設成一樣。堆動態(tài)擴縮容本身是有代價的而且初始堆小會在啟動階段頻繁 GC。唯一例外是你確定這個應用是低頻的、內(nèi)存占用極小的邊緣服務那可以省點內(nèi)存。算賬的順序是這樣的以一臺 8G 內(nèi)存、8 核的機器為例第一步確定 JVM 總的可用內(nèi)存上限。這臺機器如果只跑這一個 Java 進程可以給到 6G留 2G 給操作系統(tǒng)和可能的外部依賴。如果是容器那容器 limit 才是硬邊界。第二步從這 6G 里扣掉堆外開銷元空間按類加載數(shù)量估。一般業(yè)務系統(tǒng) 200 到 300M 足夠用 Spring 全家桶加上動態(tài)代理的大項目給 512M 也是合理的。設-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m。直接內(nèi)存-XX:MaxDirectMemorySize256m用 Netty 或者大量 NIO 的項目要按實際連接數(shù)和緩沖區(qū)大小估算。線程棧-Xss默認 1M如果線程數(shù)峰值 500那就是 500M。線程數(shù)乘以棧大小是實打?qū)嵉拈_銷這就是為什么-Xss512k在這種場景下很有必要。代碼緩存-XX:ReservedCodeCacheSize默認 240MJDK8JIT 編譯的代碼放這里一般夠用。第三步剩下的才是堆。6G 減掉 512M 元空間、256M 直接內(nèi)存、512M 線程棧、240M 代碼緩存大約 4.5G那-Xmx4g是個穩(wěn)妥的取值。第四步劃分新生代。如果不用 G1新生代大小用-Xmn或-Xmn配合-XX:NewRatio控制。NewRatio是“老年代 : 新生代”的比值默認 2也就是新生代占整堆 1/3。對于短生命周期對象多的 Web 應用可以把比例調(diào)到 1:1 甚至新生代更大減少晉升壓力。注意-Xmn一旦顯式設置-XX:NewRatio就失效了而 G1 里-Xmn會被忽略需要用-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent默認 5% 和 60%來控制新生代占比。這幾個參數(shù)互相覆蓋的關系是調(diào)參時最容易翻車的地方。3.2 GC 日志參數(shù)在 JDK8 下的正確寫法生產(chǎn)上不開 GC 日志就是閉眼開車。JDK8 的日志參數(shù)和 JDK9 之后完全不同別混著寫。-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -XX:PrintHeapAtGC -XX:PrintTenuringDistribution -XX:PrintGCApplicationStoppedTime -Xloggc:/data/logs/gc-%t.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize50M逐個說作用PrintGCDetails輸出詳細日志包含各代容量變化PrintGCDateStamps加絕對時間戳排查問題必須要有PrintGCTimeStamps加相對 JVM 啟動的時間PrintHeapAtGC在每次 GC 前后打印堆布局量很大一般排查期開穩(wěn)定后關掉PrintTenuringDistribution打印對象年齡分布判斷提前晉升全靠它PrintGCApplicationStoppedTime打印 STW 總時長這個是判斷“接口偶爾卡頓”的直接證據(jù)。-Xloggc后面加%t會用啟動時間戳命名文件避免重啟覆蓋。配合輪轉(zhuǎn)參數(shù)10 個文件每個 50M一共 500M基本夠追一周的問題。JDK8 的日志文件名參數(shù)是-XX:GCLogFileSize注意 JDK9 之后這套全被-Xlog:gc*:filexxx:time,uptime,level,tags取代了網(wǎng)上搜到的參數(shù)經(jīng)?；熘鴣韺χ姹境?.3 三檔常見規(guī)格的參數(shù)模板下面這三套是我自己在項目里反復用過的可以直接作為起點再根據(jù) GC 日志微調(diào)。4C8G堆 4GWeb 服務延遲敏感G1-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize4m -XX:InitiatingHeapOccupancyPercent45 -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:MaxDirectMemorySize256m -Xss512k -XX:ParallelRefProcEnabled -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/dump/InitiatingHeapOccupancyPercent默認 45意思是老年代占用達到整堆 45% 就啟動并發(fā)標記周期。如果日志里經(jīng)常出現(xiàn)to-space exhausted或者Evacuation Failure說明這個值太高標記得太晚要往下調(diào)到 35 到 40。8C16G堆 8G數(shù)據(jù)同步吞吐優(yōu)先Parallel-Xms8g -Xmx8g -XX:UseParallelGC -XX:ParallelGCThreads8 -XX:MaxGCPauseMillis500 -XX:GCTimeRatio99 -Xmn3g -XX:SurvivorRatio8 -XX:MaxTenuringThreshold15 -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -Xss512kParallelGCThreads默認是按 CPU 核數(shù)算的約等于核數(shù)超過 8 核時按公式縮減顯式設置成 8 是為了避免容器里 CPU 配額識別不準導致線程數(shù)異常。SurvivorRatio8是 Eden 和一個 Survivor 的比例所以新生代里 Eden 占 80%。16C32G堆 16G核心交易低延遲G1-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis150 -XX:G1HeapRegionSize8m -XX:InitiatingHeapOccupancyPercent40 -XX:G1NewSizePercent10 -XX:G1MaxNewSizePercent40 -XX:ConcGCThreads4 -XX:ParallelGCThreads12 -XX:UnlockExperimentalVMOptions -XX:UseStringDeduplication -XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g -Xss512kUseStringDeduplication是 G1 獨有的字符串去重能省下不少堆但會消耗額外的 CPU 和并發(fā)線程只在字符串重復度高的場景比如大量 JSON 解析才值得開。ConcGCThreads是并發(fā)標記線程數(shù)默認是ParallelGCThreads/4設太大反而搶業(yè)務 CPU。4. 工具鏈命令行四件套加 Arthas 的組合拳工具不在多在于知道什么時候用哪個。我的習慣是現(xiàn)場診斷先用命令行四件套需要動態(tài)追蹤再上 Arthas需要看趨勢圖才開 VisualVM。4.1 jps、jstat、jmap、jstack 的準確用法與坑jps用來找進程號最基礎的入口。jps -l # 輸出主類全名 jps -lv # 加上 JVM 參數(shù)確認啟動參數(shù)是不是你想要的jps -lv這個用法我強烈推薦排查“參數(shù)改了沒生效”這類問題時一眼就能看出實際生效的參數(shù)。jstat用來看 GC 實時數(shù)據(jù)每秒一次打十次jstat -gcutil 12345 1000 10輸出里的S0、S1、E、O、M是各區(qū)域使用百分比YGC/YGCT是新生代 GC 次數(shù)和總耗時FGC/FGCT是老年代 GC 次數(shù)和總耗時GCT是總耗時。判斷標準很簡單FGC 一直漲就是有問題正常穩(wěn)定的服務 FGC 應該長期不變FGCT / FGC得到的單次 Full GC 平均耗時超過 1 秒就需要處理。常用變體還有-gcnew只看新生代、-gcold只看老年代、-gccapacity看各區(qū)域容量。jmap用來做堆分析但有兩個坑必須先說jmap -heap 12345 # 查看堆配置和使用情況 jmap -histo 12345 | head -30 # 對象直方圖看誰占內(nèi)存 jmap -dump:formatb,file/tmp/heap.hprof 12345 # 導出堆快照第一個坑jmap -histo:live帶live會先觸發(fā)一次 Full GC 再統(tǒng)計線上執(zhí)行就是一次幾十秒的停頓除非萬不得已別在生產(chǎn)上用。用jmap -histo不帶 live 時統(tǒng)計的是所有對象包括待回收的會虛高但沒停頓風險先粗看足夠了。第二個坑jmap -dump在堆大的時候非常慢而且會 STW。8G 堆導出一次可能要一兩分鐘甚至更久業(yè)務直接受影響。正確的做法是配置-XX:HeapDumpOnOutOfMemoryError讓它自動在 OOM 時 dump或者從負載均衡摘掉節(jié)點再手動導。jstack用來看線程棧jstack -l 12345 /tmp/stack.log-l會額外打印鎖信息Locked ownable synchronizers排查死鎖必須加。想找死鎖也可以直接用jstack輸出后搜Found one Java-level deadlockJVM 會自動檢測并打印出來。排查 CPU 飆高的標準流程是先用top -Hp pid找出占 CPU 最高的線程 ID把它轉(zhuǎn)成十六進制再到 jstack 輸出里搜nid0x加那個十六進制值定位到具體代碼行。top -Hp 12345 printf %x\n 12346 # 假設高 CPU 線程是 12346得到 0x303a jstack 12345 | grep -A 30 nid0x303a4.2 VisualVM、JConsole、Arthas 的上手姿勢JConsole現(xiàn)在基本只作為兜底工具界面老、功能弱但勝在自帶。看內(nèi)存曲線、手動觸發(fā) GC 這些它能干看看線程數(shù)變化也夠。VisualVM是 JDK8 時代最順手的圖形化工具jvisualvm命令直接啟動。裝上 Visual GC 插件之后能實時看到 Eden、Survivor、老年代、元空間的曲線一眼就能看出內(nèi)存是不是鋸齒狀健康回收還是在緩慢爬升。判斷內(nèi)存泄漏最快的方式就是看這條曲線正常是鋸齒泄漏是一路向上、GC 之后回不到原位置。Arthas是后來居上的利器尤其是不能重啟的線上環(huán)境。核心命令我常用的就幾個dashboard # 總覽包含線程、內(nèi)存、GC 情況 thread -n 3 # 找 CPU 占用最高的 3 個線程 thread -b # 直接找阻塞其他線程的元兇 heapdump /tmp/a.hprof # 導出堆快照 trace com.xxx.Service method # 追蹤方法內(nèi)部調(diào)用耗時 watch com.xxx.Service method {params, returnObj} -x 2 # 觀察入?yún)⒑头祷刂祎hread -b這個命令救過我好幾次它能直接告訴你哪個線程持有鎖不放導致別的線程全卡住了比翻 jstack 快得多。但trace和watch在高頻方法上有明顯性能損耗用完一定要stop掉我見過有人忘了 stop第二天發(fā)現(xiàn)接口 P99 漲了三倍。dashboard里還有個細節(jié)值得看GC 那一欄會顯示各代的使用率曲線和 GC 次數(shù)。如果老年代使用率穩(wěn)定在 90% 以上且 FGC 緩慢增長就是內(nèi)存不夠或者有輕微泄漏的信號。4.3 一次 Full GC 頻繁的完整排查記錄說個真實場景。一個訂單查詢服務8G 堆用 Parallel上線兩周后監(jiān)控報 FGC 每小時從 0 漲到 20 多次每次約 1.5 秒高峰期接口超時。排查步驟第一步jstat -gcutil看趨勢。確認 YGC 正常每秒幾次每次 20ms 左右但老年代占用在 GC 后從 40% 一路爬到 95%然后 Full GC 打回 40%。GC 后老年代能回落到 40%說明沒有嚴重泄漏只是對象產(chǎn)生速度超過了回收能力。第二步加-XX:PrintTenuringDistribution重啟一個實例。日志里看到大量對象年齡是 1 和 2 就直接晉升了。結(jié)合年齡分布算一下Survivor 里的同齡對象總大小確實超過了 Survivor 一半動態(tài)年齡判定在起作用。第三步看新生代參數(shù)。原來是-Xmn2g -XX:SurvivorRatio8新生代 2GEden 1.6G每個 Survivor 只有 200M。而請求高峰期 Eden 每秒產(chǎn)生大約 400M 垃圾Survivor 根本裝不下存活的跨越對象。第四步調(diào)整。把-Xmn從 2G 提到 2.7GSurvivorRatio從 8 改成 6Survivor 變成約 337M同時把MaxTenuringThreshold顯式設為 15 防止被過早抬高。老年代從 5.3G 縮小到 4.6G。第五步觀察。改完后 FGC 從每小時 20 多次降到每天 1 到 2 次YGC 頻率略升但單次耗時沒變整體 P99 從 800ms 降到 120ms。這個過程里最關鍵的一步其實是第二步——加PrintTenuringDistribution看到年齡分布沒有這個信息前面所有的調(diào)整都是猜。5. OOM 與各類異常場景的排查套路OOM 不是一個錯誤是一類錯誤的統(tǒng)稱。不同后綴的 OOM 指向完全不同的根因處理方法也完全不同。把報錯后綴看懂排查能省一半時間。5.1 八種 OOM 的成因與定位方法報錯后綴觸發(fā)位置常見根因處理方向Java heap space堆大量對象未釋放、緩存無上限、查詢?nèi)砑虞d看 heap dump 找大對象檢查緩存淘汰策略GC overhead limit exceeded堆GC 花了 98% 以上時間卻只回收不到 2% 的空間基本等同于內(nèi)存泄漏先加堆續(xù)命再找泄漏點Metaspace元空間動態(tài)生成類太多CGLIB、反射、腳本引擎設 MaxMetaspaceSize檢查是否每次調(diào)用都創(chuàng)建新類加載器Direct buffer memory直接內(nèi)存NIO 緩沖區(qū)未釋放、Netty 池配置不當設 MaxDirectMemorySize檢查 ByteBuf 是否 releaseunable to create new native thread操作系統(tǒng)線程數(shù)超過系統(tǒng)限制、線程棧太大查 ulimit、線程數(shù)上限、是否存在線程泄漏Requested array size exceeds VM limit堆申請數(shù)組長度超過 int 上限附近通常代碼邏輯錯誤檢查數(shù)組長度計算Kill process or sacrifice child操作系統(tǒng)進程被 OOM Killer 殺掉容器內(nèi)存配額不足或堆外內(nèi)存超限Compressed class space元空間壓縮類指針空間耗盡調(diào)-XX:CompressedClassSpaceSize這里重點說兩個最容易被誤判的。GC overhead limit exceeded經(jīng)常被當成“內(nèi)存不夠”于是加堆結(jié)果只是把崩潰時間推遲。它的本質(zhì)是垃圾產(chǎn)生速率超過了回收速率加堆不能降低產(chǎn)生速率。正確姿勢是先用jmap -histo看對象分布如果是某個業(yè)務對象數(shù)量異常就去查對應的業(yè)務邏輯如果是HashMap$Node或者byte[]占了大頭八成是某個緩存容器沒有上限。unable to create new native thread的詭異之處在于堆內(nèi)存可能還很空但就是創(chuàng)建不了線程。原因通常是三種一是操作系統(tǒng)ulimit -u限制了單用戶進程數(shù)二是線程棧 1M 乘以線程數(shù)吃掉了大量內(nèi)存堆又開得大兩邊一起把物理內(nèi)存擠爆三是線程池創(chuàng)建了太多核心線程。我遇到過Executors.newCachedThreadPool()在突發(fā)流量下創(chuàng)建了上萬個線程的情況改成有界隊列的ThreadPoolExecutor之后就好了。順帶說一句線程池和 JVM 的關系線程池里每個線程都要占用一份?？臻g所以最大線程數(shù)乘以-Xss是必須從內(nèi)存預算里扣掉的。有人算過“最大線程數(shù) JVM 剩余可用線程”這個思路是對的但實際約束往往來自操作系統(tǒng)限制而不是堆內(nèi)存。合理的做法是把最大線程數(shù)控制在幾百這個量級配合有界隊列和合適的拒絕策略。5.2 CPU 飆高、GC 停頓、內(nèi)存泄漏怎么查CPU 飆高的三種典型模式第一種業(yè)務線程在跑密集計算或者死循環(huán)。用前面說的top -Hp加jstack定位到具體方法能看到線程一直停在同一個方法棧上。第二種GC 線程在瘋狂跑。表現(xiàn)是top里 GC 線程名字帶GC或者G1占用很高jstat里 YGC 或 FGC 頻率暴漲。這時候要處理的是內(nèi)存問題不是 CPU 問題。第三種頻繁的上下文切換。pidstat -w -p pid 1能看到cswch/s很高一般是鎖競爭嚴重。用jstack搜BLOCKED狀態(tài)的線程或者用 Arthas 的thread -b。GC 停頓的排查要區(qū)分是 Young GC 還是 Full GC 的停頓。判斷方式看PrintGCApplicationStoppedTime的輸出里面會列出每次 STW 的持續(xù)時間。如果 STW 時間遠大于 GC 日志里標注的 GC 時間那說明停頓另有原因——可能是在做偏向鎖撤銷、類加載、或者 JIT 反優(yōu)化。這個坑很深見過一次線上停頓 300ms 但 GC 日志顯示只停了 20ms 的情況最后查出來是 JVM 在做大量偏向鎖批量撤銷用-XX:-UseBiasedLocking關掉偏向鎖才解決。內(nèi)存泄漏的定位流程我固定這么走先用jstat -gcutil觀察老年代在 Full GC 后能否回落。能回落說明只是壓力大不能回落才是泄漏。然后用jmap -histo看對象排名對比兩次相隔幾分鐘的輸出看哪個類的實例數(shù)在持續(xù)增長。這一步不需要 dump 文件開銷小適合線上。鎖定可疑類之后再找個低峰期導 heap dump用 MAT 或者 JProfiler 打開看這個類的 GC Roots 引用鏈。MAT 的Dominator Tree視圖能直接告訴你誰占內(nèi)存最多Path to GC Roots能告訴你為什么這個對象回收不掉。常見的原因就那么幾個靜態(tài) Map 只增不減、ThreadLocal 用完沒 remove、監(jiān)聽器注冊后沒注銷、連接池/線程池未關閉。注意ThreadLocal 泄漏是重災區(qū)。線程池里的線程是復用的ThreadLocal 如果不在 finally 里 remove它引用的對象會一直活到線程銷毀而線程池的線程基本不會銷毀。5.3 開發(fā)環(huán)境與容器環(huán)境的調(diào)優(yōu)注意點IDEA 本身的 JVM 調(diào)優(yōu)也值得說兩句因為開發(fā)機的卡頓經(jīng)常被誤判成代碼問題。IDEA 的 JVM 參數(shù)在Help Edit Custom VM Options里改配置文件是idea.vmoptions。默認堆上限通常只有 750M 到 1G對于大型項目多模塊、大量索引根本不夠。-Xms1g -Xmx4g -XX:ReservedCodeCacheSize512m -XX:UseG1GC -XX:SoftRefLRUPolicyMSPerMB50 -XX:CICompilerCount2ReservedCodeCacheSize調(diào)大到 512M 是因為 IDEA 的索引和插件代碼量巨大默認 240M 經(jīng)常觸發(fā) JIT 代碼緩存滿表現(xiàn)就是 CPU 突然飆高、卡頓日志里能看到CodeCache is full的提示。SoftRefLRUPolicyMSPerMB50讓軟引用更快被回收減少內(nèi)存壓力。注意如果你開了大量插件導致 CPU 高先試試File Invalidate Caches重建索引比調(diào)參有用。容器環(huán)境的坑更隱蔽。JDK8 在 8u191 之前的版本JVM 根本識別不到容器的 cgroup 限制它會讀到宿主機的物理內(nèi)存然后按 1/4 算堆上限。容器 limit 是 2G宿主機 64G堆就開了 16G一啟動就被 OOM Killer 干掉。查版本java -version看構(gòu)建號。8u191 及以后默認開啟-XX:UseContainerSupport能正確讀取容器限制。更早的版本要么升級要么老老實實手動寫死-Xmx。即使在 8u191 之后容器里也建議顯式設堆。因為在容器里堆外內(nèi)存元空間、直接內(nèi)存、線程棧、JVM 自身都算在容器配額內(nèi)堆設成 limit 的 70% 到 75% 是比較穩(wěn)的比例剩下的留給堆外。見過太多“容器 limit 4G堆設 4G跑一會兒就被 Kill”的案例。6. GC 日志判讀與批量壓測調(diào)優(yōu)日志是唯一的客觀證據(jù)。很多人調(diào)優(yōu)調(diào)不好不是不懂參數(shù)是不會讀日志。6.1 三種回收器的日志格式對比Parallel 的 Young GC 日志2024-03-15T10:23:45.1230800: 25.456: [GC (Allocation Failure) [PSYoungGen: 65536K-10752K(76288K)] 65536K-11664K(251392K), 0.0234567 secs] [Times: user0.09 sys0.01, real0.02 secs]拆開看25.456是 JVM 啟動后的秒數(shù)Allocation Failure是觸發(fā)原因表示新生代沒空間分配了PSYoungGen: 65536K-10752K(76288K)表示新生代從 64M 降到 10.5M總?cè)萘?74.5M65536K-11664K(251392K)是整個堆從 64M 降到 11.4M堆總?cè)萘?245.5M0.0234567 secs是這次 GC 的耗時Times里的user是所有 GC 線程消耗的 CPU 時間總和real是實際墻鐘時間。user 遠大于 real 說明并行度好user 接近 real 說明基本是串行在跑。CMS 的日志會多出幾個階段2024-03-15T10:23:45.1230800: 25.456: [GC (CMS Initial Mark) [1 CMS-initial-mark: 131072K(174784K)] 145600K(251392K), 0.0012345 secs] 2024-03-15T10:23:45.2000800: 25.533: [CMS-concurrent-mark-start] 2024-03-15T10:23:45.8000800: 26.133: [CMS-concurrent-mark: 0.567/0.600 secs] 2024-03-15T10:23:45.8100800: 26.143: [CMS-concurrent-preclean-start] 2024-03-15T10:23:46.1000800: 26.433: [CMS-concurrent-preclean: 0.290/0.290 secs] 2024-03-15T10:23:46.1100800: 26.443: [GC (CMS Final Remark) [YG occupancy: 80000 K (131072 K)] 0.0850000 secs] 2024-03-15T10:23:46.2000800: 26.533: [CMS-concurrent-sweep-start] 2024-03-15T10:23:47.5000800: 27.833: [CMS-concurrent-sweep: 1.300/1.300 secs]看 CMS 日志只關心兩個有 STW 的階段CMS Initial Mark和CMS Final Remark。這兩個的耗時才是真正影響業(yè)務的。中間的concurrent-mark、preclean、sweep都是并發(fā)的耗時再長也只影響吞吐。如果 Final Remark 時間很長通常是新生代對象多導致重新標記工作量大可以調(diào)-XX:CMSScheduleRemarkEdenPenetration之類的高級參數(shù)但更簡單的辦法是減小新生代。G1 的日志信息量最大2024-03-15T10:23:45.1230800: 25.456: [GC pause (G1 Evacuation Pause) (young), 0.0234567 secs] [Parallel Time: 18.2 ms, GC Workers: 8] [GC Worker Start (ms): Min: 25456.1, Avg: 25456.3, Max: 25456.5, Diff: 0.4] [Ext Root Scanning (ms): Avg: 0.5, Max: 1.1, Sum: 4.0] [Update RS (ms): Avg: 0.8, Max: 1.5, Sum: 6.4] [Scan RS (ms): Avg: 0.3, Max: 0.9, Sum: 2.4] [Object Copy (ms): Avg: 12.1, Max: 14.3, Sum: 96.8] [Eden: 512.0M(512.0M)-0.0B(504.0M) Survivors: 4096.0K-8192.0K Heap: 1024.0M(2048.0M)-530.0M(2048.0M)]重點看Parallel Time和各個子階段的耗時。如果Ext Root Scanning很高說明 GC Roots比如大量線程、大量類太多了檢查線程數(shù)是不是失控如果Update RS或Scan RS高說明跨 Region 引用多Remembered Set 維護壓力大通常意味著老年代對象和新生代對象交互頻繁得考慮對象是不是過度分散了如果Object Copy占大頭那就是存活對象太多得減小新生代或者減少對象存活時間。6.2 關鍵指標與判讀閾值我整理了一張自己常用的閾值表長時間越界就要動手了。指標獲取方式健康范圍越界含義YGC 頻率jstat 里 YGC 變化率每秒小于 5 次新生代太小或?qū)ο蠓峙渌俾蔬^高YGC 單次耗時YGCT / YGC小于 50ms存活對象太多Survivor 不夠FGC 頻率jstat 里 FGC 變化率每天少于 2 次老年代不夠或有泄漏FGC 單次耗時FGCT / FGC小于 1s堆太大或回收器選擇不當GC 總時間占比GCT / 運行時長小于 5%吞吐量受損需要重新選型老年代 GC 后占用jstat 里 O穩(wěn)定不持續(xù)上升持續(xù)上升即有泄漏STW 總時長PrintGCApplicationStoppedTime單次小于 200ms影響接口 P99這張表里我覺得最該盯的是最后一個STW 總時長。因為它包含了 GC 之外的停頓原因是對用戶最直接的影響。只看 GC 耗時很容易漏掉偏向鎖撤銷、類加載、JIT 反優(yōu)化這些隱性停頓。6.3 壓測對比的落地做法調(diào)優(yōu)最后一步必須驗證而且不能只在一個參數(shù)下跑。我一般的做法是準備一組參數(shù)組合在同一臺機器、同一份壓測流量下逐個跑收集 GC 日志后用腳本對比。先寫個提取腳本把日志里的關鍵指標算出來#!/bin/bash LOG$1 echo 文件: $LOG echo YGC 次數(shù): $(grep -c GC (Allocation Failure) $LOG) echo Full GC 次數(shù): $(grep -c Full GC $LOG) echo 平均 STW: $(grep Total time for which application threads were stopped $LOG | awk {s$10; n} END {printf %.2f ms\n, s/n*1000}) echo 最長 STW: $(grep Total time for which application threads were stopped $LOG | awk {if($10m) m$10} END {printf %.2f ms\n, m*1000})然后準備三到四組參數(shù)比如新生代 2G、2.7G、3.2G 三檔每組用同樣的壓測流量跑 30 分鐘收集日志之后橫向?qū)Ρ取簻y工具用什么不重要關鍵是流量模型要貼近真實——尤其是對象創(chuàng)建速率和對象存活時間這兩個特征必須和線上一致否則調(diào)出來的參數(shù)沒有參考價值。我自己踩過的一個坑是在壓測環(huán)境用簡單的接口壓對象創(chuàng)建快、存活短調(diào)出來的參數(shù)是新生代越大越好但線上業(yè)務的對象存活時間明顯長兩個環(huán)境的最優(yōu)參數(shù)完全不同。后來我改成從線上拉一份真實的請求采樣做流量回放參數(shù)才有參考意義。還有個實用技巧參數(shù)不要一次改多個。有人喜歡一次改五六項跑出來效果好也不知道是哪項起的作用效果差更不知道是哪項搞壞了。一次改一到兩項觀察至少半小時記錄下變化這才是可積累的調(diào)優(yōu)經(jīng)驗。最后再分享一個我自己的做法把每次調(diào)優(yōu)的參數(shù)、機器規(guī)格、前后 GC 指標記錄在一個表格里。跑的項目多了之后這張表就成了自己的經(jīng)驗庫新項目上手時直接找規(guī)格相近的那一行做起點比從零開始試快得多。尤其是內(nèi)存規(guī)格在 4G 到 16G 這個區(qū)間很多業(yè)務形態(tài)的參數(shù)其實高度相似復用率相當高。 JDK8 JVM調(diào)優(yōu)與GC實戰(zhàn)：回收器選型、參數(shù)模板及OOM排查
現(xiàn)在團隊里只要有人問“線上接口偶爾卡個幾百毫秒是什么原因”十有八九最后都會落到 JVM 調(diào)優(yōu)和垃圾回收器這個話題上尤其是還在跑 JDK8 的項目。JDK8 是個很特殊的分水嶺它既有成熟的 Parallel Scavenge 和 CMS又帶來了 G1還徹底刪掉了永久代改用元空間。這意味著同樣一段“加大堆內(nèi)存、調(diào)小新生代”的老經(jīng)驗放在 JDK8 上可能反而把系統(tǒng)推向頻繁 Full GC。這篇內(nèi)容我打算按自己的實戰(zhàn)路徑來寫——先把內(nèi)存模型和對象生命周期講透再逐個拆解 JDK8 里能用的垃圾回收器然后給出可以直接抄的參數(shù)模板、工具鏈用法、GC 日志判讀方法最后落到 OOM 的各種現(xiàn)場。適合正在做服務端開發(fā)、需要處理線上性能問題或者準備面試想真正搞懂 JVM 工作原理的人。1. 先把 JVM 內(nèi)存模型捋直調(diào)優(yōu)才有坐標系我見過太多“調(diào)優(yōu)”是這么做的上來就-Xmx4g然后看 GC 日志里 Full GC 次數(shù)少了就完事。這種做法能碰對是運氣碰不對就是埋雷。真正動手前必須把內(nèi)存模型這張地圖在腦子里畫出來否則你連參數(shù)改的是哪塊區(qū)域都不知道。1.1 運行時數(shù)據(jù)區(qū)到底分幾塊JDK8 改了什么JVM 在運行時會把自己管的內(nèi)存切成幾塊每塊職責不同回收策略也完全不同。按線程私有和線程共享來分理解起來最快。線程私有的三塊程序計數(shù)器記錄當前線程執(zhí)行到哪條字節(jié)碼指令。唯一不會拋 OOM 的區(qū)域占用的內(nèi)存可以忽略不計。虛擬機棧每個方法調(diào)用創(chuàng)建一個棧幀棧幀里放局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口。平時說的“棧溢出”絕大多數(shù)就是這里由-Xss控制單個線程棧大小。本地方法棧給 native 方法用的HotSpot 里和虛擬機棧合并實現(xiàn)一般不單獨關心。線程共享的兩塊堆對象實例和數(shù)組的主要存放地也是垃圾回收的主戰(zhàn)場。調(diào)優(yōu) 90% 的參數(shù)都在動這塊。方法區(qū)存放類元信息、常量、靜態(tài)變量、即時編譯后的代碼緩存。JDK7 及以前叫永久代PermGen由 JVM 堆管理JDK8 開始改成元空間Metaspace挪到了本地內(nèi)存由操作系統(tǒng)管。這個改動的影響被嚴重低估了。以前永久代容易OutOfMemoryError: PermGen space因為類加載多了會把堆里那塊固定區(qū)域撐爆JDK8 換成元空間之后元空間默認不設上限能一直吃到操作系統(tǒng)內(nèi)存耗盡報錯變成OutOfMemoryError: Metaspace而且更容易連帶觸發(fā)機器層面的不穩(wěn)定。所以-XX:MaxMetaspaceSize在 JDK8 里是必須顯式設置的參數(shù)不能放任不管。除了這幾塊還有兩塊容易被忽略但很要命的區(qū)域直接內(nèi)存Direct Memory通過-XX:MaxDirectMemorySize限制NIO 的DirectByteBuffer就住在這它不受堆大小約束以及JVM 自身的開銷包括 GC 元數(shù)據(jù)、JIT 編譯線程、線程?？偭?、代碼緩存等。這兩塊加起來經(jīng)常占到堆內(nèi)存的 30% 以上算容器內(nèi)存配額時漏掉就會被打死。1.2 對象從分配到回收的完整路徑理解對象的一生比背參數(shù)有用得多。新建對象優(yōu)先在Eden 區(qū)分配。如果開啟 TLAB-XX:UseTLAB默認開啟線程會先在 Eden 里劃一小塊私有區(qū)域避免多線程分配時爭搶指針。這塊優(yōu)化不顯眼但對高并發(fā)分配的影響很大。Eden 滿了觸發(fā)Minor GC。存活對象被復制到 Survivor 區(qū)From 到 To 來回復制對象年齡加 1。年齡達到閾值后晉升老年代閾值由-XX:MaxTenuringThreshold控制Parallel 和 G1 下默認是 15。這里有個很多人不知道的機制動態(tài)年齡判定。不是非得熬到 15 歲才能晉升。如果 Survivor 區(qū)中某一批同齡對象的總大小超過了 Survivor 空間的一半那么年齡大于等于這批對象年齡的所有對象會直接晉升老年代。這就是為什么有時候你把MaxTenuringThreshold調(diào)到 15實際對象三四歲就進老年代了——參數(shù)沒生效是動態(tài)判定提前觸發(fā)了。還有兩個特殊通道大對象直接進老年代。-XX:PretenureSizeThreshold可以設置這個閾值但它只對 Serial 和 ParNew 生效Parallel Scavenge 不認這個參數(shù)G1 里則用 Humongous Region 處理一個對象超過單個 Region 大小的一半就算大對象。長期存活對象。老年代滿了觸發(fā) Full GC這個代價通常比 Minor GC 高一到兩個數(shù)量級。反向看回收一個對象要經(jīng)過兩次標記第一次可達性分析從 GC Roots 出發(fā)掃描引用鏈不可達的對象被標記第二次檢查對象是否重寫了finalize()且未被調(diào)用過如果是就放進 F-Queue 等待執(zhí)行執(zhí)行完還沒被引用才真正回收。finalize()這個方法在實際項目里基本不該用它的執(zhí)行時機不確定還容易拖慢 GC。1.3 一次 Minor GC 的現(xiàn)場還原假設堆是 4G用 Parallel Scavenge默認新生代和老年代是 1:2那新生代約 1.33GEden 和兩個 Survivor 按 8:1:1 分Eden 約 1.06G每個 Survivor 約 133M。當 Eden 被填滿觸發(fā) Minor GC暫停所有應用線程Stop-The-World。從 GC Roots 出發(fā)標記 Eden 和當前 From Survivor 里的存活對象。把存活對象復制到 To Survivor年齡 1。清空 Eden 和 From Survivor然后 From 和 To 角色互換。關鍵點來了如果 To Survivor 裝不下所有存活對象多余的對象會通過“分配擔?！睓C制直接進老年代。這是最隱蔽的問題來源之一很多人看到老年代莫名其妙漲得快其實就是 Survivor 太小導致的提前晉升。提示如果你觀察到 Minor GC 之后老年代占用明顯上升先別急著調(diào) GC 策略先把-XX:SurvivorRatio和新生代大小重新算一遍。Survivor 太小是提前晉升最常見的原因。2. JDK8 里的垃圾回收器怎么挑JDK8 這個版本的好處是選擇多壞處也是選擇多。很多人上手就查“哪個回收器最好”這個問題問法本身就錯了——沒有最好的只有適配當前內(nèi)存規(guī)模、延遲要求和吞吐要求的。2.1 分代收集器的組合關系與適用邊界先搞清楚哪些回收器能配對。新生代和老年代各有各的實現(xiàn)必須成對使用。新生代回收器老年代回收器啟用方式特點SerialSerial Old-XX:UseSerialGC單線程客戶端模式或小內(nèi)存場景ParNewCMS-XX:UseConcMarkSweepGC低延遲響應優(yōu)先Parallel ScavengeParallel Old-XX:UseParallelGC吞吐優(yōu)先JDK8 默認G1自身管理整堆-XX:UseG1GC可預測停頓大堆首選補充一點容易搞混的JDK8 的默認回收器在服務端機器上CPU 大于 2 核、內(nèi)存大于 2G是 Parallel Scavenge Parallel Old在客戶端機器上是 Serial。所以很多項目其實一直跑在 Parallel 上從沒動過參數(shù)。Serial 系列現(xiàn)在基本只在嵌入式或者內(nèi)存極小的場景用得上。它的優(yōu)勢是簡單、沒有線程交互開銷、沒有額外內(nèi)存占用單核環(huán)境下反而比并行版本快。但如果你的堆有 8G 以上單線程回收一次全堆能卡秒級直接排除。2.2 Parallel、CMS、G1 的取舍邏輯Parallel Scavenge Parallel Old的核心目標是吞吐量也就是用戶代碼運行時間 / (用戶代碼時間 GC 時間)。它的設計取向是少停頓次數(shù)、多干活適合后臺批處理、離線計算、數(shù)據(jù)同步這類對單次停頓不敏感、但對整體算力敏感的場景。可調(diào)參數(shù)主要是兩個-XX:MaxGCPauseMillis設置最大停頓時間-XX:GCTimeRatio設置吞吐量目標默認 99即 GC 時間不超過 1%。注意MaxGCPauseMillis調(diào)小之后JVM 會自動縮小新生代代價是 GC 更頻繁、吞吐量下降。這是個蹺蹺板不能兩頭都要。CMS是 JDK8 時代低延遲的代表目標是縮短停頓代價是犧牲吞吐量并占用額外 CPU。它把老年代回收拆成四個階段初始標記STW很短、并發(fā)標記、重新標記STW、并發(fā)清除。最長的并發(fā)標記和并發(fā)清除階段是和應用線程同時跑的所以停頓短。但 CMS 有幾個硬傷這也是它后來被 G1 取代的原因浮動垃圾并發(fā)清理期間應用還在產(chǎn)生新垃圾這些只能等下一次。所以 CMS 不能等老年代滿了才動手默認老年代使用到 92% 就觸發(fā)-XX:CMSInitiatingOccupancyFraction通常要調(diào)到 70 到 80 留出余量。并發(fā)模式失敗Concurrent Mode Failure如果在并發(fā)清理期間老年代就被填滿了CMS 會退化成 Serial Old 做一次單線程 Full GC那個停頓就是災難級的。這是 CMS 線上事故的第一大來源。內(nèi)存碎片CMS 用的是標記-清除不做壓縮跑久了老年代全是碎片大對象分配不下又觸發(fā) Full GC。G1是 JDK8 里唯一兼顧吞吐和停頓、并且能處理大堆的通用回收器。JDK9 之后它成了默認但 JDK8 里需要手動開啟。它的整體思路是把堆切成很多等大的 Region每個 Region 可以動態(tài)扮演 Eden、Survivor、Old 或 Humongous然后基于“哪個 Region 垃圾最多”來優(yōu)先回收這就是 Garbage First 名字的由來。選型上我一般這么定堆小于 4G、追求吞吐、能接受百毫秒級停頓Parallel。堆 4G 到 8G、延遲敏感、有調(diào)優(yōu)經(jīng)驗CMS 或者 G1。CMS 需要精細調(diào)參G1 相對省心。堆大于 8G直接 G1別猶豫。CMS 在這個量級上的碎片和并發(fā)失敗風險太高。堆超過 16G、停頓要求 10ms 級JDK8 里 G1 也吃力這時候應該考慮升級 JDK 版本用 ZGC。2.3 G1 的 Region 模型與停頓預測原理G1 的參數(shù)里有個容易被忽略的-XX:G1HeapRegionSize。如果不設JVM 會自動推算規(guī)則大致是把整堆除以 2048 得到一個目標值然后向上取到 2 的冪且限制在 1M 到 32M 之間。比如 4G 堆4G/2048 2M那 Region 就是 2M16G 堆是 8M32G 堆是 16M。這個值為什么重要因為它決定了大對象的標準。超過 Region 一半的對象會被標記為 Humongous直接分配在連續(xù)的 Region 里且回收時機比較尷尬——如果它被判定為全垃圾會立刻回收否則要等并發(fā)標記周期結(jié)束。所以如果應用里有大量 1M 到幾 M 的緩存對象Region 設小了會產(chǎn)生一堆 HumongousGC 效率反而下降。我遇到過一個案例16G 堆沒設 Region 大小推算出來是 8M但業(yè)務里有大量 6M 左右的圖片緩存對象每個都觸發(fā) Humongous 分配GC 日志里全是Humongous字樣調(diào)大-XX:G1HeapRegionSize16m之后問題就沒了。G1 的停頓預測靠的是-XX:MaxGCPauseMillis默認 200ms。這里必須提醒一句這個值是目標不是承諾。G1 通過歷史回收數(shù)據(jù)估算哪些 Region 值得回收選出能在目標時間內(nèi)搞定的集合Collection Set。如果你把目標設成 10msG1 會幾乎收不動老年代最后堆積到并發(fā)模式失敗。經(jīng)驗值3 到 8G 堆設 100 到 200ms8G 以上設 200ms 就夠了別貪心。3. 參數(shù)怎么定從機器規(guī)格倒推 JVM 參數(shù)參數(shù)不是背下來的是算出來的。而且必須從機器規(guī)格和容器限制倒推不能拍腦袋設個大值。3.1 堆內(nèi)存、元空間、線程棧的賬要算清楚先說默認值很多人不知道默認堆是多少。JDK8 里-Xms默認是物理內(nèi)存的 1/64-Xmx默認是 1/4。真跑在生產(chǎn)上8G 的機器默認堆上限只有 2G而且初始堆小會經(jīng)歷一段不斷擴堆的過程每次都觸發(fā) Full GC。關于-Xms和-Xmx是否要一樣我的觀點很明確生產(chǎn)環(huán)境必須設成一樣。堆動態(tài)擴縮容本身是有代價的而且初始堆小會在啟動階段頻繁 GC。唯一例外是你確定這個應用是低頻的、內(nèi)存占用極小的邊緣服務那可以省點內(nèi)存。算賬的順序是這樣的以一臺 8G 內(nèi)存、8 核的機器為例第一步確定 JVM 總的可用內(nèi)存上限。這臺機器如果只跑這一個 Java 進程可以給到 6G留 2G 給操作系統(tǒng)和可能的外部依賴。如果是容器那容器 limit 才是硬邊界。第二步從這 6G 里扣掉堆外開銷元空間按類加載數(shù)量估。一般業(yè)務系統(tǒng) 200 到 300M 足夠用 Spring 全家桶加上動態(tài)代理的大項目給 512M 也是合理的。設-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m。直接內(nèi)存-XX:MaxDirectMemorySize256m用 Netty 或者大量 NIO 的項目要按實際連接數(shù)和緩沖區(qū)大小估算。線程棧-Xss默認 1M如果線程數(shù)峰值 500那就是 500M。線程數(shù)乘以棧大小是實打?qū)嵉拈_銷這就是為什么-Xss512k在這種場景下很有必要。代碼緩存-XX:ReservedCodeCacheSize默認 240MJDK8JIT 編譯的代碼放這里一般夠用。第三步剩下的才是堆。6G 減掉 512M 元空間、256M 直接內(nèi)存、512M 線程棧、240M 代碼緩存大約 4.5G那-Xmx4g是個穩(wěn)妥的取值。第四步劃分新生代。如果不用 G1新生代大小用-Xmn或-Xmn配合-XX:NewRatio控制。NewRatio是“老年代 : 新生代”的比值默認 2也就是新生代占整堆 1/3。對于短生命周期對象多的 Web 應用可以把比例調(diào)到 1:1 甚至新生代更大減少晉升壓力。注意-Xmn一旦顯式設置-XX:NewRatio就失效了而 G1 里-Xmn會被忽略需要用-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent默認 5% 和 60%來控制新生代占比。這幾個參數(shù)互相覆蓋的關系是調(diào)參時最容易翻車的地方。3.2 GC 日志參數(shù)在 JDK8 下的正確寫法生產(chǎn)上不開 GC 日志就是閉眼開車。JDK8 的日志參數(shù)和 JDK9 之后完全不同別混著寫。-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -XX:PrintHeapAtGC -XX:PrintTenuringDistribution -XX:PrintGCApplicationStoppedTime -Xloggc:/data/logs/gc-%t.log -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize50M逐個說作用PrintGCDetails輸出詳細日志包含各代容量變化PrintGCDateStamps加絕對時間戳排查問題必須要有PrintGCTimeStamps加相對 JVM 啟動的時間PrintHeapAtGC在每次 GC 前后打印堆布局量很大一般排查期開穩(wěn)定后關掉PrintTenuringDistribution打印對象年齡分布判斷提前晉升全靠它PrintGCApplicationStoppedTime打印 STW 總時長這個是判斷“接口偶爾卡頓”的直接證據(jù)。-Xloggc后面加%t會用啟動時間戳命名文件避免重啟覆蓋。配合輪轉(zhuǎn)參數(shù)10 個文件每個 50M一共 500M基本夠追一周的問題。JDK8 的日志文件名參數(shù)是-XX:GCLogFileSize注意 JDK9 之后這套全被-Xlog:gc*:filexxx:time,uptime,level,tags取代了網(wǎng)上搜到的參數(shù)經(jīng)?；熘鴣韺χ姹境?.3 三檔常見規(guī)格的參數(shù)模板下面這三套是我自己在項目里反復用過的可以直接作為起點再根據(jù) GC 日志微調(diào)。4C8G堆 4GWeb 服務延遲敏感G1-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize4m -XX:InitiatingHeapOccupancyPercent45 -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:MaxDirectMemorySize256m -Xss512k -XX:ParallelRefProcEnabled -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/dump/InitiatingHeapOccupancyPercent默認 45意思是老年代占用達到整堆 45% 就啟動并發(fā)標記周期。如果日志里經(jīng)常出現(xiàn)to-space exhausted或者Evacuation Failure說明這個值太高標記得太晚要往下調(diào)到 35 到 40。8C16G堆 8G數(shù)據(jù)同步吞吐優(yōu)先Parallel-Xms8g -Xmx8g -XX:UseParallelGC -XX:ParallelGCThreads8 -XX:MaxGCPauseMillis500 -XX:GCTimeRatio99 -Xmn3g -XX:SurvivorRatio8 -XX:MaxTenuringThreshold15 -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -Xss512kParallelGCThreads默認是按 CPU 核數(shù)算的約等于核數(shù)超過 8 核時按公式縮減顯式設置成 8 是為了避免容器里 CPU 配額識別不準導致線程數(shù)異常。SurvivorRatio8是 Eden 和一個 Survivor 的比例所以新生代里 Eden 占 80%。16C32G堆 16G核心交易低延遲G1-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis150 -XX:G1HeapRegionSize8m -XX:InitiatingHeapOccupancyPercent40 -XX:G1NewSizePercent10 -XX:G1MaxNewSizePercent40 -XX:ConcGCThreads4 -XX:ParallelGCThreads12 -XX:UnlockExperimentalVMOptions -XX:UseStringDeduplication -XX:MetaspaceSize512m -XX:MaxMetaspaceSize1g -Xss512kUseStringDeduplication是 G1 獨有的字符串去重能省下不少堆但會消耗額外的 CPU 和并發(fā)線程只在字符串重復度高的場景比如大量 JSON 解析才值得開。ConcGCThreads是并發(fā)標記線程數(shù)默認是ParallelGCThreads/4設太大反而搶業(yè)務 CPU。4. 工具鏈命令行四件套加 Arthas 的組合拳工具不在多在于知道什么時候用哪個。我的習慣是現(xiàn)場診斷先用命令行四件套需要動態(tài)追蹤再上 Arthas需要看趨勢圖才開 VisualVM。4.1 jps、jstat、jmap、jstack 的準確用法與坑jps用來找進程號最基礎的入口。jps -l # 輸出主類全名 jps -lv # 加上 JVM 參數(shù)確認啟動參數(shù)是不是你想要的jps -lv這個用法我強烈推薦排查“參數(shù)改了沒生效”這類問題時一眼就能看出實際生效的參數(shù)。jstat用來看 GC 實時數(shù)據(jù)每秒一次打十次jstat -gcutil 12345 1000 10輸出里的S0、S1、E、O、M是各區(qū)域使用百分比YGC/YGCT是新生代 GC 次數(shù)和總耗時FGC/FGCT是老年代 GC 次數(shù)和總耗時GCT是總耗時。判斷標準很簡單FGC 一直漲就是有問題正常穩(wěn)定的服務 FGC 應該長期不變FGCT / FGC得到的單次 Full GC 平均耗時超過 1 秒就需要處理。常用變體還有-gcnew只看新生代、-gcold只看老年代、-gccapacity看各區(qū)域容量。jmap用來做堆分析但有兩個坑必須先說jmap -heap 12345 # 查看堆配置和使用情況 jmap -histo 12345 | head -30 # 對象直方圖看誰占內(nèi)存 jmap -dump:formatb,file/tmp/heap.hprof 12345 # 導出堆快照第一個坑jmap -histo:live帶live會先觸發(fā)一次 Full GC 再統(tǒng)計線上執(zhí)行就是一次幾十秒的停頓除非萬不得已別在生產(chǎn)上用。用jmap -histo不帶 live 時統(tǒng)計的是所有對象包括待回收的會虛高但沒停頓風險先粗看足夠了。第二個坑jmap -dump在堆大的時候非常慢而且會 STW。8G 堆導出一次可能要一兩分鐘甚至更久業(yè)務直接受影響。正確的做法是配置-XX:HeapDumpOnOutOfMemoryError讓它自動在 OOM 時 dump或者從負載均衡摘掉節(jié)點再手動導。jstack用來看線程棧jstack -l 12345 /tmp/stack.log-l會額外打印鎖信息Locked ownable synchronizers排查死鎖必須加。想找死鎖也可以直接用jstack輸出后搜Found one Java-level deadlockJVM 會自動檢測并打印出來。排查 CPU 飆高的標準流程是先用top -Hp pid找出占 CPU 最高的線程 ID把它轉(zhuǎn)成十六進制再到 jstack 輸出里搜nid0x加那個十六進制值定位到具體代碼行。top -Hp 12345 printf %x\n 12346 # 假設高 CPU 線程是 12346得到 0x303a jstack 12345 | grep -A 30 nid0x303a4.2 VisualVM、JConsole、Arthas 的上手姿勢JConsole現(xiàn)在基本只作為兜底工具界面老、功能弱但勝在自帶。看內(nèi)存曲線、手動觸發(fā) GC 這些它能干看看線程數(shù)變化也夠。VisualVM是 JDK8 時代最順手的圖形化工具jvisualvm命令直接啟動。裝上 Visual GC 插件之后能實時看到 Eden、Survivor、老年代、元空間的曲線一眼就能看出內(nèi)存是不是鋸齒狀健康回收還是在緩慢爬升。判斷內(nèi)存泄漏最快的方式就是看這條曲線正常是鋸齒泄漏是一路向上、GC 之后回不到原位置。Arthas是后來居上的利器尤其是不能重啟的線上環(huán)境。核心命令我常用的就幾個dashboard # 總覽包含線程、內(nèi)存、GC 情況 thread -n 3 # 找 CPU 占用最高的 3 個線程 thread -b # 直接找阻塞其他線程的元兇 heapdump /tmp/a.hprof # 導出堆快照 trace com.xxx.Service method # 追蹤方法內(nèi)部調(diào)用耗時 watch com.xxx.Service method {params, returnObj} -x 2 # 觀察入?yún)⒑头祷刂祎hread -b這個命令救過我好幾次它能直接告訴你哪個線程持有鎖不放導致別的線程全卡住了比翻 jstack 快得多。但trace和watch在高頻方法上有明顯性能損耗用完一定要stop掉我見過有人忘了 stop第二天發(fā)現(xiàn)接口 P99 漲了三倍。dashboard里還有個細節(jié)值得看GC 那一欄會顯示各代的使用率曲線和 GC 次數(shù)。如果老年代使用率穩(wěn)定在 90% 以上且 FGC 緩慢增長就是內(nèi)存不夠或者有輕微泄漏的信號。4.3 一次 Full GC 頻繁的完整排查記錄說個真實場景。一個訂單查詢服務8G 堆用 Parallel上線兩周后監(jiān)控報 FGC 每小時從 0 漲到 20 多次每次約 1.5 秒高峰期接口超時。排查步驟第一步jstat -gcutil看趨勢。確認 YGC 正常每秒幾次每次 20ms 左右但老年代占用在 GC 后從 40% 一路爬到 95%然后 Full GC 打回 40%。GC 后老年代能回落到 40%說明沒有嚴重泄漏只是對象產(chǎn)生速度超過了回收能力。第二步加-XX:PrintTenuringDistribution重啟一個實例。日志里看到大量對象年齡是 1 和 2 就直接晉升了。結(jié)合年齡分布算一下Survivor 里的同齡對象總大小確實超過了 Survivor 一半動態(tài)年齡判定在起作用。第三步看新生代參數(shù)。原來是-Xmn2g -XX:SurvivorRatio8新生代 2GEden 1.6G每個 Survivor 只有 200M。而請求高峰期 Eden 每秒產(chǎn)生大約 400M 垃圾Survivor 根本裝不下存活的跨越對象。第四步調(diào)整。把-Xmn從 2G 提到 2.7GSurvivorRatio從 8 改成 6Survivor 變成約 337M同時把MaxTenuringThreshold顯式設為 15 防止被過早抬高。老年代從 5.3G 縮小到 4.6G。第五步觀察。改完后 FGC 從每小時 20 多次降到每天 1 到 2 次YGC 頻率略升但單次耗時沒變整體 P99 從 800ms 降到 120ms。這個過程里最關鍵的一步其實是第二步——加PrintTenuringDistribution看到年齡分布沒有這個信息前面所有的調(diào)整都是猜。5. OOM 與各類異常場景的排查套路OOM 不是一個錯誤是一類錯誤的統(tǒng)稱。不同后綴的 OOM 指向完全不同的根因處理方法也完全不同。把報錯后綴看懂排查能省一半時間。5.1 八種 OOM 的成因與定位方法報錯后綴觸發(fā)位置常見根因處理方向Java heap space堆大量對象未釋放、緩存無上限、查詢?nèi)砑虞d看 heap dump 找大對象檢查緩存淘汰策略GC overhead limit exceeded堆GC 花了 98% 以上時間卻只回收不到 2% 的空間基本等同于內(nèi)存泄漏先加堆續(xù)命再找泄漏點Metaspace元空間動態(tài)生成類太多CGLIB、反射、腳本引擎設 MaxMetaspaceSize檢查是否每次調(diào)用都創(chuàng)建新類加載器Direct buffer memory直接內(nèi)存NIO 緩沖區(qū)未釋放、Netty 池配置不當設 MaxDirectMemorySize檢查 ByteBuf 是否 releaseunable to create new native thread操作系統(tǒng)線程數(shù)超過系統(tǒng)限制、線程棧太大查 ulimit、線程數(shù)上限、是否存在線程泄漏Requested array size exceeds VM limit堆申請數(shù)組長度超過 int 上限附近通常代碼邏輯錯誤檢查數(shù)組長度計算Kill process or sacrifice child操作系統(tǒng)進程被 OOM Killer 殺掉容器內(nèi)存配額不足或堆外內(nèi)存超限Compressed class space元空間壓縮類指針空間耗盡調(diào)-XX:CompressedClassSpaceSize這里重點說兩個最容易被誤判的。GC overhead limit exceeded經(jīng)常被當成“內(nèi)存不夠”于是加堆結(jié)果只是把崩潰時間推遲。它的本質(zhì)是垃圾產(chǎn)生速率超過了回收速率加堆不能降低產(chǎn)生速率。正確姿勢是先用jmap -histo看對象分布如果是某個業(yè)務對象數(shù)量異常就去查對應的業(yè)務邏輯如果是HashMap$Node或者byte[]占了大頭八成是某個緩存容器沒有上限。unable to create new native thread的詭異之處在于堆內(nèi)存可能還很空但就是創(chuàng)建不了線程。原因通常是三種一是操作系統(tǒng)ulimit -u限制了單用戶進程數(shù)二是線程棧 1M 乘以線程數(shù)吃掉了大量內(nèi)存堆又開得大兩邊一起把物理內(nèi)存擠爆三是線程池創(chuàng)建了太多核心線程。我遇到過Executors.newCachedThreadPool()在突發(fā)流量下創(chuàng)建了上萬個線程的情況改成有界隊列的ThreadPoolExecutor之后就好了。順帶說一句線程池和 JVM 的關系線程池里每個線程都要占用一份?？臻g所以最大線程數(shù)乘以-Xss是必須從內(nèi)存預算里扣掉的。有人算過“最大線程數(shù) JVM 剩余可用線程”這個思路是對的但實際約束往往來自操作系統(tǒng)限制而不是堆內(nèi)存。合理的做法是把最大線程數(shù)控制在幾百這個量級配合有界隊列和合適的拒絕策略。5.2 CPU 飆高、GC 停頓、內(nèi)存泄漏怎么查CPU 飆高的三種典型模式第一種業(yè)務線程在跑密集計算或者死循環(huán)。用前面說的top -Hp加jstack定位到具體方法能看到線程一直停在同一個方法棧上。第二種GC 線程在瘋狂跑。表現(xiàn)是top里 GC 線程名字帶GC或者G1占用很高jstat里 YGC 或 FGC 頻率暴漲。這時候要處理的是內(nèi)存問題不是 CPU 問題。第三種頻繁的上下文切換。pidstat -w -p pid 1能看到cswch/s很高一般是鎖競爭嚴重。用jstack搜BLOCKED狀態(tài)的線程或者用 Arthas 的thread -b。GC 停頓的排查要區(qū)分是 Young GC 還是 Full GC 的停頓。判斷方式看PrintGCApplicationStoppedTime的輸出里面會列出每次 STW 的持續(xù)時間。如果 STW 時間遠大于 GC 日志里標注的 GC 時間那說明停頓另有原因——可能是在做偏向鎖撤銷、類加載、或者 JIT 反優(yōu)化。這個坑很深見過一次線上停頓 300ms 但 GC 日志顯示只停了 20ms 的情況最后查出來是 JVM 在做大量偏向鎖批量撤銷用-XX:-UseBiasedLocking關掉偏向鎖才解決。內(nèi)存泄漏的定位流程我固定這么走先用jstat -gcutil觀察老年代在 Full GC 后能否回落。能回落說明只是壓力大不能回落才是泄漏。然后用jmap -histo看對象排名對比兩次相隔幾分鐘的輸出看哪個類的實例數(shù)在持續(xù)增長。這一步不需要 dump 文件開銷小適合線上。鎖定可疑類之后再找個低峰期導 heap dump用 MAT 或者 JProfiler 打開看這個類的 GC Roots 引用鏈。MAT 的Dominator Tree視圖能直接告訴你誰占內(nèi)存最多Path to GC Roots能告訴你為什么這個對象回收不掉。常見的原因就那么幾個靜態(tài) Map 只增不減、ThreadLocal 用完沒 remove、監(jiān)聽器注冊后沒注銷、連接池/線程池未關閉。注意ThreadLocal 泄漏是重災區(qū)。線程池里的線程是復用的ThreadLocal 如果不在 finally 里 remove它引用的對象會一直活到線程銷毀而線程池的線程基本不會銷毀。5.3 開發(fā)環(huán)境與容器環(huán)境的調(diào)優(yōu)注意點IDEA 本身的 JVM 調(diào)優(yōu)也值得說兩句因為開發(fā)機的卡頓經(jīng)常被誤判成代碼問題。IDEA 的 JVM 參數(shù)在Help Edit Custom VM Options里改配置文件是idea.vmoptions。默認堆上限通常只有 750M 到 1G對于大型項目多模塊、大量索引根本不夠。-Xms1g -Xmx4g -XX:ReservedCodeCacheSize512m -XX:UseG1GC -XX:SoftRefLRUPolicyMSPerMB50 -XX:CICompilerCount2ReservedCodeCacheSize調(diào)大到 512M 是因為 IDEA 的索引和插件代碼量巨大默認 240M 經(jīng)常觸發(fā) JIT 代碼緩存滿表現(xiàn)就是 CPU 突然飆高、卡頓日志里能看到CodeCache is full的提示。SoftRefLRUPolicyMSPerMB50讓軟引用更快被回收減少內(nèi)存壓力。注意如果你開了大量插件導致 CPU 高先試試File Invalidate Caches重建索引比調(diào)參有用。容器環(huán)境的坑更隱蔽。JDK8 在 8u191 之前的版本JVM 根本識別不到容器的 cgroup 限制它會讀到宿主機的物理內(nèi)存然后按 1/4 算堆上限。容器 limit 是 2G宿主機 64G堆就開了 16G一啟動就被 OOM Killer 干掉。查版本java -version看構(gòu)建號。8u191 及以后默認開啟-XX:UseContainerSupport能正確讀取容器限制。更早的版本要么升級要么老老實實手動寫死-Xmx。即使在 8u191 之后容器里也建議顯式設堆。因為在容器里堆外內(nèi)存元空間、直接內(nèi)存、線程棧、JVM 自身都算在容器配額內(nèi)堆設成 limit 的 70% 到 75% 是比較穩(wěn)的比例剩下的留給堆外。見過太多“容器 limit 4G堆設 4G跑一會兒就被 Kill”的案例。6. GC 日志判讀與批量壓測調(diào)優(yōu)日志是唯一的客觀證據(jù)。很多人調(diào)優(yōu)調(diào)不好不是不懂參數(shù)是不會讀日志。6.1 三種回收器的日志格式對比Parallel 的 Young GC 日志2024-03-15T10:23:45.1230800: 25.456: [GC (Allocation Failure) [PSYoungGen: 65536K-10752K(76288K)] 65536K-11664K(251392K), 0.0234567 secs] [Times: user0.09 sys0.01, real0.02 secs]拆開看25.456是 JVM 啟動后的秒數(shù)Allocation Failure是觸發(fā)原因表示新生代沒空間分配了PSYoungGen: 65536K-10752K(76288K)表示新生代從 64M 降到 10.5M總?cè)萘?74.5M65536K-11664K(251392K)是整個堆從 64M 降到 11.4M堆總?cè)萘?245.5M0.0234567 secs是這次 GC 的耗時Times里的user是所有 GC 線程消耗的 CPU 時間總和real是實際墻鐘時間。user 遠大于 real 說明并行度好user 接近 real 說明基本是串行在跑。CMS 的日志會多出幾個階段2024-03-15T10:23:45.1230800: 25.456: [GC (CMS Initial Mark) [1 CMS-initial-mark: 131072K(174784K)] 145600K(251392K), 0.0012345 secs] 2024-03-15T10:23:45.2000800: 25.533: [CMS-concurrent-mark-start] 2024-03-15T10:23:45.8000800: 26.133: [CMS-concurrent-mark: 0.567/0.600 secs] 2024-03-15T10:23:45.8100800: 26.143: [CMS-concurrent-preclean-start] 2024-03-15T10:23:46.1000800: 26.433: [CMS-concurrent-preclean: 0.290/0.290 secs] 2024-03-15T10:23:46.1100800: 26.443: [GC (CMS Final Remark) [YG occupancy: 80000 K (131072 K)] 0.0850000 secs] 2024-03-15T10:23:46.2000800: 26.533: [CMS-concurrent-sweep-start] 2024-03-15T10:23:47.5000800: 27.833: [CMS-concurrent-sweep: 1.300/1.300 secs]看 CMS 日志只關心兩個有 STW 的階段CMS Initial Mark和CMS Final Remark。這兩個的耗時才是真正影響業(yè)務的。中間的concurrent-mark、preclean、sweep都是并發(fā)的耗時再長也只影響吞吐。如果 Final Remark 時間很長通常是新生代對象多導致重新標記工作量大可以調(diào)-XX:CMSScheduleRemarkEdenPenetration之類的高級參數(shù)但更簡單的辦法是減小新生代。G1 的日志信息量最大2024-03-15T10:23:45.1230800: 25.456: [GC pause (G1 Evacuation Pause) (young), 0.0234567 secs] [Parallel Time: 18.2 ms, GC Workers: 8] [GC Worker Start (ms): Min: 25456.1, Avg: 25456.3, Max: 25456.5, Diff: 0.4] [Ext Root Scanning (ms): Avg: 0.5, Max: 1.1, Sum: 4.0] [Update RS (ms): Avg: 0.8, Max: 1.5, Sum: 6.4] [Scan RS (ms): Avg: 0.3, Max: 0.9, Sum: 2.4] [Object Copy (ms): Avg: 12.1, Max: 14.3, Sum: 96.8] [Eden: 512.0M(512.0M)-0.0B(504.0M) Survivors: 4096.0K-8192.0K Heap: 1024.0M(2048.0M)-530.0M(2048.0M)]重點看Parallel Time和各個子階段的耗時。如果Ext Root Scanning很高說明 GC Roots比如大量線程、大量類太多了檢查線程數(shù)是不是失控如果Update RS或Scan RS高說明跨 Region 引用多Remembered Set 維護壓力大通常意味著老年代對象和新生代對象交互頻繁得考慮對象是不是過度分散了如果Object Copy占大頭那就是存活對象太多得減小新生代或者減少對象存活時間。6.2 關鍵指標與判讀閾值我整理了一張自己常用的閾值表長時間越界就要動手了。指標獲取方式健康范圍越界含義YGC 頻率jstat 里 YGC 變化率每秒小于 5 次新生代太小或?qū)ο蠓峙渌俾蔬^高YGC 單次耗時YGCT / YGC小于 50ms存活對象太多Survivor 不夠FGC 頻率jstat 里 FGC 變化率每天少于 2 次老年代不夠或有泄漏FGC 單次耗時FGCT / FGC小于 1s堆太大或回收器選擇不當GC 總時間占比GCT / 運行時長小于 5%吞吐量受損需要重新選型老年代 GC 后占用jstat 里 O穩(wěn)定不持續(xù)上升持續(xù)上升即有泄漏STW 總時長PrintGCApplicationStoppedTime單次小于 200ms影響接口 P99這張表里我覺得最該盯的是最后一個STW 總時長。因為它包含了 GC 之外的停頓原因是對用戶最直接的影響。只看 GC 耗時很容易漏掉偏向鎖撤銷、類加載、JIT 反優(yōu)化這些隱性停頓。6.3 壓測對比的落地做法調(diào)優(yōu)最后一步必須驗證而且不能只在一個參數(shù)下跑。我一般的做法是準備一組參數(shù)組合在同一臺機器、同一份壓測流量下逐個跑收集 GC 日志后用腳本對比。先寫個提取腳本把日志里的關鍵指標算出來#!/bin/bash LOG$1 echo 文件: $LOG echo YGC 次數(shù): $(grep -c GC (Allocation Failure) $LOG) echo Full GC 次數(shù): $(grep -c Full GC $LOG) echo 平均 STW: $(grep Total time for which application threads were stopped $LOG | awk {s$10; n} END {printf %.2f ms\n, s/n*1000}) echo 最長 STW: $(grep Total time for which application threads were stopped $LOG | awk {if($10m) m$10} END {printf %.2f ms\n, m*1000})然后準備三到四組參數(shù)比如新生代 2G、2.7G、3.2G 三檔每組用同樣的壓測流量跑 30 分鐘收集日志之后橫向?qū)Ρ取簻y工具用什么不重要關鍵是流量模型要貼近真實——尤其是對象創(chuàng)建速率和對象存活時間這兩個特征必須和線上一致否則調(diào)出來的參數(shù)沒有參考價值。我自己踩過的一個坑是在壓測環(huán)境用簡單的接口壓對象創(chuàng)建快、存活短調(diào)出來的參數(shù)是新生代越大越好但線上業(yè)務的對象存活時間明顯長兩個環(huán)境的最優(yōu)參數(shù)完全不同。后來我改成從線上拉一份真實的請求采樣做流量回放參數(shù)才有參考意義。還有個實用技巧參數(shù)不要一次改多個。有人喜歡一次改五六項跑出來效果好也不知道是哪項起的作用效果差更不知道是哪項搞壞了。一次改一到兩項觀察至少半小時記錄下變化這才是可積累的調(diào)優(yōu)經(jīng)驗。最后再分享一個我自己的做法把每次調(diào)優(yōu)的參數(shù)、機器規(guī)格、前后 GC 指標記錄在一個表格里。跑的項目多了之后這張表就成了自己的經(jīng)驗庫新項目上手時直接找規(guī)格相近的那一行做起點比從零開始試快得多。尤其是內(nèi)存規(guī)格在 4G 到 16G 這個區(qū)間很多業(yè)務形態(tài)的參數(shù)其實高度相似復用率相當高。