阿里Java面试被问：如何分析Full GC的原因？jmap -histo和jmap -dump区别？

一、Full GC频繁的定位流程

1. 快速诊断流程图

flowchart TD A[发现Full GC频繁] --> B[立即收集现场证据] B --> C{分析GC日志} C --> D[确定GC类型] D --> E[系统级Full GC<br>System.gc()调用] D --> F[并发失败Full GC<br>CMS回收失败] D --> G[晋升失败Full GC<br>老年代空间不足] D --> H[元空间Full GC<br>Metaspace不足] E --> I[排查代码中System.gc<br>或RMI等调用] F --> J[检查CMS并发标记<br>期间老年代增长] G --> K[检查新生代大小<br>和晋升阈值] H --> L[检查Metaspace大小<br>和类加载] I & J & K & L --> M[实施对应优化方案] M --> N[验证优化效果]

2. 现场证据收集（黄金5分钟）

命令集（按顺序执行）

bash

# 1. 保存当前GC日志（如果开启） jstat -gcutil <pid> 1000 10 > gc_status.log # 2. 立即dump堆内存（根据堆大小决定） jmap -dump:live,format=b,file=heap_dump.hprof <pid> # 3. 查看线程状态 jstack <pid> > thread_dump.log # 4. 查看JVM参数 jinfo -flags <pid> > jvm_flags.log # 5. 监控系统资源 top -H -p <pid> # 线程CPU vmstat 1 10 # 系统内存和IO iostat -x 1 10 # 磁盘IO

关键指标解读

bash

# jstat输出示例 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 96.88 18.24 85.91 94.12 91.72 1130 32.234 24 8.123 40.357 关键字段： - O (Old): 老年代使用率 > 80% 危险 - YGC/YGCT: Young GC次数/总耗时 - FGC/FGCT: Full GC次数/总耗时 - FGCT/YGCT > 0.3 说明Full GC消耗过多时间

二、CMS并发失败原因深度分析

CMS工作流程回顾

text

初始标记(STW) → 并发标记 → 重新标记(STW) → 并发清理 ↓ ↓ 时间很短 时间较长，但STW

并发失败（Concurrent Mode Failure）的根本原因

核心问题：在并发标记和清理期间，老年代剩余空间不足以容纳新生代晋升的对象

数学公式解释

text

触发条件：剩余老年代空间 < 预期晋升对象大小 + 浮动垃圾 其中： 1. 预期晋升对象大小 ≈ 历次Young GC晋升对象的平均值 × 安全系数 2. 浮动垃圾 = 并发标记期间新产生的垃圾（无法在此次回收）

具体原因排查

原因1：老年代空间过小

java

// 错误配置示例 -Xmx4g -Xms4g -XX:NewRatio=2 // 新生代1.33G，老年代2.67G -XX:SurvivorRatio=8 // Eden:Survivor = 8:1:1 // 计算：每次Young GC后可能晋升的对象 Eden区大小 = 1.33G × 0.8 ≈ 1.06G 假设存活率10% → 晋升约106M 如果存在大对象，可能直接进入老年代

原因2：晋升阈值不合理

bash

# 关键参数 -XX:MaxTenuringThreshold=15 # 最大晋升年龄，默认15 -XX:TargetSurvivorRatio=50 # Survivor区目标使用率，默认50% # 查看晋升年龄分布 jmap -histo:live <pid> | head -20

原因3：大对象直接分配

java

// 常见大对象场景 byte[] largeBuffer = new byte[10 * 1024 * 1024]; // 10MB数组 List<Data> hugeList = new ArrayList<>(1000000); // 大集合 // CMS下大对象直接进入老年代 // 参数：-XX:PretenureSizeThreshold=3M (默认0，Serial/ParNew有效) // CMS没有此参数控制，大对象直接进入老年代

原因4：浮动垃圾过多

• 并发标记期间，应用线程仍在运行

• 新产生的垃圾无法在此次回收

• 如果应用产生大量新对象，浮动垃圾占用大量空间

原因5：内存碎片化

bash

# 查看内存碎片情况（需要开启特定参数） -XX:+PrintFLSStatistics=1 # 打印Free List统计 # 或者通过GC日志分析 [ParNew: 1398144K->1398144K(1398144K), 0.0000370 secs] [CMS: 2414195K->2414195K(4194304K), 2.3983480 secs] # 清理前后老年代使用率不变 → 严重碎片化

篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafc

