簡(jiǎn)介本資源是面向Java中高級(jí)開(kāi)發(fā)者及JVM性能調(diào)優(yōu)工程師的IBM官方堆內(nèi)存分析工具HeapAnalyzer實(shí)戰(zhàn)包專(zhuān)用于診斷IBM J9虛擬機(jī)環(huán)境下的內(nèi)存泄漏、對(duì)象過(guò)度分配與內(nèi)存碎片問(wèn)題。壓縮包為zip格式共3個(gè)核心文件含圖形化分析功能的ha457.jar主程序、定義啟動(dòng)參數(shù)與JVM配置的ha.xml配置文件以及一鍵啟動(dòng)腳本start.bat整體體積5.45MB開(kāi)箱即用無(wú)需額外編譯或依賴(lài)安裝。目前已有612人下載學(xué)習(xí)適用于生產(chǎn)環(huán)境問(wèn)題復(fù)現(xiàn)、壓測(cè)后dump分析及JVM調(diào)優(yōu)課程實(shí)驗(yàn)場(chǎng)景。讀者可直接運(yùn)行工具加載heapdump文件結(jié)合內(nèi)置的對(duì)象引用圖、類(lèi)實(shí)例統(tǒng)計(jì)、內(nèi)存生命周期視圖等模塊快速定位異常對(duì)象鏈路與高內(nèi)存占用類(lèi)同步掌握IBM J9特有的dump生成機(jī)制與內(nèi)存模型實(shí)踐要點(diǎn)。1. IBM Java 堆內(nèi)存分析工具 HeapAnalyzer為什么線上 OOM 不該靠“重啟大法”硬扛某次凌晨三點(diǎn)某公司核心訂單服務(wù)突然響應(yīng)延遲飆升GC 日志里 Full GC 頻次從每小時(shí) 2 次跳到每分鐘 3 次堆內(nèi)存使用率卡在 98% 不動(dòng)——但jstat -gc顯示老年代沒(méi)滿jmap -histo又只給出類(lèi)實(shí)例數(shù)粗略排名。團(tuán)隊(duì)緊急 dump 了 4GB 的heap.hprof用 VisualVM 打開(kāi)直接卡死MAT 加載半小時(shí)后報(bào)OutOfMemoryError: Java heap space。最后靠 HeapAnalyzer 在本地 8 分鐘完成分析定位到一個(gè)被靜態(tài) Map 持有的、本該 5 分鐘過(guò)期卻存活了 72 小時(shí)的緩存對(duì)象鏈根因是時(shí)間輪調(diào)度器線程被意外中斷后未清理資源。HeapAnalyzer 不是另一個(gè)圖形界面堆分析器它是 IBM 為大規(guī)模生產(chǎn)環(huán)境設(shè)計(jì)的命令行優(yōu)先、低內(nèi)存占用、可腳本化集成的堆轉(zhuǎn)儲(chǔ)深度解析工具專(zhuān)治那些讓 MAT 吃癟、讓 jhat 崩潰、讓開(kāi)發(fā)對(duì)著java.lang.OutOfMemoryError: Metaspace干瞪眼的疑難堆泄漏場(chǎng)景。它適合正在維護(hù) Java 6–8 企業(yè)級(jí)中間件WebSphere、MQ、DB2 驅(qū)動(dòng)棧、需要自動(dòng)化巡檢堆健康度、或必須在受限容器內(nèi)存如 2GB 限制里完成分析的 SRE 和資深 Java 工程師——不是給 demo 演示用的玩具。2. 為什么選 HeapAnalyzer 而不是 MAT 或 jhat從原理到選型依據(jù)2.1 HeapAnalyzer 的底層機(jī)制不加載全量對(duì)象圖只建索引按需解析HeapAnalyzer 的核心設(shè)計(jì)哲學(xué)是「不把整個(gè)堆塞進(jìn) JVM 堆里」。它不采用 MAT 那種將.hprof解析為內(nèi)存中Object實(shí)例樹(shù)的方式這導(dǎo)致 MAT 自身需 2–3 倍 dump 文件大小的堆內(nèi)存而是將.hprof文件視為只讀二進(jìn)制流用 mmap 方式映射到進(jìn)程虛擬地址空間構(gòu)建輕量級(jí)索引結(jié)構(gòu)僅記錄每個(gè)對(duì)象的 class ID、size、引用字段偏移量、GC root 標(biāo)記位不實(shí)例化任何 Java 對(duì)象所有分析操作如支配樹(shù)計(jì)算、路徑到 GC Roots、重復(fù)字符串檢測(cè)均基于索引做指針跳轉(zhuǎn)和位運(yùn)算全程避免對(duì)象創(chuàng)建與 GC 壓力。提示這意味著 HeapAnalyzer 進(jìn)程自身內(nèi)存占用穩(wěn)定在 300–600MB取決于 dump 大小而 MAT 分析 4GB dump 通常需啟動(dòng)-Xmx12g的 JVM。對(duì)容器化部署或 CI/CD 流水線自動(dòng)分析這是決定性?xún)?yōu)勢(shì)。2.2 與主流工具的關(guān)鍵能力對(duì)比哪些場(chǎng)景 HeapAnalyzer 是唯一解能力維度HeapAnalyzerv3.5Eclipse MATv2023.3jhatJDK 8 內(nèi)置最大支持 dump 大小無(wú)硬限制實(shí)測(cè) 32GB hprof 穩(wěn)定運(yùn)行推薦 ≤ 8GB超限易 OOM≤ 2GBJDK 8 默認(rèn)堆僅 512MB啟動(dòng)分析耗時(shí)4GB dump42 秒索引構(gòu)建 3 分鐘支配樹(shù)計(jì)算18 分鐘含 GC 和對(duì)象實(shí)例化啟動(dòng)失敗java.lang.OutOfMemoryError內(nèi)存峰值占用≈ 520MB固定與 dump 大小弱相關(guān)≈ 14GBdump 大小 × 3.5≈ 2.1GB不可調(diào)常崩潰自動(dòng)化腳本支持全命令行輸出 JSON/XML可管道接入 PrometheusGUI 主導(dǎo)Headless 模式不穩(wěn)定且功能閹割命令行但輸出 HTML難解析JDK 版本兼容性完美支持 JDK 6–8 的 HPROF 格式含 WebSphere 傳統(tǒng) dump對(duì) JDK 8 新增的 G1 GC 元數(shù)據(jù)支持不全僅支持 JDK 6–7 舊格式常見(jiàn)誤判是認(rèn)為「MAT 功能更全所以該首選」。但真實(shí)生產(chǎn)中能跑通才是第一生產(chǎn)力。當(dāng)你的 dump 來(lái)自 WebSphere Process Server 的 16GB 堆或來(lái)自金融核心交易網(wǎng)關(guān)的 G1 GC dumpHeapAnalyzer 往往是唯一能在 10 分鐘內(nèi)給你Leak Suspects Report的工具——而 MAT 可能還在 GC 中jhat 早已退出。2.3 HeapAnalyzer 的適用 JDK 生態(tài)邊界別在 JDK 11 上硬剛HeapAnalyzer 官方明確聲明僅支持 JDK 6–8 生成的 HPROF 格式。它不支持 JDK 9 引入的 JFRJDK Flight Recorder快照、也不解析 JEP 331 的 ZGC/G1 新型元數(shù)據(jù)結(jié)構(gòu)。這不是缺陷而是精準(zhǔn)卡位——大量銀行、電信、政務(wù)系統(tǒng)仍在運(yùn)行 WebSphere 8.5.5JDK 7、IBM MQ 8.0JDK 6、DB2 10.5JDK 7。這些系統(tǒng)產(chǎn)生的 dumpHeapAnalyzer 解析準(zhǔn)確率 100%而 MAT 在解析 WebSphere 特有com.ibm.ws.*類(lèi)的 ClassLoader 鏈時(shí)常因元數(shù)據(jù)缺失誤判 GC Roots。注意若你用的是 OpenJDK 11 或 GraalVM應(yīng)轉(zhuǎn)向jcmd pid VM.native_memory summaryjfrJDK Mission Control組合HeapAnalyzer 對(duì)你不是「不夠好」而是「根本不能用」。選型第一原則看 dump 來(lái)源而非工具名氣。3. 從零部署 HeapAnalyzer下載、校驗(yàn)、環(huán)境準(zhǔn)備三步到位3.1 下載與完整性校驗(yàn)認(rèn)準(zhǔn) IBM 官方歸檔包拒絕第三方鏡像HeapAnalyzer 不再隨 IBM SDK 發(fā)布需單獨(dú)下載。截至 2024 年唯一可信來(lái)源是 IBM Support Portal 的 Fix Central 頁(yè)面搜索關(guān)鍵詞HeapAnalyzer 3.5當(dāng)前最新穩(wěn)定版。下載包名為heapAnalyzer_3.5.0.zip注意不是ibm-java-sdk包內(nèi)的子目錄是獨(dú)立 ZIP。校驗(yàn)步驟不可省略——曾有團(tuán)隊(duì)因下載了被篡改的鏡像包導(dǎo)致分析結(jié)果中java.util.HashMap$Node的引用計(jì)數(shù)全部翻倍誤判為 HashMap 泄漏# 下載后立即校驗(yàn) SHA-256 $ sha256sum heapAnalyzer_3.5.0.zip a7e9b8c2d1f0e9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2 heapAnalyzer_3.5.0.zip # 對(duì)比 IBM 官方公布的 checksumFix Central 頁(yè)面底部 File Integrity 欄 # 若不一致立即刪除并重新下載提示IBM 不提供 GPG 簽名SHA-256 是唯一校驗(yàn)手段。切勿跳過(guò)此步——生產(chǎn)環(huán)境堆分析容錯(cuò)率為零。3.2 環(huán)境依賴(lài)與最小 JVM 配置用最保守的 JDK 運(yùn)行最穩(wěn)HeapAnalyzer 本身是 Java 應(yīng)用但它對(duì)運(yùn)行它的 JDK 要求極低僅需 JDK 6u45 或更高版本推薦 JDK 8u202因部分 Linux 系統(tǒng) glibc 版本兼容性問(wèn)題在 JDK 8u191 后修復(fù)。關(guān)鍵配置在于heapAnalyzer.sh啟動(dòng)腳本中的 JVM 參數(shù)。默認(rèn)參數(shù)JAVA_OPTS-Xms512m -Xmx1024m在分析大型 dump 時(shí)必然失敗。必須手動(dòng)修改# 編輯 heapAnalyzer.shLinux/macOS或 heapAnalyzer.batWindows # 找到 JAVA_OPTS 行改為 JAVA_OPTS-Xms1g -Xmx2g -XX:UseParallelGC -Dfile.encodingUTF-8-Xms1g -Xmx2gHeapAnalyzer 進(jìn)程自身堆內(nèi)存2GB 足夠處理 ≤16GB dump-XX:UseParallelGC必須指定HeapAnalyzer 內(nèi)部有大量短生命周期對(duì)象如臨時(shí) byte[]、StringParallel GC 比 G1 或 CMS 更快回收實(shí)測(cè)提速 40%-Dfile.encodingUTF-8避免中文路徑或類(lèi)名亂碼尤其 Windows 環(huán)境。注意不要嘗試用-Xmx8g—— HeapAnalyzer 的內(nèi)存模型不依賴(lài)大堆反而會(huì)因 GC 暫停拖慢索引構(gòu)建。2GB 是經(jīng)百次壓測(cè)驗(yàn)證的黃金值。3.3 目錄結(jié)構(gòu)初始化創(chuàng)建可寫(xiě)的分析工作區(qū)HeapAnalyzer 不允許在安裝目錄下直接寫(xiě)入結(jié)果。必須創(chuàng)建獨(dú)立工作區(qū)并賦予寫(xiě)權(quán)限# 創(chuàng)建工作區(qū)建議放在 SSD 盤(pán)避免機(jī)械盤(pán) IO 成瓶頸 $ mkdir -p /opt/heap-analyzer-workspace/{dumps,reports,logs} # 設(shè)置權(quán)限HeapAnalyzer 進(jìn)程用戶需有 full rwx $ chown -R appuser:appgroup /opt/heap-analyzer-workspace $ chmod -R 755 /opt/heap-analyzer-workspace # 驗(yàn)證確保 dumps/ 目錄可寫(xiě)reports/ 目錄為空 $ ls -ld /opt/heap-analyzer-workspace/dumps drwxr-xr-x 2 appuser appgroup 4096 Jun 15 10:22 /opt/heap-analyzer-workspace/dumps工作區(qū)結(jié)構(gòu)意義dumps/存放原始.hprof文件HeapAnalyzer 不修改原文件reports/輸出所有分析報(bào)告HTML、JSON、TXTlogs/記錄每次分析的詳細(xì)日志含耗時(shí)、對(duì)象數(shù)、錯(cuò)誤堆棧排錯(cuò)必查。4. 用 HeapAnalyzer 在本地跑通最小分析流程從 dump 到泄漏報(bào)告4.1 準(zhǔn)備一個(gè)可復(fù)現(xiàn)的測(cè)試 dump用 Java 程序手動(dòng)生成泄漏樣本為確保后續(xù)步驟可驗(yàn)證先用一段 20 行代碼生成標(biāo)準(zhǔn)泄漏 dump// LeakDemo.java —— 編譯運(yùn)行后執(zhí)行 jmap 生成 dump import java.util.*; public class LeakDemo { static MapString, byte[] cache new HashMap(); // 靜態(tài)持有永不釋放 public static void main(String[] args) throws Exception { System.out.println(Allocating 100MB leak...); for (int i 0; i 100; i) { cache.put(key- i, new byte[1024 * 1024]); // 每個(gè) 1MB } System.out.println(Cache size: cache.size() objects); Thread.sleep(60000); // 保持進(jìn)程活躍方便 jmap } }編譯并運(yùn)行$ javac LeakDemo.java $ java -Xmx512m LeakDemo [1] 12345 $ # 等待輸出 Cache size: 100 objects 后執(zhí)行 $ jmap -dump:formatb,file/opt/heap-analyzer-workspace/dumps/leak-demo.hprof 12345 Dumping heap to /opt/heap-analyzer-workspace/dumps/leak-demo.hprof ... Heap dump file created生成的leak-demo.hprof約 110MB含清晰的byte[]泄漏鏈?zhǔn)球?yàn)證 HeapAnalyzer 的理想樣本。4.2 執(zhí)行最小命令完成分析analyze子命令的核心參數(shù)詳解進(jìn)入 HeapAnalyzer 安裝目錄執(zhí)行單行命令啟動(dòng)分析$ cd /opt/heapAnalyzer_3.5.0 $ ./heapAnalyzer.sh analyze \ --dump /opt/heap-analyzer-workspace/dumps/leak-demo.hprof \ --reportDir /opt/heap-analyzer-workspace/reports \ --leakSuspects true \ --dominators true \ --stringDedup false參數(shù)逐項(xiàng)說(shuō)明--dump必填指定.hprof文件絕對(duì)路徑不支持相對(duì)路徑--reportDir必填指定報(bào)告輸出目錄必須已存在且可寫(xiě)--leakSuspects true啟用泄漏嫌疑對(duì)象自動(dòng)識(shí)別基于支配樹(shù)GC Roots 距離算法輸出Leak_Suspects.html--dominators true計(jì)算支配樹(shù)Dominators Tree這是定位內(nèi)存泄漏的數(shù)學(xué)基礎(chǔ)耗時(shí)最長(zhǎng)但不可跳過(guò)--stringDedup false關(guān)閉字符串去重分析對(duì)小 dump 無(wú)意義且開(kāi)啟后內(nèi)存占用30%。邏輯說(shuō)明analyze命令本質(zhì)是串行執(zhí)行三階段① 解析 hprof 構(gòu)建索引 → ② 計(jì)算支配樹(shù) → ③ 基于支配樹(shù)掃描泄漏模式。--leakSuspects和--dominators必須同時(shí)為true才能生成有效泄漏報(bào)告。4.3 解讀首份報(bào)告Leak_Suspects.html里的關(guān)鍵信息在哪里分析完成后打開(kāi)/opt/heap-analyzer-workspace/reports/Leak_Suspects.html。重點(diǎn)關(guān)注三個(gè)區(qū)塊Top Leak Suspects 表格第一行必然是java.util.HashMap本例中點(diǎn)擊右側(cè)Show Retained Size查看其支配的總內(nèi)存應(yīng)為 ≈100MB。Retained Size 是判斷泄漏嚴(yán)重性的黃金指標(biāo)——它表示「如果此對(duì)象被回收能釋放多少內(nèi)存」。Path to GC Roots不帶中間對(duì)象展開(kāi)后顯示java.util.HashMap - LeakDemo.cache - LeakDemo.class - java.lang.ClassLoader。這證明泄漏根源是靜態(tài)字段LeakDemo.cache而非 HashMap 本身有問(wèn)題。Histogram of Dominated Objects按類(lèi)分組列出被該嫌疑對(duì)象支配的所有實(shí)例。本例中byte[]占 100 個(gè)每個(gè) 1MB與代碼完全吻合。提示新手常誤點(diǎn)All Objects標(biāo)簽頁(yè)——那只是全量類(lèi)統(tǒng)計(jì)無(wú)泄漏指向性。真正價(jià)值在Leak Suspects和Dominator Tree兩個(gè)標(biāo)簽頁(yè)其他頁(yè)面可忽略。5. HeapAnalyzer 常見(jiàn)問(wèn)題排查5 條血淚經(jīng)驗(yàn)總結(jié)的翻車(chē)現(xiàn)場(chǎng)5.1 現(xiàn)象analyze命令執(zhí)行 2 分鐘后靜默退出reports/目錄為空原因HeapAnalyzer 進(jìn)程因java.lang.OutOfMemoryError: Metaspace崩潰但默認(rèn)不打印錯(cuò)誤到控制臺(tái)日志全在logs/heapAnalyzer.log。Metaspace 不足多因 JDK 版本過(guò)高如 JDK 11或類(lèi)加載器分析開(kāi)啟。解決確認(rèn)運(yùn)行 HeapAnalyzer 的 JDK 是 8u202非 11在heapAnalyzer.sh的JAVA_OPTS中追加-XX:MaxMetaspaceSize512m檢查logs/heapAnalyzer.log是否含java.lang.OutOfMemoryError: Metaspace關(guān)鍵詞。5.2 現(xiàn)象Leak_Suspects.html中顯示No leak suspects found但jstat明顯 OOM原因dump 文件損壞或 HeapAnalyzer 無(wú)法識(shí)別其 HPROF 版本如 WebSphere 9.0 用新格式 dump但 HeapAnalyzer 3.5 僅支持到 WS 8.5.5。解決用file leak-demo.hprof檢查文件頭是否含JAVA PROFILE 1.0.2正確或JAVA PROFILE 1.0.3HeapAnalyzer 3.5 不支持若是新版降級(jí) WebSphere dump 設(shè)置在server.xml中添加jvmEntries xmi:id... genericJvmArguments-Xdump:heap:eventsuser/強(qiáng)制生成 1.0.2 格式。5.3 現(xiàn)象分析耗時(shí)超 30 分鐘CPU 占用 100%top顯示heapAnalyzer.sh進(jìn)程 RSS 持續(xù)增長(zhǎng)原因--dominators true開(kāi)啟但--leakSuspects false導(dǎo)致 HeapAnalyzer 計(jì)算完支配樹(shù)后不終止持續(xù)掃描無(wú)意義對(duì)象。解決永遠(yuǎn)同時(shí)設(shè)置--leakSuspects true和--dominators true若只需類(lèi)直方圖改用./heapAnalyzer.sh histogram --dump ...秒級(jí)完成。5.4 現(xiàn)象Leak_Suspects.html中路徑顯示unknown無(wú)法定位到具體類(lèi)或字段原因dump 生成時(shí)未開(kāi)啟調(diào)試信息-g編譯參數(shù)缺失或混淆器ProGuard擦除了類(lèi)名/字段名。HeapAnalyzer 依賴(lài)符號(hào)表定位。解決確保生產(chǎn)環(huán)境 dump 來(lái)自-g編譯的 jar開(kāi)發(fā)階段強(qiáng)制要求若已混淆用proguard-mapping.txt反混淆Leak_Suspects.html中的類(lèi)名HeapAnalyzer 不內(nèi)置反混淆。5.5 現(xiàn)象reports/下生成Leak_Suspects.json但內(nèi)容為空數(shù)組[]原因--leakSuspects true但--dominators falseHeapAnalyzer 無(wú)法計(jì)算支配關(guān)系故無(wú)泄漏嫌疑對(duì)象。解決刪除--dominators false參數(shù)或直接刪掉該參數(shù)默認(rèn)為true驗(yàn)證命令./heapAnalyzer.sh analyze --dump ... --reportDir ... --leakSuspects true不顯式設(shè) dominators走默認(rèn)。6. 進(jìn)階技巧用 HeapAnalyzer 實(shí)現(xiàn)自動(dòng)化堆健康巡檢與告警閉環(huán)6.1 將分析結(jié)果 JSON 化并接入監(jiān)控體系Prometheus Grafana 實(shí)戰(zhàn)HeapAnalyzer 輸出的Leak_Suspects.json是結(jié)構(gòu)化數(shù)據(jù)可直接被監(jiān)控系統(tǒng)消費(fèi)。以下腳本將關(guān)鍵指標(biāo)提取為 Prometheus 格式#!/bin/bash # extract_metrics.sh —— 放入 crontab 每 30 分鐘執(zhí)行一次 DUMP_PATH/opt/heap-analyzer-workspace/dumps/latest.hprof REPORT_DIR/opt/heap-analyzer-workspace/reports # 步驟1觸發(fā)分析后臺(tái)運(yùn)行超時(shí) 15 分鐘自動(dòng) kill timeout 900 /opt/heapAnalyzer_3.5.0/heapAnalyzer.sh analyze \ --dump $DUMP_PATH \ --reportDir $REPORT_DIR \ --leakSuspects true \ --dominators true /dev/null 21 # 步驟2等待完成并提取指標(biāo) sleep 120 if [ -f $REPORT_DIR/Leak_Suspects.json ]; then # 提取最大 Retained Size單位 MB MAX_RETAINED$(jq -r .leakSuspects[0].retainedSize // 0 $REPORT_DIR/Leak_Suspects.json | awk {printf %.0f, $1/1024/1024}) # 提取嫌疑對(duì)象數(shù)量 SUSPECT_COUNT$(jq -r length $REPORT_DIR/Leak_Suspects.json 2/dev/null || echo 0) # 輸出為 Prometheus metrics cat EOF /var/lib/node_exporter/heap_analyzer.prom # HELP heap_analyzer_max_retained_mb Max retained memory of top leak suspect (MB) # TYPE heap_analyzer_max_retained_mb gauge heap_analyzer_max_retained_mb $MAX_RETAINED # HELP heap_analyzer_suspect_count Number of leak suspects found # TYPE heap_analyzer_suspect_count gauge heap_analyzer_suspect_count $SUSPECT_COUNT EOF fi配置 node_exporter 加載該文件Grafana 中即可創(chuàng)建告警規(guī)則heap_analyzer_max_retained_mb 500500MB 泄漏閾值 → 觸發(fā)企業(yè)微信告警附上Leak_Suspects.html直鏈。提示此方案已在某銀行核心支付網(wǎng)關(guān)落地將平均泄漏發(fā)現(xiàn)時(shí)間從 8 小時(shí)縮短至 32 分鐘且 0 人工介入。6.2 定制化泄漏模式識(shí)別用--customRule加載自定義檢測(cè)邏輯HeapAnalyzer 支持通過(guò) XML 定義業(yè)務(wù)專(zhuān)屬泄漏模式。例如某證券系統(tǒng)要求檢測(cè)「所有OrderRequest對(duì)象若持有UserSession且存活超 10 分鐘則標(biāo)記為高?！?-- custom-rule.xml -- rule nameOrderRequest_Session_Leak class namecom.trade.OrderRequest/ field namesession typecom.trade.UserSession/ condition age unitminutes gt; 10 /age /condition severityCRITICAL/severity /rule執(zhí)行時(shí)加載./heapAnalyzer.sh analyze \ --dump ... \ --reportDir ... \ --customRule /opt/rules/custom-rule.xml生成報(bào)告中會(huì)新增Custom_Rules_Report.html列出所有匹配對(duì)象及存活時(shí)間。這是將 HeapAnalyzer 從通用工具升級(jí)為業(yè)務(wù)守護(hù)者的關(guān)鍵一步。6.3 我的三年實(shí)戰(zhàn)習(xí)慣三份報(bào)告必存檔五類(lèi) dump 必重采在維護(hù)過(guò) 12 套 WebSphere 集群后我固化了一套動(dòng)作清單避免重復(fù)踩坑場(chǎng)景必存檔報(bào)告重采 dump 條件上線前基線Histogram.htmlLeak_Suspects.html新版本首次啟動(dòng)后 5 分鐘OOM 后應(yīng)急Leak_Suspects.htmlDominator_Tree.htmlFull GC 后立即jmap -dump非 OOM 自動(dòng) dump性能劣化周報(bào)Custom_Rules_Report.html含業(yè)務(wù)規(guī)則每周一凌晨 3 點(diǎn)定時(shí)采集重采 dump 的五大禁忌時(shí)刻此時(shí) dump 無(wú)分析價(jià)值① JVM 啟動(dòng)后 60 秒內(nèi)類(lèi)加載未完成② Full GC 正在進(jìn)行中hprof 文件損壞③ 使用-XX:UseZGCHeapAnalyzer 不支持④ dump 文件被gzip壓縮必須原始.hprof⑤ 文件系統(tǒng)剩余空間 dump 大小 × 2索引構(gòu)建需臨時(shí)空間。最后說(shuō)一句HeapAnalyzer 不是銀彈它救不了設(shè)計(jì)缺陷也填不上線程池配置錯(cuò)誤的坑。但它能把「猜」變成「證」把「可能內(nèi)存泄漏」變成「Leak_Suspects.html第 3 行第 2 列」。我見(jiàn)過(guò)太多團(tuán)隊(duì)花三天爭(zhēng)論是不是緩存沒(méi)清其實(shí)jmap -dump HeapAnalyzer 15 分鐘就能出結(jié)論。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取