记录一次内存泄漏的排查过程

问题描述

工作中发现,在对A服务的B接口压测之后,发现内存占用一直降不下来,怀疑有内存泄漏,需要进一步排查

排查思路

通过咨询chatgpt ,确定思路:

1,使用内存分析工具(如Eclipse Memory Analyzer、VisualVM、MAT等)来分析堆转储快照(heap dump),查找潜在的内存泄漏问题

2,检查GC日志中的频率、持续时间和回收的内存量等信息,可以确定是否存在内存泄漏或频繁的全局垃圾回收事件

3,代码审查:检查Java服务的代码,特别关注内存管理方面的实现。查找是否有未关闭的资源(如数据库连接、文件流等)、缓存未正确释放、对象生命周期管理不当等问题。

内存分析

使用开源的 Eclipse Memory Analyzer 工具进行分析

1. 导出 UAT 环境A服务的内存快照

(经过确认,UAT和生产有相同的问题,尽可能不动生产环境)

2. 将转储文件导入到分析工具

3. 查看结果

3.1 先看分析工具提供的内存泄漏检测报告

3.2 理解问题

如图所示,报告说有 7295 个org.apache.http.impl.conn.PoolingHttpClientConnectionManager 对象占据了 186245928 字节,约等于 52.46% 的内存空间,并且被一个 java.util.concurrent.ConcurrentHashMap$Node[] 对象引用,简单理解,就是一个ConcurrentHashMap里面有7295个对象占据了大量内存,疑似内存泄漏

3.3 获取更多线索

一个 PoolingHttpClientConnectionManager 还不够,为了获得更多线索,可以查看对象之间的引用关系,获取更多信息。

进入对象直方图,找到PoolingHttpClientConnectionManager的统计信息

通过查询 GC Roots 功能,查询引用这些对象的其他对象

分析可知:

有一个 software.amazon.awssdk.http.apache.internal.conn.IdleConnectionReaper$ReaperTask 对象引用了一个 java.util.concurrent.ConcurrentHashMap 对象,然后这个map里面有大量的 PoolingHttpClientConnectionManager 对象

4. 定位并解决问题

4.1 先找到对应的类

4.2 合理设置断点

发现 connectionManagers 只有两个地方在操作这个map,一个put,一个remove

put 和 remove 操作打上断点

4.3 调试

debug调用压测的接口,发现卡在put方法的断点了,并且根据方法调用栈显示,SdkDefaultClientBuilder 的 build 方法是源头,这个方法是用来创建 S3Client 的

继续执行代码,发现没卡在 remove 方法的断点上

到这里问题已经比较明显了:

每次调用该接口时,都会创建一次 S3Client,每次创建都会把一个新的 PoolingHttpClientConnectionManager 对象放到一个 map 里面,并且不会 remove,同时,我们继续研究代码发现

ReaperTask 是一个循环任务,该对象会一直引用这个connectionManagers,connectionManagers 又引用了大量的 PoolingHttpClientConnectionManager对象, 这会导致 connectionManagers 以及内部的 PoolingHttpClientConnectionManager对象 不会被 GC 回收(GC可达性分析:可达的对象不回收,不可达对象作为"垃圾"被回收)

4.4 修复问题

找到出问题的代码块时,发现编辑器已经给出了提示,S3client 没有被关闭

通过验证发现,调用S3client 的关闭方法确实会移除 connectionManagers 里面的PoolingHttpClientConnectionManager对象

也就意味着每次调用接口都会创建一个S3client,并且put一个PoolingHttpClientConnectionManager对象到一个map中,如果不关闭S3client,这个 PoolingHttpClientConnectionManager 就会造成内存泄漏

将原来的代码改成try-with-resource 语句就能解决问题

4.5 服务端验证

将最新代码发布到UAT环境,执行压测脚本,然后导出内存快照

可以观察到 PoolingHttpClientConnectionManager 对象的数量已经少了很多

同时这些对象中大部分都是被 Finalizer 引用的,这意味着这些对象很快会被回收掉

至此,说明该问题已经解决

总结

写代码需要规范,不熟悉的api需要参考文档,参考最佳实践。同时,多留意代码检查插件和编辑器的提示信息。

相关推荐
wuminyu5 小时前
专家视角看Java字节码加载与存储指令机制
java·linux·c语言·jvm·c++
小码哥_常5 小时前
Spring Boot:别再重复造轮子,这些内置功能香麻了
后端
皮皮林5516 小时前
OpenFeign 首次调用卡 3 秒?八年老开发扒透 5 个坑,实战优化到 100ms!
后端
callJJ6 小时前
Spring Data Redis 两种编程模型详解:同步 vs 响应式
java·spring boot·redis·python·spring
千寻girling7 小时前
《 Git 详细教程 》
前端·后端·面试
wbs_scy7 小时前
Linux线程同步与互斥(三):线程同步深度解析之POSIX 信号量与环形队列生产者消费者模型,从原理到源码彻底吃透
java·开发语言
0xDevNull8 小时前
Linux 中 Nginx 代理 Redis 的详细教程
redis·后端
GetcharZp8 小时前
告别 Nginx 手动配置!这款 Go 语言开发的云原生网关,才是容器化时代的真香神器!
后端
jinanwuhuaguo8 小时前
(第三十三篇)五月的文明奠基:OpenClaw 2026.5.2版本的文明级解读
android·java·开发语言·人工智能·github·拓扑学·openclaw
RuoyiOffice9 小时前
SpringBoot+Vue3 企业考勤如何处理法定假期?节假日方案、调休补班与工作日判断链路拆解
spring boot·后端·vue·anti-design-vue·ruoyioffice·假期·人力