需要全套面试笔记及答案
【点击此处即可/免费获取】​​​

三、CMS并发失败解决方案

方案1：调整空间比例（最直接）

bash

# 增加老年代空间 -Xmx8g -Xms8g -XX:NewRatio=3 # 老年代:新生代=3:1，老年代6G -XX:SurvivorRatio=6 # Eden:Survivor = 6:1:1 # 或显式设置新生代大小 -Xmn2g # 新生代固定2G，老年代6G

方案2：优化晋升策略

bash

# 降低晋升阈值，让对象在年轻代多待几轮 -XX:MaxTenuringThreshold=5 # 从15降到5 -XX:TargetSurvivorRatio=40 # 降低Survivor目标使用率 # 启用晋升阈值自动调整 -XX:+UseAdaptiveSizePolicy # 默认开启

方案3：增加CMS触发提前量

bash

# 降低CMS触发阈值 -XX:CMSInitiatingOccupancyFraction=70 # 默认68，降低到65-70 -XX:+UseCMSInitiatingOccupancyOnly # 只使用设定值，不使用动态调整 # 启用并行Full GC作为后备（JDK 7u4+） -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection # Full GC时整理碎片 -XX:CMSFullGCsBeforeCompaction=0 # 每次Full GC都整理

方案4：减少内存碎片

bash

# 启用并发整理（CMS中最重要优化之一） -XX:+UseCMSCompactAtFullCollection # 在Full GC时进行内存整理 -XX:CMSFullGCsBeforeCompaction=0 # 每次Full GC都压缩 # 或者使用并发整理（JDK 5u6+） -XX:+CMSConcurrentMTEnabled # 并发阶段多线程（默认true） -XX:ConcGCThreads=4 # 并发GC线程数，CPU核数1/4

方案5：处理大对象问题

java

// 代码层面优化 // 1. 对象池化 private static final ThreadLocal<ByteBuffer> bufferCache = ThreadLocal.withInitial(() -> ByteBuffer.allocateDirect(1024)); // 2. 分批处理大数据 public void processLargeData(byte[] data) { int batchSize = 1024 * 1024; // 1MB一批 for (int i = 0; i < data.length; i += batchSize) { processBatch(data, i, Math.min(i + batchSize, data.length)); } } // 3. 使用堆外内存处理超大对象 ByteBuffer directBuffer = ByteBuffer.allocateDirect(100 * 1024 * 1024);

方案6：切换GC算法（终极方案）

bash

# 如果CMS无法满足，考虑G1（JDK 8u40+稳定） -XX:+UseG1GC -XX:MaxGCPauseMillis=200 # 目标暂停时间 -XX:G1HeapRegionSize=4m # Region大小 -XX:InitiatingHeapOccupancyPercent=45 # 触发并发标记阈值 # 或使用ZGC（JDK 11+，低延迟） -XX:+UseZGC -XX:ConcGCThreads=4 -XX:MaxGCPauseMillis=10

四、实战排查案例

案例1：电商大促期间Full GC频繁

bash

# 初始配置 -Xmx8g -Xms8g -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 # 现象：每分钟2-3次Full GC，并发失败 # 排查步骤： 1. 分析GC日志：发现每次Young GC后晋升约300MB 2. 老年代总空间：8G × 2/3 ≈ 5.33G 3. 当老年代使用到75%（4G）时触发CMS 4. 但新生代Eden区：8G × 1/3 × 0.8 ≈ 2.13G 5. 问题：一次Young GC可能晋升300MB，而老年代剩余空间可能不足 # 解决方案： -Xmx12g -Xms12g # 扩容 -XX:NewRatio=3 # 老年代9G，新生代3G -XX:CMSInitiatingOccupancyFraction=65 # 更早触发CMS -XX:+UseCMSCompactAtFullCollection # 整理碎片

案例2：内存泄漏导致的Full GC

java

// 问题代码：静态Map缓存无限增长 public class CacheManager { private static Map<String, Object> cache = new ConcurrentHashMap<>(); public static void put(String key, Object value) { cache.put(key, value); // 永不清理 } } // 排查方法： jmap -histo <pid> | head -20 # 查看对象数量排行 jmap -dump:format=b,file=heap.hprof <pid> # 使用MAT分析：查找最大的对象保留路径

案例3：元空间导致的Full GC

bash

