基于gc.log与堆转储文件快速分析内存导致服务挂掉问题

最新推荐文章于 2026-07-01 10:35:35 发布
原创 最新推荐文章于 2026-07-01 10:35:35 发布 · 770 阅读 · 9 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
大数据

当前文章被收录于：

大数据
72 篇文章 0 人学习
订阅专栏 查看详情
架构

当前文章被收录于：

架构
51 篇文章 0 人学习

软件架构 系统架构

订阅专栏 查看详情
分布式

当前文章被收录于：

分布式
12 篇文章 0 人学习
订阅专栏 查看详情

第一步：5分钟快速定位问题类型

1.1 检查GC日志中的死亡信号

# 查看最后50行，找到死亡时间点
tail -50 gc.log

# 或者更精确地查找死亡痕迹
grep -n "OutOfMemoryError\|FULL GC\|Allocation Failure\|concurrent mode failure" gc.log | tail -10

1.2 运行这个快速诊断脚本

#!/bin/bash
echo "=== GC日志快速诊断 ==="
echo "1. 文件信息:"
wc -l gc.log
echo -e "\n2. 关键错误统计:"
echo "OOM错误: $(grep -c "OutOfMemoryError" gc.log)"
echo "Full GC次数: $(grep -c "Full GC" gc.log)"
echo "并发模式失败: $(grep -c "concurrent mode failure" gc.log)"

echo -e "\n3. 最后5次关键事件:"
tail -100 gc.log | grep -B2 -A2 "Full GC\|OOM\|failed\|Error" | tail -20

echo -e "\n4. 内存增长趋势:"
grep "Full GC" gc.log | tail -5 | awk '{
    for(i=1;i<=NF;i++) {
        if($i ~ /old=[0-9]+K->[0-9]+K/) {
            match($i, /old=([0-9]+)K->([0-9]+)K/, arr)
            printf("时间 %s: 老年代 %sK → %sK\n", $1, arr[1], arr[2])
        }
    }
}'

 第二步：分析堆转储文件（核心步骤）

2.1 先查看堆转储基本信息

# 检查文件有效性
jmap -histo heap_dump.hprof 2>&1 | head -5

# 如果报错，可能需要指定JRE路径
export JAVA_HOME=/path/to/java
$JAVA_HOME/bin/jmap -histo heap_dump.hprof > /dev/null && echo "堆转储文件正常" || echo "文件可能损坏"

2.2 生成对象直方图（最重要的一步）

# 按对象数量排序
jmap -histo heap_dump.hprof | head -50 > histo_by_count.txt

# 按内存占用排序（倒序）
jmap -histo heap_dump.hprof | awk '
BEGIN {print "Class_Name\t<实例数>\t<总大小>\t<平均大小>"}
NR>3 {
    gsub(/</, "", $2); gsub(/>/, "", $2)
    printf("%s\t%s\t%s\t%.1f\n", $2, $3, $4, $4/$3)
}' | sort -k3 -rn | head -50 > histo_by_size.txt

echo "已生成 histo_by_size.txt，查看前50个最大对象"

2.3 重点关注你们自己的代码

# 查找你们公司包名的对象
jmap -histo heap_dump.hprof | grep -E "com\.yourcompany|com\.yourproject" | sort -k4 -rn > our_objects.txt

# 如果没有明确包名，查找常见的可疑类
jmap -histo heap_dump.hprof | grep -E "HashMap|ArrayList|LinkedList|ConcurrentHashMap|byte\[\]|char\[\]" > collections.txt

2.4 分析具体问题模式

#!/bin/bash
echo "=== 堆转储详细分析 ==="

