记一次JVM内存泄漏问题排查、分析过程

最新推荐文章于 2025-09-07 18:12:50 发布
原创 最新推荐文章于 2025-09-07 18:12:50 发布 · 1k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #spring boot

本文详述了一次使用SpringBoot + Akka框架的项目在JDK 1.8环境下遇到的内存泄漏问题。通过jmeter压测，配合jconsole、jvisualvm、ha450.jar和mat工具进行监控和分析，发现在增大堆内存后仍出现GCOverheadLimitExceeded异常。通过对比不同时间点的dump文件，定位到Akka流的使用问题。分析过程中发现多个内存泄漏点，包括未释放的对象、过多线程和监听器等问题。解决问题的方法包括修改代码、手动释放强引用对象以及正确使用线程池。文章强调了内存泄漏的多种原因，并提供了获取dump文件和启动jmeter的命令。

背景

项目使用框架为springboot + akka(想要了解akka框架的同学可自行查看)，JDK版本1.8 使用的垃圾回收器为1.8默认的UseParallelGC

工具说明

  1. 压测工具使用的是jmeter脚本
  2. 性能监测工具使用的是jdk自带工具，jconsole、jvisualvm，一般第一个基本可以满足监测需求
    在这里插入图片描述
  3. 分析工具使用的是IBM的工具，ha450.jar(分析dump文件)、jca450.jar(分析线程信息)
    分析dump文件也可以使用 JProfile和mat(两个都为可视化分析工具)

使用相关命令说明

  1. 获取dump文件命令
    (1) 自己手动获取使用命令 jmap -dump:format=b,file=dump18947_1.hprof 18947，pid替换为自己服务pid即可。
    (2) 在服务启动命令添加jvm参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dev/jvm_log，在服务发生内存泄漏时会自动生成dump文件在指定目录下。
  2. 获取线程信息命令
    使用 jstack 命令获取，如 jstack pid > jstack.log

内存泄漏分析过程

  1. 首次压测 设置堆大小为2G，压测几个小时发现服务出现 java.lang.OutOfMemoryError: GC overhead limit exceeded 异常，首次认为是堆内存设置太小(压测服务本身比较吃资源所以有此猜测，是否因为参数问题要视项目具体情况而言)，然后重新设置堆大小为 8G后重新压测，发现老年堆持续上涨且GC后并不能释放，所以定位为代码问题。
    在这里插入图片描述
  2. 因要在本地分析，dump文件较大时使用分析工具无法打开，所以重新设置堆大小为2G重新进行压测。使用jmap命令分别在压测开始的10min、1h、内存溢出时获取dump文件进行对比分析，这样能够很直观的看出来哪些资源快速增长且未释放。
  3. 这里我使用的分析工具为 ha450.jar和mat，下面使用mat进行说明
    在这里插入图片描述
    在这里插入图片描述
    这里的可视化工具会把问题给暴露出来，dump两个文件对比可以明显的发现是akka 流使用时候的问题，具体情况还需要再次进行分析。
  4. 查看具体问题
    在这里插入图片描述
    这里可以给我们更详细的信息，当我们选择点击进去查看时可以发现问题
    在这里插入图片描述
    这时候我们去自己的代码中去追溯，可以发现一些对象没有释放，一直被占用。
  5. 问题处理
    有时候内存泄漏点可能不止一个，这个需要我们多次压测并进行分析，我这里只是讲分析的一个思路。我在压测的过程中就是发现了多个泄漏点，逐一解决后压测内存才恢复正常。
    出现内存泄漏的原因有很多，如：
    (1) 对象创建较多且一直被引用导致gc不能回收
    (2) 创建线程过多导致的内存溢出
    (3) 一些监听器的使用
    (4) 静态集合类引起的内存泄漏等

在解决这类问题的时候，我们可以先找到有问题的代码进行修改，然后对一些强引用对象可以尝试手动置空释放。如果使用线程池要正确的去使用，并对一些资源进行回收释放。

共勉~