# 现象：频繁的Metaspace Full GC # 配置：默认Metaspace大小（约20-30MB） # 解决方案： -XX:MetaspaceSize=256m # 初始大小 -XX:MaxMetaspaceSize=512m # 最大大小 -XX:+UseCompressedClassPointers # 使用压缩指针（64位系统） -XX:+UseCompressedOops # 如果类加载过多，排查： 1. 动态生成类（如CGLIB代理） 2. 热部署频繁 3. 多个ClassLoader泄漏

五、监控与预防体系

1. 监控指标配置

yaml

# Prometheus + Grafana监控模板 gc_monitor: critical_metrics: - jvm_gc_full_count:rate_5m > 0.1 # 5分钟内Full GC次数 - jvm_gc_pause_seconds:fgc > 5 # 单次Full GC暂停超过5秒 - jvm_memory_old_usage > 0.85 # 老年代使用率超85% - jvm_gc_concurrent_failure > 0 # CMS并发失败次数 alert_rules: - 当Full GC频率 > 1次/分钟，发送警告 - 当老年代使用率持续 > 80%超过5分钟，发送警告 - 当Young GC晋升速率 > 老年代空闲空间/2，发送警告

2. 日志配置最佳实践

bash

# JDK 8+ GC日志完整配置 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution # 打印晋升年龄分布 -XX:+PrintGCApplicationStoppedTime # 打印应用暂停时间 -XX:+PrintPromotionFailure # 打印晋升失败详情 -XX:+PrintFLSStatistics=2 # 打印内存碎片统计 -Xloggc:/path/to/gc-%t.log # GC日志路径，%t为时间戳 -XX:+UseGCLogFileRotation # 日志轮转 -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M

3. 压测验证方案

java

// 使用JMH进行GC压力测试 @Benchmark @BenchmarkMode(Mode.Throughput) public void testMemoryAllocation() { // 模拟生产环境对象分配模式 List<Order> orders = new ArrayList<>(1000); for (int i = 0; i < 1000; i++) { orders.add(new Order(i, "user_" + i, i * 100.0)); } // 模拟对象存活时间分布 if (Math.random() > 0.9) { orders.clear(); // 10%成为长期存活 } } // 监控压测期间的GC行为

4. 应急响应流程

bash

# 1级应急：Full GC导致服务不可用 1. 立即扩容：临时增加堆内存 2. 重启服务：使用原有配置但清理状态 3. 降级功能：关闭非核心功能减少内存分配 # 2级应急：频繁Full GC但服务可用 1. 调整GC参数：降低CMS触发阈值 2. 清理缓存：强制回收部分缓存 3. 限流降级：减少新请求进入 # 长期优化 1. 代码优化：减少大对象、内存泄漏 2. 架构优化：缓存拆分、读写分离 3. GC升级：考虑G1或ZGC

六、面试深度回答要点

基础回答

"Full GC频繁首先要收集GC日志，用jstat监控实时状态。CMS并发失败通常是因为并发标记期间老年代空间不足，解决方案包括增大堆内存、降低CMS触发阈值、优化对象晋升策略等。"

进阶回答

"我会分四步处理：1) 用jstat+jmap收集现场证据；2) 分析GC日志确定是并发失败、晋升失败还是元空间问题；3) 针对调整空间比例、优化晋升策略、减少碎片化；4) 建立监控预防体系。CMS并发失败的核心是浮动垃圾和晋升速度的平衡问题。"

架构师级回答

"这本质上是内存管理的容量规划问题。需要建立完整的监控->分析->优化闭环。除了调整JVM参数，更要关注：1) 应用对象模型的合理性；2) 缓存系统的内存控制；3) 数据结构的优化。在云原生环境下，还要考虑容器内存限制与JVM堆的配合。对于关键系统，我们会采用多级方案：短期参数调整、中期代码优化、长期架构升级到G1/ZGC。"

生产经验分享

"最近处理的一个案例：支付系统在大促时CMS并发失败。根本原因是订单对象的序列化缓存过大。我们最终方案是：1) 短期：调整-XX:CMSInitiatingOccupancyFraction到60；2) 中期：引入缓存分片和过期策略；3) 长期：迁移到G1 GC。效果：Full GC从每小时10次降到每天1次。"

掌握Full GC排查不仅是面试技能，更是保障系统稳定性的核心能力。建议在日常开发中就建立完善的监控体系，防患于未然。

如何分析Full GC的原因？jmap -histo和jmap -dump区别？

Full GC原因深度分析与jmap工具使用详解

一、Full GC原因分析完整流程

