记一次OOM堆栈信息泄漏分析过程
来源:互联网 发布:淘宝子账号要下载什么 编辑:程序博客网 时间:2024/05/22 01:45
1、用户反映生产订单下不来,马上打开服务器查看gc日志(前提是已经先排除了业务逻辑问题)
tomcat配置:
JAVA_OPTS=”$JAVA_OPTS -server -Xms4096m -Xmx4096m -Xss1024k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDetails -Xloggc:/usr/local/gc.log -XX:+PrintGCTimeStamps”
查看gc日志:
tail -f gc.log
发现gc日志一直在作fullGc,频率在1分钟内,GC时间长达9秒,而且fullGC并没有释放出内存,因此断定服务器出问题了,查看了CPU,内存的使用率,
top -H -p pid
也发现CPU高达300%,平常是60%
为了恢复生产,此时服务器必须马上重启,但是为了查找出原因,先把堆栈信息打出来才能方便后续查找原因,保护现场很重要:
第一步:栈信息
jstack pid > jst.txt
第二步:堆信息
jmap -dump:format=b,file=jdump.bin pid
-dump: 生成Java堆转储快照
-heap:显示Java堆详细信息
-histo:显示堆中对象统计信息
然后恢复生产环境,重启,因为以前也是发生过一次这种情况,说明导致服务器挂掉的原因发生概率较小,是偶然性因素
2、分析堆栈信息:Memory Analyzer tools:AMT
分析工具采用AMT,可以在Eclipse安装也可以独立安装,打开工具,默认生成Leak Suspect report,内存泄漏报告
首先:overview,看到的是内存占用较大的对象
然后查看是由哪个线程产生的对象
点击 See stacktrace,可以看见栈信息
此时可以看到自己写的代码部分
最后点击details,查看这个GC不掉的内存对象是谁?
我们找到了线程,找到了内存对象,看来这个问题比较简单的被我们找到了问题症结点
3、回过去查找代码,此时我们至少能将问题锁定在某个具体的方法上,再去查找服务器生产业务日志,终于找到,原来是一个循环代码中,跳出条件有个隐蔽的边界条件,会导致死循环,生产服务器的日志也是一直在死循环,代码也能解释
OK,完成
- 记一次OOM堆栈信息泄漏分析过程
- 一次OOM分析的过程
- 一次内存泄漏导致的OOM实例分析和解决
- 一次OOM排查过程
- 记一次通过Memory Analyzer分析内存泄漏的解决过程
- 一次内存泄漏问题定位过程与分析
- 记一次线上Groovy导致的OOM的问题解决过程
- 记一次OOM异常
- 记一次 OOM经验
- 记一次OOM总结
- [OOM]记一次线上OOM的问题
- Android 内存泄漏和OOM分析(一)
- Android 内存泄漏和OOM分析(二)
- 一次堆栈溢出的分析
- 一次堆栈溢出的分析
- Java堆栈信息分析
- 一次线上OOM过程的排查
- 一次函数调用过程对堆栈的逆向分析之旅
- py2vspy3
- JavaScript中new String()和直接""有什么区别?
- Leetcode#53 Maximum Subarray
- 个推(App端)
- 由哈希表所联想到的相关问题
- 记一次OOM堆栈信息泄漏分析过程
- JSP九大内建对象
- 函数指针&指针函数&结构体调用函数
- 记一次上传文件的nginx配置
- npm淘宝镜像
- 500 OOPS: could not read chroot() list file:/etc/vsftpd/chroot_list
- week4 神经网络
- JavaWeb响应下载(包含工具类)
- Java反射机制详解