新增：

  1. dump当前进程文件命令：jmap -dump:format=b,file=文件名称.hprof 进程号；
  2. jmeter启动命令： nohup ./apache-jmeter-4.0/bin/jmeter.sh -n -t test.jmx -l result.jtl &
  3. jar启动参数：nohup java -Xmx8g -Xms8g -XX:+UnlockExperimentalVMOptions -Dfile.encoding=UTF-8 -XX:+UseG1GC -XX:MaxGCPauseMillis=10 -XX:GCPauseIntervalMillis=200 -XX:+UseStringDeduplication -XX:+ParallelRefProcEnabled -XX:+DisableExplicitGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dev/jvm_log -Djava.rmi.server.hostname=172.31.184.209 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -jar service-3.1-SNAPSHOT.jar &
如何高效解决 Java 内存泄漏问题方法论
张彦峰的博客
03-18 11万+
本文介绍了高效诊断和优化 Java 内存泄漏问题的系统化方法。通过获取内存快照、使用 MAT 和 JProfiler 等工具分析对象，逐步排查泄漏源，确认问题并优化代码，开发者可以解决内存泄漏并提升应用性能。内容包括内存快照生成、内存差异对比、疑似泄漏检测、代码优化等，确保垃圾回收机制正常工作，最终提高应用的稳定性和效率。
JVM内存问题排查
偶尔写些东西，意思一下我也参与了内卷
01-25 1551
JVM 的堆空间分成2个区域：年轻代、老年代年轻代又进一步细分成3个区域：Eden、Survivor From、Survivor To。
JVM 问题排查
Penny的博客
05-26 1593
CPU使用率高找出使用率高的进程的pidtop找出使用率高的线程tpidtop -p pid -H查看使用率高的线程当前在干什么jstack -l pid > stack.log// 将线程的tpid转为16进制，到stack.log中查找 grep tpid stack.log -a3GC问题// -t：打印时间戳，1s每隔1秒打印一次 jstat -gcutil -t pid 1s也可以通过查看
JVM堆内存泄露分析
jh035512的博客
11-19 744
使用全局的对象时，最好不要直接引用生命周期变化的对象，如果非要引用其它对象，则保证被引用的对象也是全局的，不会被销毁重建，如果被引用对象会被销毁重建，则在销毁时，从全局对象中删除对其的引用，以免造成内存泄露。
JVM 的内存泄漏（Memory Leak）
最新发布
qq_61723836的博客
09-07 1006
JVM内存泄漏是指不再使用的对象因被引用而无法被垃圾回收，导致内存消耗增加甚至引发OutOfMemoryError。常见原因包括静态集合类持有引用、未关闭资源（如文件流、连接）、内部类持有外部类引用、ThreadLocal未清理、缓存未设置淘汰机制等。排查方法包括监控工具（jstat、jmap）、生成堆转储分析（MAT工具）和检查GC日志。预防措施包括避免滥用static变量、及时关闭资源、合理使用缓存、及时清理ThreadLocal、代码审查和压力测试。核心思路是确保无用对象能被GC回收。
一次完整的JVM堆外内存泄漏故障排查记录
m0_73311735的博客
04-03 393
记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些「JVM内存分配的原理分析」以及「常用的JVM问题排查手段和工具分享」，希望对大家有所帮助。在整个排查过程中，我也走了不少弯路，但是在文章中我仍然会把完整的思路和想法写出来，当做一次经验教训，给后人参考，文章最后也总结了下内存泄漏问题快速排查的几个原则。「本文的主要内容：」故障描述和排查过程故障原因和解决方案分析JVM堆内内存和堆外内存分配原理常用的进程内存泄漏排查指令和工具介绍和使用。
JVM 内存泄露 分析 （史上最全）
架构师尼恩
02-08 2128
文章很长，建议收藏起来，慢慢读! 备注：持续更新中… 进大厂、升架构、拿高薪 必备 的 经典图书和资料： 高薪必备1 ： 经典图书《Netty Zookeeper Redis 高并发实战》 奉上 NIO、Netty Reactor模式 高性能 底层知识 高薪必备2 ： 经典图书《SpringCloud、Nginx高并发核心编程》 奉上 微服务、分布式 高并发 底层知识 高薪必备3 ：来Java高并发研究社群<疯狂创客圈>，价值 1000元网盘资源大礼包，免费拿 【博客园总
记录一次jvm内存泄露的排查过程
qq_33544052的博客
02-11 509
　　前些天，运维告诉我刚上线的java服务占用CPU过高。 以下是发现解决问题的具体流程。 　　1：通过#top命令查看，我的java服务确实把CPU几乎占满了，如图 　　 　　可看到18400这个进程CPU占用达到了1200%，这确实不太正常，那么我们接下来分析到底哪些线程占用了CPU 　　2：通过#top -Hp 18400这条命令我们可以看到这个进程中线程的情况，部分截图如下。 　　通过截图可以看到，前面的线程占用的CPU是比较高的，那我们就具体分析这些...
jvm排查问题-实践追踪问题 与思路--堆内堆外内存泄漏排查方针
凌波漫步
12-26 1419
JDK默认使用G1GC算法，G1将堆内存划分为等大的Region，并逐一选取可用的Region分配对象。一个对象的Size超过Region大小的一半则被称为大对象（Humongous），G1会将大对象独立放在一个或连续多个Region中。独立分配/回收大对象的成本比较低，不需要和其它小对象公用Region；存放大对象的Region放在独立的区域中，存活的大对象不会被GC Copy，介绍了GC开销；
【编程底层思考】JVM内存泄漏和内存溢出的原因、解决方案，以及排查步骤
Dylaniou的博客
09-04 872
JVM内存泄漏和内存溢出的原因、解决方案，以及排查步骤。
JVM 内存分析
04-05
NULL 博文链接：https://kevin1.iteye.com/blog/1538471
记录一次生产线上JVM_OOM事故排查真实过程（主要分析并定位问题代码）
凹凸曼的博客
12-16 677
文章目录分析准备开始分析 最近几天总出现线上程序莫名其妙登录不上，同事给我说‘没事重启下就好了’（不是大厂），肯定不能总重启啊，这肯定是有问题的。于是就打开日志发现最后报了“java.lang.OutOfMemoryError：Java heap space”。之前也没遇到这种情况，也没有相应的措施。 之前jvm是默认分配的堆大小，于是我就调大了并添加些启动命令方便再次报OOM时观察jvm中堆的状况： -Xms1024m -Xmx1024m -XX:+PrintGCDetails -XX:+PrintGC
【JVM】问题排查
weixin_30615767的博客
01-22 160
jetty的调用场景是：为了支持Servlet规范中的注解方式（使得不再需要在web.xml文件中进行Servlet的部署描述，简化开发流程），jetty在启动时会扫描class、lib包，将使用注解方式声明的Servlet、Listener注册到jetty容器，在扫描jar包的时候调用了inflate，分配了大量的内存，此时通过关键词搜索到Memory leak while scanning a...
JVM 12：内存泄漏分析
Fisher3652的博客
08-17 651
内存泄漏1. 内存分析工具1.1 MAT 简介2. MAT 中的 Incoming/Outgoing References2.1 代码示例2.2 incoming references2.3 outgoing references3. MAT 中的浅堆与深堆3.1 案例分析3.2 引用变动的影响 1. 内存分析工具 使用 jmap –histo 这种命令可以分析哪些对象占据着我们的堆空间。但是那是比较容易分析的问题，如果是遇到内存情况比较复杂 的情况，命令的方式是看不出来的，这个时候我们必须要借助一下工具。
记录一次jvm内存泄露的问题
kkkkk0826的专栏
10-16 446
　　前些天，运维告诉我刚上线的 java服务占用CPU过高。 以下是发现解决问题的具体流程。 　　1：通过#top命令查看，我的java服务确实把CPU几乎占满了，如图 　　可看到18400这个进程CPU占用达到了1200%，这确实不太正常，那么我们接下来分析到底哪些线程占用了CPU 　　2：通过#top -Hp 18400这条命令我们可以看到这个进程中线程的情况，部...
JVM问题排查
samyang1的博客
06-03 2579
本文将介绍JDK自带的JVM排查工具。其提供的排查工具有：（1）jps：JVM Process Status Tool，显示系统内所有的JVM进程；（2）jstat：JVM Statistics Monitoring Tool，可以收集JVM相关的运行数据；（3）jinfo：Configuration Info for Java，显示JVM配置信息；（4）jmap：Memory Map for J...
Linux strace命令使用详解
竹林听雨
07-10 1434
strace是Linux环境下的一款程序调试工具，用来监察一个应用程序所使用的系统调用及它所接收的系统信息。 可谓是 linux 下的调试利器，不仅可以用来找程序错误，系统为什么挂死了，命令为什么报错，还可以用来查找哪些程序占用系统资源。 命令实例 比如，但网站服务器负载过大，网站数量又多，不知是那个网站占用太多资源，这时strace派上用场了。 第一步，查
JVM 内存泄漏怎么排查
07-23
### JVM 内存泄漏排查方法与工具 JVM 内存泄漏是指程序在运行过程中，对象不再被使用但无法被垃圾回收器（GC）回收，导致内存资源被无效占用，最终可能引发 `OutOfMemoryError`。排查此类问题需要结合理论分析与工具辅助，以下是一些常用的排查方法和工具。 #### 1. 常见内存泄漏场景 - **集合类未释放引用**：如 `HashMap`、`ArrayList` 等集合类中保存了对象引用，使用完后未清空，导致 GC 无法回收。 - **监听器和回调未注销**：如事件监听器、定时任务等未及时取消注册。 - **缓存未清理**：长时间未访问的缓存对象未被清除，持续占用内存。 - **线程未终止**：线程未正确关闭，线程局部变量（`ThreadLocal`）未清理，导致内存泄漏。 #### 2. 内存查看与分析命令 JDK 提供了多种命令行工具用于查看 JVM 内存状态和堆转储信息： - **jstat**：用于监控 JVM 堆内存和垃圾回收情况。例如： ```bash jstat -gc <pid> 1000 ``` 该命令每秒输出一次 GC 统计信息，帮助判断内存回收是否正常进行。 - **jmap**：生成堆转储快照（heap dump），用于后续分析内存使用情况。例如： ```bash jmap -dump:live,format=b,file=heapdump.hprof <pid> ``` - **jcmd**：用于执行 JVM 命令，包括查看 Native Memory Tracking（NMT）信息。例如： ```bash jcmd <pid> VM.native_memory summary ``` 该命令可查看 JVM 原生内存使用情况，帮助识别非堆内存泄漏[^4]。 #### 3. 图形化分析工具 - **VisualVM**：集成了多种监控和分析功能，支持查看堆内存、线程状态、GC 情况，并可加载 heap dump 进行对象分析。 - **Eclipse MAT（Memory Analyzer）**：专门用于分析 heap dump 文件，可识别内存泄漏的潜在对象，提供支配树（Dominator Tree）和直方图（Histogram）视图。 - **JProfiler**：商业工具，提供更强大的性能分析功能，支持实时监控内存分配、GC 情况，并可进行线程和锁分析。 #### 4. 分析步骤示例 1. **监控内存使用情况**：使用 `jstat` 或 VisualVM 监控堆内存和 GC 情况，判断是否存在频繁 Full GC。 2. **生成堆转储文件**：使用 `jmap` 生成 heap dump。 3. **加载并分析 heap dump**：使用 Eclipse MAT 或 VisualVM 加载 dump 文件，查找内存占用最高的类及其引用链。 4. **定位泄漏点**：通过支配树或直方图视图，找到未被释放的对象及其持有者，分析引用关系，判断是否为内存泄漏。 #### 5. 预防措施 - 使用弱引用（`WeakHashMap`）管理缓存或监听器。 - 在对象使用完成后显式置 `null`，帮助 GC 回收。 - 定期进行内存分析，结合监控工具（如 Prometheus + Grafana）进行长期观察。 - 设置合理的 JVM 启动参数，如 `-Xmx` 和 `-Xms`，避免内存过小。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值