1. 诊断流程图

flowchart TD A[发现Full GC频繁] --> B[紧急现场保存] B --> C[收集三大证据] C --> D[证据1: GC日志分析] C --> E[证据2: 堆内存分析] C --> F[证据3: 线程状态分析] D --> G[确定GC类型与触发原因] E --> H[识别内存使用模式] F --> I[发现线程阻塞问题] G --> J{问题分类} H --> J I --> J J --> K[空间不足类] J --> L[代码调用类] J --> M[系统资源类] K --> N[解决方案] L --> N M --> N N --> O[验证与预防]

2. Full GC的八大原因及排查方法

原因1：老年代空间不足（最常见）

bash

# 排查方法 jstat -gcutil <pid> 1000 5 # 输出关键指标 O M YGC YGCT FGC FGCT GCT 85.91 94.12 1130 32.234 24 8.123 40.357 # 分析点： # - O(老年代) > 80% 持续增长 → 空间不足 # - FGC/FGCT 频繁且耗时 → 影响严重

典型场景：

• 长期存活对象积累（缓存、Session等）

• 大对象直接进入老年代

• 新生代晋升过快

原因2：Metaspace/永久代溢出

bash

# JDK 8+ Metaspace监控 jstat -gcutil <pid> | awk '{print $5}' # M列 > 95%危险 # 配置参数回顾： -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m

触发条件：

• 动态类生成过多（CGLIB、动态代理）

• 热部署频繁

• ClassLoader泄漏

原因3：System.gc()显式调用

bash

# 查找调用点 jstack <pid> | grep -A5 -B5 "System.gc" # 或通过BTrace动态监控 @OnMethod(clazz="java.lang.System", method="gc") public static void onSystemGC() { println("System.gc() called from: "); jstack(); }

常见源头：

• RMI分布式垃圾收集（默认每60秒）

• NIO DirectBuffer清理

• 第三方库调用

原因4：CMS并发失败

bash

# GC日志特征 [GC (CMS Initial Mark) ...] [GC (CMS Final Remark) ...] [Full GC (CMS) ...] # 出现此日志表示并发失败

根本原因：并发标记期间，老年代空间不足以容纳新生代晋升对象。

原因5：晋升失败（Promotion Failed）

bash

复制

下载

# GC日志特征 [ParNew (promotion failed): ...] [Full GC: ...]

触发条件：Young GC时，Survivor区放不下存活对象，且老年代也没有足够空间。

原因6：内存碎片化严重

bash

# 开启碎片统计 -XX:+PrintFLSStatistics=2 # 典型日志 Free space: 524288K, fragments: 16384 # 碎片数多

影响：虽然有总空闲空间，但都是小碎片，无法分配大对象。

原因7：堆外内存不足

bash

# 监控堆外内存 jcmd <pid> VM.native_memory summary # 或使用pmap pmap -x <pid> | sort -k2 -n -r | head -20

影响：Direct Buffer、JNI等使用的堆外内存不足，触发Full GC尝试回收。

原因8：JVM Bug或兼容性问题

bash

# 检查JVM版本和已知问题 java -version # 查看是否有对应版本的已知Bug修复

二、jmap命令深度解析

jmap -histo vs jmap -dump 核心区别

1. jmap -histo：实时内存快照分析

基本用法

bash

# 查看存活对象统计（不会触发GC） jmap -histo <pid> > histo_live.txt # 查看包括未回收对象的统计（会触发Full GC！） jmap -histo:live <pid> > histo_live_forced.txt # 按对象数量排序 jmap -histo <pid> | sort -n -r -k2 | head -20 # 按占用内存排序 jmap -histo <pid> | sort -n -r -k3 | head -20

输出解析示例

text

num #instances #bytes class name ---------------------------------------------- 1: 1856783 162357864 [C # char数组 2: 234567 56432896 java.lang.String 3: 45678 12345678 [Ljava.lang.Object; # Object数组 4: 12345 9876544 java.util.HashMap$Node 5: 6789 4567890 java.lang.Class

实战分析技巧

bash

# 技巧1：重点关注大对象 # [B - byte数组，[C - char数组，[I - int数组等 jmap -histo <pid> | grep -E "\[B|\[C|\[I" | head -10 # 技巧2：监控特定类增长 #!/bin/bash PID=$1 while true; do echo "=== $(date) ===" >> histo_trend.log jmap -histo $PID | grep "com.example.MyClass" >> histo_trend.log sleep 60 done # 技巧3：内存泄漏快速判断 # 比较两次histo，关注特定类实例数增长 jmap -histo <pid> > histo1.txt # 等待一段时间或执行某些操作后 jmap -histo <pid> > histo2.txt diff histo1.txt histo2.txt | grep -E "^<|^>" | head -20

