评论

收藏

[Java] Java内存泄漏问题处理方法经验总结

编程语言 编程语言 发布于:2021-10-05 20:40 | 阅读数:458 | 评论:0

今天小编就为大家分享一篇关于Java内存泄漏问题处理方法经验总结,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
jvm问题,一般会有三种情况,目前遇到了两种,线程溢出和jvm不够用
1.线程溢出:unable to create new native thread
1.1问题描述:
系统在1月4号左右,突然发现会产生内存溢出问题,从日志上看,错误信息为:
DSC0000.png

导致系统不能使用,对外不能相应,但是观察gc等又处于正常情况,free 系统内存也正常。开始重启机器进行解决,真正的原因查找,过程比较坎坷,经历也比较痛苦。
1.2 问题解决

  • pstree查看线程数,发现系统线程数不断增长,直到oom。
命令:pstree  -p pid (对该项已经加了监控)

  • 线程过多导致的内存溢出,但是那里的线程过多呢?!
我们实现了threadfactory,通过它,给线程的加一个前缀。来标记线程所属。重现问题后,发现是task模块的taskscheduler的定时任务中,在方法内使用
executorservice taskexecutor = executors.newfixedthreadpool(nthreads);
taskexecutor.invokeall(tasks);
导致回收不及时,发生了问题。
2.内存溢出:老生代100%无法及时回收
2.1问题现象:
1月31号,中午中影突然所有的机器陆续出现不能工作的现象,日志中看不到oom错误,但是不能访问服务,或者访问非常的慢,观察jmap -heap发现老生代占用达到99%以上(不同版本jdk显示可能不一样。)
DSC0001.jpg

2.2 问题解决:
1、查看对内存使用情况,发现存在jvm堆内存不能释放的问题

  •    命令:jmap -heap pid   此命令有时候,会执行卡顿,不建议加监控
  •    语法:jmap - heap pid
2、进一步查看gc回收情况,发现fgc频率高,而且时间长,且回收不给力。

  • 命令:jstat -gcutil pid
  • 语法:jstat [ generaloption | outputoptions vmid [interval[s|ms] [count]] ]
3、查看jvm堆中具体有哪些对象。发现不正常,byte数组占用过大。实例达到1亿两千万,大小竟然有4g(3958m).同时,订单、hibernate引擎、mysql结果集类实例都很多。

  • 命令:jmap -histo
  • 语法:jmap -histo[:live] pid
4、查看mysql慢查询,发现确实找达到问题原因。
命令1:mysql数据库上查看,所有的。
命令2:查看当前慢查询
select * from information_schema.`processlist` ;(简化版:show processlist)
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对CodeAE代码之家的支持。如果你想了解更多相关内容请查看下面相关链接
原文链接:https://blog.csdn.net/only_jing1314/article/details/50986723

关注下面的标签,发现更多相似文章