您现在的位置是:网站首页> 内容页

一次Java内存泄露处理手记

  • s7137辉煌中心下载
  • 2019-03-07
  • 28人已阅读
简介现象最近项目组从NET平台迁移到Java的Dubbo平台上,由于大家都是Java的生手,发生了蛮多的问题,以后一一记录。现在解决一个遇到的关于Java程序内存泄露的问题。特别说明Jav

现象

最近项目组从NET平台迁移到Java的Dubbo平台上,由于大家都是Java的生手,发生了蛮多的问题,以后一一记录。现在解决一个遇到的关于Java程序内存泄露的问题。

特别说明

Java萌新,理解不到位的地方请指点一二

版本

Java 1.8Dubbo 2.6.2Docker 18.0.2

系统环境

我们这里是Docker Swarm集群,三台机器组成,Dubbo服务随机部署到三台机器上。

问题重现

上线了一个Dubbo服务,这个服务涉及到数据库查询、排序分析、第三方接口调用。服务启动初始内存占用500MB左右,每检索一次,内存增加10MB到几十MB不等,而且不释放。持续增高,最高可以塞满整个服务器的内存。

检查问题

首先,由于我们是部署在Docker集群上的,所以得去容器内进行检查,刚上线,所以基础容器选择的是JDK版本,没有用JRE。因为JDK带有很多的调试工具。

查看生产环境并导出heap.hprof

首先看看容器的运行情况:

docker stats

这是后面调试的时候截的图,早期发现的时候,内存是4.8G。明显内存占用过多了。

因为宿主是没有任何java环境的,进容器内做内存分析。

docker exec -it 容器ID bash # 进入指定容器jmap -histo 1 | head -n 30 # 通过jmap工具查看

jmap的检查结果当时忘了截图了,这里就不留存了,百度能搜到了,就一笔带过。

现在导出heap.hprof文件,方便用MAT进行分析。

jmap -dump:format=b,file=heap.hprof 1

在docker容器内,PID 1 是服务进程,以上命令将会在当前目录生成heap.hprof文件,比较大,我的有1.2G。可以先压缩了,再传回来,进行分析。

使用MAT进行内存分析

独立版下载地址:MAT

打开从服务器下载回来的heap.hprof文件

点击Leak Suspects查看分析结果。

点击Details查看详情

上图可以看到,MAT分析结果表明,OcMapperFactory这个类有问题。

看看具体代码:

这个OcMapperFactory是用来封装orika的工具类,而orika是一个对象映射工具。由于这里没有用单例导致了内存的泄露。加上单例再看看:

重新测试,发现内存已经稳定。

, 1, 0, 9);

文章评论

Top