2. jmap -dump：完整堆转储分析

生成堆转储文件

bash

# 基本dump（可能STW） jmap -dump:format=b,file=heap.bin <pid> # 只dump存活对象（会触发Full GC！） jmap -dump:live,format=b,file=heap_live.bin <pid> # 分块dump（大堆优化） jmap -dump:format=b,file=heap.bin,gz=9 <pid> # 安全dump（减少STW影响，JDK 7u4+） jmap -dump:format=b,file=heap.bin,live <pid>

生产环境最佳实践

bash

#!/bin/bash # 安全dump脚本 PID=$1 TIMESTAMP=$(date +%Y%m%d_%H%M%S) DUMP_FILE="heap_${PID}_${TIMESTAMP}.hprof" echo "开始dump进程 $PID 的堆内存..." echo "输出文件: $DUMP_FILE" # 1. 先用histo快速判断 jmap -histo $PID > histo_before_${TIMESTAMP}.txt # 2. 执行dump（根据堆大小设置超时） timeout 300 jmap -dump:format=b,file=${DUMP_FILE} $PID if [ $? -eq 0 ]; then echo "堆转储完成，文件大小: $(du -h ${DUMP_FILE} | cut -f1)" # 3. dump后再次histo对比 jmap -histo $PID > histo_after_${TIMESTAMP}.txt # 4. 压缩以节省空间 gzip ${DUMP_FILE} echo "文件已压缩: ${DUMP_FILE}.gz" else echo "dump失败或超时" # 备用方案：使用gcore（Linux） # gcore -o heap_core $PID fi

MAT(Memory Analyzer)分析示例

java

// 通过OQL查询内存问题 SELECT * FROM java.util.HashMap WHERE size() > 1000 // 查找重复字符串 SELECT OBJECTS s FROM java.lang.String s WHERE s.count > 1 // 查找大数组 SELECT * FROM "[B" WHERE @retainedHeapSize > 10485760

3. 两者协同分析实战

案例：内存泄漏排查流程

bash

# 第一步：快速histo扫描 jmap -histo <pid> | head -30 # 发现HashMap$Node异常多 # 第二步：趋势监控 watch -n 60 'jmap -histo <pid> | grep HashMap | head -5' # 第三步：确认增长后，生成dump jmap -dump:format=b,file=leak_suspect.hprof <pid> # 第四步：MAT分析 # 1. 打开dump文件 # 2. 运行Leak Suspects Report # 3. 查看Dominator Tree # 4. 使用OQL深入查询

案例：Full GC频繁分析

bash

# 当发现Full GC频繁时： # 1. 实时监控GC jstat -gcutil <pid> 1000 10 # 2. 查看内存分布（快速） jmap -histo:live <pid> | sort -nr -k3 | head -20 # 发现大量char[]，可能字符串缓存问题 # 3. 生成完整dump（在业务低峰期） jmap -dump:format=b,file=full_gc_analysis.hprof <pid> # 4. 使用MAT分析： # - 查看Histogram，关注大对象 # - 运行Duplicate Strings检测 # - 查看GC Roots路径

三、高级分析技巧

1. 结合其他工具综合分析

bash

# 综合诊断脚本 #!/bin/bash PID=$1 LOG_DIR="diagnosis_$(date +%s)" mkdir -p $LOG_DIR echo "收集系统信息..." > $LOG_DIR/report.txt top -b -n1 -p $PID >> $LOG_DIR/report.txt echo "收集JVM信息..." >> $LOG_DIR/report.txt jinfo -flags $PID >> $LOG_DIR/report.txt echo "收集GC状态..." >> $LOG_DIR/report.txt jstat -gcutil $PID 1000 3 >> $LOG_DIR/report.txt echo "收集线程状态..." >> $LOG_DIR/report.txt jstack $PID > $LOG_DIR/thread_dump.txt echo "收集堆直方图..." >> $LOG_DIR/report.txt jmap -histo $PID > $LOG_DIR/histo.txt echo "分析完成，查看 $LOG_DIR 目录"

2. 自动化监控预警

python