# 1. 查看byte[]数组占用（通常最大）
echo "1. byte[] 数组分析:"
BYTE_ARRAY_INFO=$(jmap -histo heap_dump.hprof | grep "^\s*[0-9]\+:\s\+[0-9]\+\s\+[0-9]\+\s\+byte\[\]" | head -1)
if [ ! -z "$BYTE_ARRAY_INFO" ]; then
    echo "  发现: $BYTE_ARRAY_INFO"
    NUM_BYTE_ARRAYS=$(echo $BYTE_ARRAY_INFO | awk '{print $2}')
    TOTAL_SIZE=$(echo $BYTE_ARRAY_INFO | awk '{print $3}')
    AVG_SIZE=$(echo "scale=2; $TOTAL_SIZE * 1024 / $NUM_BYTE_ARRAYS" | bc)
    echo "  平均每个byte[]大小: $AVG_SIZE 字节"
fi

# 2. 查看HashMap相关
echo -e "\n2. HashMap分析:"
jmap -histo heap_dump.hprof | grep -E "HashMap\$Node|HashMap\$Entry" | head -3

# 3. 查看线程数量
echo -e "\n3. 线程分析:"
THREAD_COUNT=$(jmap -histo heap_dump.hprof | grep " java.lang.Thread" | awk '{print $2}')
if [ ! -z "$THREAD_COUNT" ]; then
    echo "  线程数量: $THREAD_COUNT"
    if [ $THREAD_COUNT -gt 500 ]; then
        echo "  ⚠️  线程数过多!"
    fi
fi

# 4. 查看Class数量
echo -e "\n4. Class数量:"
jmap -histo heap_dump.hprof | grep " java.lang.Class" | awk '{print "  Class数量: "$2}'

 第三步：分析对象引用关系

3.1 查找最大的对象并追踪引用链

# 先找到最大的类名
BIGGEST_CLASS=$(head -1 histo_by_size.txt | awk '{print $1}')

echo "最大的类是: $BIGGEST_CLASS"
echo "开始分析引用链..."

# 如果是你自己的类，直接分析
if [[ $BIGGEST_CLASS == com.* ]]; then
    echo "这是你们自己的类，需要找到谁创建了它"
    
    # 获取类的所有实例ID
    echo "获取实例ID..."
    jmap -histo heap_dump.hprof | grep "$BIGGEST_CLASS" | head -5
fi

3.2 使用jhat命令行模式（需要额外内存）

# 启动jhat分析服务（可能需要4-8G内存）
jhat -J-Xmx4g heap_dump.hprof &
JHAT_PID=$!
echo "jhat启动在端口7000，PID: $JHAT_PID"

# 等待启动
sleep 30

# 查询最大的对象
curl -s "http://localhost:7000/oql/?query=select%20s%20from%20java.lang.Object%20s%20where%20s.getClass().getName().equals(\"$BIGGEST_CLASS\")" | grep -A20 -B20 "instance"

# 完成后杀掉jhat
kill $JHAT_PID

3.3 更轻量的分析方式：使用jstack分析线程

如果有线程转储，可以结合分析：

# 查看哪些线程持有大量内存
grep -A5 -B5 "RUNNABLE" thread_dump.txt | grep -E "com\.yourcompany|正在执行" | head -20

第四步：结合业务代码定位问题

4.1 从堆转储反推代码位置

#!/bin/bash
echo "=== 问题定位指南 ==="

# 从histo_by_size.txt中读取可疑类
echo "检查以下可疑类:"
cat histo_by_size.txt | head -10 | while read line; do
    CLASS_NAME=$(echo $line | awk '{print $1}')
    INSTANCE_COUNT=$(echo $line | awk '{print $2}')
    TOTAL_SIZE_MB=$(echo $line | awk '{print $3/1024}')
    
    echo "类: $CLASS_NAME"
    echo "  实例数: $INSTANCE_COUNT"
    echo "  总内存: ${TOTAL_SIZE_MB}MB"
    
    # 给出可能的问题点
    if [[ $CLASS_NAME == *HashMap* ]]; then
        echo "  可能问题: 缓存未清理或无限增长的Map"
    elif [[ $CLASS_NAME == *ArrayList* ]]; then
        echo "  可能问题: 列表无限增长或查询未分页"
    elif [[ $CLASS_NAME == *byte[]* ]]; then
        echo "  可能问题: 大文件处理或网络传输未使用流"
    elif [[ $CLASS_NAME == *Thread* ]]; then
        echo "  可能问题: 线程池配置过大或线程泄露"
    fi
    echo "---"
