博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
分享一次解决线上java应用导致JVM内存溢出(OOM)的问题
阅读量:4291 次
发布时间:2019-05-27

本文共 2290 字,大约阅读时间需要 7 分钟。

某个线上的应用运行几天后,总是出现卡死甚至出现OOM的情况。

注:文中图片可能与描述不符,仅作为演示!

通过Linux的top命令查看cpu占比

首先通过top命令查看,发现某个java程序占用了较高内存:

这里写图片描述

JDK的jps命令确定是哪个java程序

然后通过jps -l 与上面的PID列(2848)比较,确定是 picasso-java-v1.jar 这个java程序占用cpu过高:

这里写图片描述

通过ps 查看具体哪个JVM线程

当时想的是可能应用内某个线程导致死循环,使用如下命令查看2848进程的各个线程小号cpu时间

//ps -mp [线程号] -o THREAD,tid,timeps -mp 2848 -o THREAD,tid,time

下图 %CPU列 为 cpu的百分比,TID列线程id

这里写图片描述

找到消耗cpu最大的线程(当时线上出现时某个线程消耗cpu90%多),这里为了演示,所以取2858这个线程

通过jstack查看java中的具体线程栈信息

然后把上面线程id转化为16进制,在shell中使用printf "%x\n" tid即可,结果为b2a:

这里写图片描述

然后使用jstack输出这个线程的调用栈:

//jstack [进程id] | grep [线程的16进制id] -A行数jstack 2848 | grep b2a -A30

这里写图片描述

发现为GC线程,原来是jvm内存回收导致的cpu过高!

通过jstat查看内存回收情况

使用jstat -gcutil 线程数 间隔秒数 次数命令查看:

这里写图片描述

如图上面的FGC列Full GC次数为几百,而FGCT的Full GC秒数达到了几千,通过设置更多的监控次数观察,每次Full GC过后,O列的老年代还是99%,可见是内存不足导致的一直不停Full GC !

重启程序,使用-Xmx -Xms设置更大堆内存

通过重启程序,-Xmx2048m -Xms2048m 设置了更大的内存参数,缓解了问题!

问题重现,寻找其他原因,使用jmap生成堆转储文件

隔了几天后,问题重现,此时通过jmap 生成了镜像

jmap -dump:format=b,file=dumpfile.dat [pid]

生成的文件也是非常之大,达到2.1Gb!

柳暗花明,使用Eclipse Memory Analyzer分析出原因

把dump文件下载到本地,同时下载了Eclipse Memory Analyzer对dump文件进行分析。

在Eclipse Memory Analyzer中生成Leak Suspects报告:

这里写图片描述

发现是 PoolingHttpClientConnectionManager 这个类导致的。再点击上图中的Details,查看详细信息:

这里写图片描述

这下清晰了,是阿里的oss类库导致的,结合程序中的如下代码:

OSSClient ossClient = new OSSClient("","");PutObjectResult putObjectResult = ossClient.putObject("", "", "");

这个方法在程序中没有使用单例模式而且没有关闭,每调用一次就生成了一个PoolingHttpClientConnectionManager,而且是不可回收的。通过源码查看到IdleConnectionReaper.size()这个类会生成PoolingHttpClientConnectionManager的总数量。

验证猜测

使用 -Xms20m -Xmx20m 运行以下程序,发现size一直变大,最后导致OOM (java.lang.OutOfMemoryError)

for (int i = 0; i < 60000; i++) {
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret); ossClient.putObject("
", "test1234" + UUID.randomUUID(), new File("d:/file.txt")); System.out.println("size="+IdleConnectionReaper.size()); Thread.sleep(2);}

这里写图片描述

查看api,得知使用shutdown方法即可关闭OSSClient:

ossClient.shutdown();

再运行以下程序,size一直为0,一切正常:

for (int i = 0; i < 60000; i++) {
OSSClient ossClient = new OSSClient(endpoint, accessKeyId, accessKeySecret); ossClient.putObject("
", "test1234" + UUID.randomUUID(), new File("d:/file.txt")); ossClient.shutdown(); System.out.println("size="+IdleConnectionReaper.size()); Thread.sleep(2);}

至此,终于找到了导致cpu过高和OutOfMemoryError的真凶!

你可能感兴趣的文章
Java传参方式
查看>>
分布式补偿事务处理方案 / 分布式计算是如何控制事务的?
查看>>
分布式定时任务——elastic-job
查看>>
Spring中配置数据源的4种形式(含有如何在spring框架中解决多数据源的问题)
查看>>
分布式与集群有什么区别?
查看>>
linux安全-禁止密码登录及root登录
查看>>
Java 中的类为什么要实现序列化呢 / JAVA中序列化和反序列化中的静态成员问题
查看>>
redis集群搭建及注意事项
查看>>
分布式演变过程中之Session集群解决方案
查看>>
拥有这些Java这些技术可以涨工资吗?
查看>>
MySql学习之Join查询
查看>>
简单介绍线程池在并发编程中的使用
查看>>
redis如何防止并发?
查看>>
无备份情况下恢复MySQL误删的表,这样做再也不用怕误删了
查看>>
MySQL断电恢复的一点简单分析
查看>>
linux进程网络流量监控工具nethogs
查看>>
String.ValueOf和toString区别
查看>>
分布式补偿事务处理方案 / 分布式计算是如何控制事务的?
查看>>
SQL之常用小技巧第一篇
查看>>
java互联网架构-Mybatis缓存机制
查看>>