# Python监控脚本示例 import subprocess import time from datetime import datetime def check_full_gc(pid, threshold=0.1): """检查Full GC频率""" cmd = f"jstat -gcutil {pid} 1000 5" output = subprocess.check_output(cmd, shell=True).decode() lines = output.strip().split('\n') if len(lines) < 3: return False # 解析Full GC次数 fgc_values = [] for line in lines[1:]: parts = line.split() if len(parts) > 8: fgc_values.append(float(parts[8])) # FGC列 # 计算Full GC增长速率 if len(fgc_values) > 1: fgc_rate = (fgc_values[-1] - fgc_values[0]) / (len(fgc_values) - 1) if fgc_rate > threshold: alert(f"Full GC频率过高: {fgc_rate}/秒") return True return False def analyze_memory(pid): """分析内存分布""" cmd = f"jmap -histo {pid} | head -50" output = subprocess.check_output(cmd, shell=True).decode() # 解析大对象 for line in output.split('\n'): if '[B' in line or '[C' in line: parts = line.split() if len(parts) > 3: size_mb = int(parts[2]) / 1024 / 1024 if size_mb > 100: # 超过100MB的大对象 alert(f"发现大对象: {line.strip()}")

3. 容器环境特殊考虑

bash

# Kubernetes中获取Java进程堆信息 # 进入Pod kubectl exec -it <pod-name> -- /bin/bash # 查找Java进程 ps aux | grep java # 使用容器友好的内存dump # 1. 使用sidecar模式共享emptyDir # 2. 使用临时卷存储dump文件 # 3. 通过ephemeral storage限制 # 使用jattach工具（更轻量） # https://github.com/apangin/jattach jattach <pid> dumpheap /tmp/heap.bin

四、面试深度回答要点

问题1：如何分析Full GC的原因？

基础回答：
"首先通过jstat监控GC频率，然后分析GC日志确定触发类型。常见原因有老年代空间不足、Metaspace溢出、System.gc()调用等。需要结合jmap分析内存分布。"

进阶回答：
"我会建立完整的分析闭环：1) 实时监控jstat观察趋势；2) 分析GC日志确定是并发失败还是晋升失败；3) 用jmap -histo快速定位内存大户；4) 必要时生成heap dump用MAT深入分析。还要考虑堆外内存、代码调用等因素。"

架构师级回答：
"Full GC分析需要多维度联动。除了JVM层面，还要看：1) 应用层面：对象模型、缓存策略；2) 架构层面：流量突增、数据倾斜；3) 基础设施：容器内存限制、物理机资源。我们会建立监控告警->自动诊断->智能优化的全链路体系。"

问题2：jmap -histo和jmap -dump区别？

对比回答：
"histo是轻量级文本统计，适合快速分析内存分布，对服务影响小；dump是完整二进制堆转储，用于深度分析内存泄漏，但文件大、可能STW。histo看『有哪些类，各有多少实例』，dump看『每个对象的具体内容和引用关系』。"

实战回答：
"生产环境中，我通常先用histo快速扫描，如果发现某个类实例数异常增长，再用dump深入分析。比如发现HashMap$Node数量持续增长，就生成dump用MAT查看具体是哪些HashMap以及它们的GC路径。"

原理级回答：
"histo基于JVM的Klass元数据统计，只读操作；dump需要遍历整个堆的对象图并序列化，涉及内存拷贝。在ZGC/Shenandoah等新GC下，dump可能需要更多协调来保证一致性视图。"

篇幅限制下面就只能给大家展示小册部分内容了。整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafc

需要全套面试笔记及答案
【点击此处即可/免费获取】​​​

高频追问问题

1. histo:live为什么可能触发Full GC？

   • 因为它需要获取准确的存活对象计数，JVM可能需要执行GC来回收不可达对象

2. dump对服务的影响有多大？

   • 取决于堆大小和IO速度，通常会引起秒级到分钟级的STW

   • 大堆（32G+）可能需要几分钟，建议在低峰期进行

3. 除了jmap还有哪些堆分析工具？

   • jcmd GC.heap_info（JDK 7+）

   • VisualVM、JProfiler、YourKit等图形工具

   • async-profiler可以低开销采样

4. 如何分析非堆内存问题？

   • Native Memory Tracking(NMT)：-XX:NativeMemoryTracking=detail

   • pmap查看进程内存映射

   • gdb调试（高级）

掌握这些分析技能，不仅能解决线上问题，更能建立预防性监控体系，让系统更加稳健。