done

4.2 在代码库中搜索可疑类

# 假设你在项目根目录
PROJECT_ROOT="/path/to/your/project"

# 搜索使用HashMap且可能有问题的地方
echo "搜索可能的问题代码..."
find $PROJECT_ROOT -name "*.java" -type f | xargs grep -l "static.*HashMap\|static.*ConcurrentHashMap" | head -10

# 搜索缓存相关代码
find $PROJECT_ROOT -name "*.java" -type f | xargs grep -l "Cache\|cache" | head -10

# 搜索大对象创建
find $PROJECT_ROOT -name "*.java" -type f | xargs grep -l "new byte\[.*\]\|ByteBuffer.allocate" | head -10

第五步：验证和复现

5.1 创建最小复现脚本

#!/bin/bash
echo "=== 内存问题复现脚本 ==="

# 1. 提取关键参数
echo "从GC日志提取关键参数:"
LAST_FULL_GC=$(grep "Full GC" gc.log | tail -1)
echo "最后一次Full GC: $LAST_FULL_GC"

# 2. 计算内存增长率
echo -e "\n计算内存增长率:"
grep "Full GC" gc.log | tail -10 | awk '{
    for(i=1;i<=NF;i++) {
        if($i ~ /old=[0-9]+K->[0-9]+K/) {
            match($i, /old=([0-9]+)K->([0-9]+)K/, arr)
            if(last_after > 0) {
                growth = (arr[2] - last_after) / last_after * 100
                printf("增长率: %.2f%% (从 %sK 到 %sK)\n", growth, last_after, arr[2])
            }
            last_after = arr[2]
        }
    }
}'

# 3. 给出复现建议
echo -e "\n复现建议:"
echo "1. 使用以下JVM参数启动测试:"
echo "   -Xmx512m -Xms512m -XX:+HeapDumpOnOutOfMemoryError"
echo "2. 模拟以下操作:"
echo "   - 重复调用最近修改的接口"
echo "   - 大数据量查询"
echo "   - 文件上传下载"

第六步：创建修复方案

6.1 根据分析结果生成修复建议

#!/bin/bash
echo "=== 修复方案生成 ==="

# 读取最大的类
TOP_CLASS=$(head -1 histo_by_size.txt | awk '{print $1}')

echo "问题根因: 发现大量 $TOP_CLASS 对象"

case $TOP_CLASS in
    *HashMap*)
        echo "修复方案:"
        echo "1. 检查静态HashMap是否无限增长"
        echo "2. 添加LRU淘汰策略"
        echo "3. 使用WeakHashMap或ConcurrentHashMap"
        ;;
    *ArrayList*)
        echo "修复方案:"
        echo "1. 查询添加分页"
        echo "2. 设置列表初始大小"
        echo "3. 及时清理不再使用的列表"
        ;;
    *byte*)
        echo "修复方案:"
        echo "1. 大文件使用流处理"
        echo "2. 复用ByteBuffer"
        echo "3. 限制上传文件大小"
        ;;
    *)
        echo "修复方案:"
        echo "1. 检查 $TOP_CLASS 对象的创建位置"
        echo "2. 查看是否有循环创建或静态引用"
        echo "3. 添加对象池或复用机制"
        ;;
esac

第七步：创建完整报告

#!/bin/bash
REPORT="memory_issue_report_$(date +%Y%m%d_%H%M%S).txt"

{
echo "内存问题分析报告"
echo "========================"
echo "生成时间: $(date)"
echo

echo "一、问题现象"
echo "------------"
echo "服务挂掉时间: $(tail -1 gc.log | awk '{print $1}')"
echo "错误信息:"
grep "OutOfMemoryError" gc.log | tail -1
echo

echo "二、GC日志分析"
echo "------------"
echo "1. Full GC次数: $(grep -c "Full GC" gc.log)"
echo "2. 最后5次Full GC:"
grep "Full GC" gc.log | tail -5 | awk '{print "   " $0}'
echo

echo "三、堆转储分析"
echo "------------"
echo "1. 堆转储文件大小: $(du -h heap_dump.hprof | awk '{print $1}')"
echo "2. 内存占用TOP 5:"
head -5 histo_by_size.txt | awk '{print "   " $0}'
echo

echo "四、问题根因"
echo "------------"
echo "主要问题类: $(head -1 histo_by_size.txt | awk '{print $1}')"
echo "实例数量: $(head -1 histo_by_size.txt | awk '{print $2}')"
echo "占用内存: $(head -1 histo_by_size.txt | awk '{print $3/1024}') MB"
echo

echo "五、修复建议"
echo "------------"
# 根据TOP类给出建议
TOP_CLASS=$(head -1 histo_by_size.txt | awk '{print $1}')
if [[ $TOP_CLASS == *HashMap* ]]; then
    cat << EOF
1. 代码层面:
   - 检查所有静态HashMap，添加大小限制
   - 使用Guava Cache或Caffeine替代
   - 添加缓存淘汰策略

2. 配置层面:
   - 调整JVM参数: -XX:NewRatio=3
   - 设置合理堆大小
   - 启用G1垃圾回收器

3. 监控层面:
   - 添加缓存命中率监控
   - 设置内存使用告警阈值
EOF
fi

echo
echo "六、验证方法"
echo "------------"
echo "1. 本地复现: 使用相同JVM参数启动，模拟用户操作"
echo "2. 性能测试: 使用jmeter压测，观察内存增长"
echo "3. 监控验证: 修复后持续监控老年代使用率"

} > $REPORT

echo "报告已生成: $REPORT"

快速排查流程图

开始
  ↓
1. tail -50 gc.log                         # 看死亡时刻
  ↓
2. jmap -histo heap_dump.hprof > histo.txt # 生成对象清单
  ↓
3. sort -k4 -rn histo.txt | head -20       # 找最大的对象
  ↓
4. 判断对象类型：
   - 如果是byte[] → 检查文件/网络操作
   - 如果是HashMap → 检查缓存代码
   - 如果是自定义类 → grep搜索该类
  ↓
5. 结合gc.log看增长趋势                   # 确认是否泄漏
  ↓
6. 修复并验证

最重要的三条命令

# 1. 查看死亡瞬间
tail -100 gc.log | grep -B5 -A5 "OutOfMemoryError\|Full GC"

# 2. 找到罪魁祸首
jmap -histo heap_dump.hprof | sort -k4 -rn | head -20

# 3. 定位到代码
grep -r "可疑类名" /path/to/project --include="*.java"

记住这个排查口诀：

  • 看日志（怎么死的）

  • 找对象（谁占的内存）

  • 搜代码（谁创建的）

  • 验增长（是否持续增长）

按照这个流程，即使只有命令行，30分钟内也一定能找到问题根源！

标签
#jvm #java #系统架构
9、学会查看GC日志
weixin_35794878的博客
07-13 1万+
通过一个简单的例子来触发程序发生Young GC，并学会查看GC日志
Java中的GC（垃圾回收）log ，以及 JVM 介绍
sun0322
08-10 8961
目录 ■启动参数 ■启动Log ■GC Log ■GC Log ---- 垃圾回收部分 Log【Full GC】 ■GC Log 对性能的影响 ■JVM 内存模型 ■GC Log ---- 垃圾回收部分 Log ----每一列的含义 【JVM启动后，经过的时间】 【PSYoungGen】 【ParOldGen】 【Metaspace】 【默认元空间大小】 【Time】 ■图文信息 ■启动参数 java -verbose:gc -Xloggc:C:/Logs/Sprin...
JVM调优的GC日志观察解读
zhk
09-14 1149
JVM调优的GC日志观察解读
JVM查看GC日志
cristianoxm的博客
04-23 5633
一、如何打印出JVM GC日志 需要在系统的JVM参数中加入GC日志的打印选型，jvm参数如下所示： -XX:NewSize=5242880 -XX:MaxNewSize=5242880 -XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10485760 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+Print
JVM系列4-GC log
唐影若凡的专栏
06-30 4213
1、JVM参数-XX:+PrintGC参数-XX:+PrintGC开启了简单GC日志模式，为每一次新生代（young generation）的GC和每一次的Full GC打印一行信息。日志默认输出到终端。下面举例说明：[GC 1843K->632K(116736K), 0.0112928 secs] [Full GC 632K->558K(116736K), 0.0157125 secs]每行开始首
Java内存泄漏排查指南（从GC日志到堆转储的完整链路解析）
PixelStream的博客
10-21 391
掌握Java内存泄漏排查全链路方法，从GC日志分析到堆转储定位，精准识别内存问题根源。适用于高并发、长时间运行的Java应用，结合工具与实战步骤，高效诊断与优化。值得收藏的完整指南。
从内存泄漏到GC调优：用VisualVM+IDEA插件实战分析一个‘吃内存’的Java程序
dianzhuique8587的博客
06-12 350
本文详细介绍了如何使用VisualVM和IDEA插件分析Java程序中的内存泄漏问题，并通过GC调优提升性能。通过实战案例演示了从问题发现到解决的全过程，包括工具配置、内存监控、堆转储分析和代码优化，帮助开发者掌握Java性能调优的关键技能。
从OOM到性能优化：Java堆转储分析的实战指南
weixin_29246195的博客
01-23 322
本文详细介绍了Java应用在遭遇OOM（内存溢出）时的应急响应与堆转储分析实战指南。通过jmap、jhat等工具的使用技巧，结合典型内存问题案例，帮助开发者快速定位和优化内存问题，提升系统性能。文章还提供了防御性编程和监控体系的配置建议，确保Java应用的稳定运行。
一次 JVM Full GC 排查全过程
m0_69632475的博客
01-21 762
/ 每次实例化都创建 @Override public Map getNullableResult(ResultSet resultSet, String s) throws SQLException { return this.toObject(resultSet.getString(s), map.getClass());# 或者使用 jcmd（推荐） jcmd GC.heap_dump /tmp/heap_dump_20260111.hprof。# 查看堆内存使用 jmap -heap。
IntelliJ IDEA内置的Java内存分析神器，不用装插件也能搞定.hprof文件
weixin_42531925的博客
04-04 515
本文详细介绍了IntelliJ IDEA内置的Java内存分析工具，无需安装插件即可高效处理.hprof文件。通过对比专业工具，展示了IDEA在便捷性、分析速度和代码关联度上的优势，并提供了生成堆转储文件的三种方法及实战案例分析，帮助开发者快速定位内存泄漏问题。
别再只盯着GC日志了！用MAT和VisualVM深度剖析JVM hprof文件，揪出隐藏的内存泄漏
weixin_27697385的博客
04-12 153
本文深入探讨了如何使用Eclipse Memory Analyzer (MAT)和VisualVM分析JVM hprof文件，精准定位内存泄漏问题。通过对比两款工具的核心能力，提供高级分析技巧和典型内存泄漏模式识别方法，帮助开发者从GC日志转向更专业的hprof文件分析，提升JVM内存问题排查效率。
如何排查java程序的宕机和oom？如何解决宕机和oom？
LUCIAZZZ的博客
03-29 1420
用jmap生成我们的堆空间的快照Heap Dump（堆转储文件），来分析我们的内存占用 用可视化工具，例如java中的jhat分析Heap Dump文件 ，它分析完会通过一个浏览器打开一个可视化页面展示分析结果 根据oom的类型来调整我们的内存配置
工业级堆转储（Heap Dump）分析方法（.NET 7+ / .NET 5+）
专注于前沿技术的探索与实践，热衷于从代码逻辑、架构设计到行业应用等多维度深挖技术本质。期待在技术之路上与你共同成长～
11-10 781
概念说明Heap Dump.NET 进程完整内存快照，包含：所有对象、类型、大小、引用关系用途List<T>无限增长、Form未释放、事件未注销格式.dmp（Windows）/.core（Linux）步骤工具时间生成 dump1s打开快照10s对比增长Diff View30s找引用链1min修复代码事件注销2min你的ROBOT.exe能力状态自动 dumpDone5 分钟定位Done自动化分析Done生产零泄漏Done提供Visual Studio 分析模板。
Spring应用内存泄漏实战：如何用MAT揪出那个偷偷吃内存的ApplicationContext
weixin_29190573的博客
03-15 236
本文详细介绍了如何使用MAT工具诊断Spring应用中的内存泄漏问题，特别是由ApplicationContext引起的内存泄漏。通过jmap获取堆转储文件，利用MAT分析内存大户和对象引用链，帮助开发者快速定位并修复内存泄漏问题，提升应用稳定性。
Android Studio Memory Profiler实战：揪出内存泄漏的罪魁祸首（附调用栈分析技巧）
weixin_27303545的博客
04-11 385
本文详细介绍了如何使用Android Studio Memory Profiler工具诊断和解决内存泄漏问题。通过实战案例，包括定位泄漏Activity、分析大对象占用和解决内存抖动，帮助开发者掌握调用栈分析技巧和优化策略，提升应用性能。
从hs_err_pid.log到MAT：手把手教你用Arthas和MAT分析Java内存泄漏（附CPLEX实战案例）
weixin_28736355的博客
04-20 300
本文详细介绍了如何从hs_err_pid.log错误日志入手，结合Arthas和MAT工具分析Java内存泄漏问题。通过实战案例演示了从日志解读、在线诊断到堆转储分析的完整流程，并提供了CPLEX内存泄漏的解决方案和JVM参数优化建议，帮助开发者高效解决Cannot allocate memory等内存问题。
MAT支配树完全指南：从对象引用图到内存泄漏根源分析（含Shallow/Retained Heap对比）
pink的博客
02-19 939
本文详细介绍了如何使用Eclipse Memory Analyzer Tool（MAT）中的支配树功能进行Java内存分析，从对象引用图到内存泄漏根源的全面解析。通过对比Shallow Heap与Retained Heap的差异，帮助开发者快速定位内存问题关键对象，并提供实战案例和高级技巧，优化系统内存使用。
Java性能调优必备：用VisualVM+VisualGC插件揪出内存泄漏（附OOM分析案例）
sky77的博客
02-18 169
本文深入解析了Java性能调优中VisualVM与VisualGC插件的实战应用，通过电商系统OOM案例演示如何快速定位内存泄漏。详细介绍了工具配置、堆转储分析、远程监控方案及优化技巧，帮助开发者有效解决JVM内存问题。
【我的Android进阶之旅】使用Android Studio 3.6 的 Android Profiler快速进行内存泄漏检查
字节卷动
03-24 3719
一、概要 最近更新了Android Studio 3.6.1版本，发现一个新的功能： 在Memory Profiler中分析堆转储时，可以过滤Android Studio认为可能指示应用程序中Activity和Fragment实例的内存泄漏的概要分析数据。 要使用此功能，请先捕获堆转储或将堆转储文件导入Android Studio。 要显示可能正在泄漏内存的碎片和活动，请在“Memory Pr...
JDumpSpider：从Java堆转储文件中自动化提取敏感信息的安全工具
最新发布
weixin_34279579的博客
07-01 399
Java堆转储文件是JVM内存的瞬时快照，常用于诊断内存泄漏和性能问题。其核心原理在于序列化了堆中所有存活对象的状态、类信息和引用关系。这一特性使其在安全领域展现出独特的技术价值：内存中可能意外驻留数据库密码、API密钥等敏感配置信息。通过自动化工具对堆转储文件进行模式匹配和深度扫描，可以高效识别这些潜在的信息泄露风险，广泛应用于内部安全审计、渗透测试（授权范围内）和事故后溯源分析等场景。JDumpSpider正是这样一款专精于此的工程实践工具，它通过预定义的提取器规则，能精准定位HikariDataSou
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值