javaOOM该分析dump文件而不是看异常log日志原因

应用程序出现OOM异常,你是否仍然通过看日志的方式去排查问题(该方式定位解决问题是大概率的巧合而已)?正确的排查方案是进行dump文件分析,你知道为什么吗?

OOM异常--intsmaze

首先说一下,本人在开发中遇到的OOM异常基本也是通过看log日志去定位的(很多OOM异常是因为出现死循环或者查询返回的数据量多大,没有分页等等,通过异常日志我们确实能很快定位,但这不是正确的姿势。),只是碰巧刚好日志打印的异常栈信息就是对应的代码问题。 很多博客也说了,定位OOM异常通过分析dump日志,因此深表疑惑,为什么明明看log日志就能解决的非要去分析dump日志,网上也没有检索到满意的答案,问了身边的很多开发,也仅仅说dump进行性能分析,log日志进行异常排查。在我几度深思中,突然开窍,特此写下原因。

OOM异常会导致程序宕机,进程结束。

正确姿势dump文件分析--intsmaze

请看大屏幕:

public class OOMDump {

    static class OOMIntsmaze {
        public byte[] placeholder = new byte[64 * 1024];
    }

    public static void fillHeap(ArrayList<OOMIntsmaze> list, int num) throws Exception {

        for (int i = 0; i < num; i++) {
            list.add(new OOMIntsmaze());
            System.out.println(i);
        }
    }

    public static void main(String[] args) throws Exception {
        ArrayList<OOMIntsmaze> list = new ArrayList<OOMIntsmaze>();
        fillHeap(list,131);
        Thread.sleep(20000000);
    }
}

我们配置jvm参数如下 -Xmx10M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:// 当fillHeap(list,131)时,程序正常执行;当fillHeap(list,132)时,程序就会报OOM异常:

130
java.lang.OutOfMemoryError: Java heap space
Dumping heap to d://\java_pid10000.hprof ...
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at cn.intsmaze.dump.OOMDump$OOMIntsmaze.<init>(OOMDump.java:27)
    at cn.intsmaze.dump.OOMDump.fillHeap(OOMDump.java:34)
    at cn.intsmaze.dump.OOMDump.main(OOMDump.java:47)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
Heap dump file created [10195071 bytes in 0.017 secs]
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

通过异常日志我们可以看到,是因为代码 at cn.intsmaze.dump.OOMDump.fillHeap(OOMDump.java:34) list.add(new OOMIntsmaze()); 导致的问题,通过日志所见即所得,我立马解决了问题,为什么要看dump日志呢?我有病啊。

其实不然,骚年。假如main方法如下,执行

    public static void main(String[] args) throws Exception {
        ArrayList<OOMIntsmaze> list = new ArrayList<OOMIntsmaze>();
        fillHeap(list,131);
        Map<String,OOMIntsmaze> map=new HashMap<String,OOMIntsmaze>();
        map.put("LIUYANG",new OOMIntsmaze());
        map.put("intsmaze",new OOMIntsmaze());
        Thread.sleep(20000000);
    }

这个时候我们通过异常日志发现是因为map.put("LIUYANG",new OOMIntsmaze());导致的,找到代码发现,map里面才插入了一条数据,没有出现死循环,怎么会导致OOM异常了,真是活久见了。

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at cn.intsmaze.dump.OOMDump$OOMIntsmaze.<init>(OOMDump.java:27)
    at cn.intsmaze.dump.OOMDump.main(OOMDump.java:49)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

设置10M我们可以发现list添加132各个元素时会发生OOM,这个时候我们向list添加131个元素,然后执行map添加,发现map添加一个元素就报错。此时的oom异常日志定位的是map添加元素导致的。 但是真实情况不是的,因为看代码也会发现map只添加了2个元素,怎么会是他造成的。map的添加只是刚好此时jvm内存达到容量上限了。 所以要找到根本问题,是需要通过dump文件分析OOM时,各个对象的容量状态。 而且实际情况中,map.put()的代码并不会向上面示例一样和list.add()代码放在一块,而是位于不同的包下,不同的业务流程中。这个时候看log日志去定位基本不可能了。 但是为什么大家出行OOM异常还是通过看log日志而且定位的位置是正确的。只是因为向list.add这种循环中,一直在执行,基本大概率是他触发的。

正确的姿势--intsmaze

所以为了防患于未然,程序猿在开发的时候,一定要配置jvm启动参数HeapDumpOnOutOfMemoryError。 参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析

dump丢失打印--intsmaze

有些时候,我们的应用程序宕机,既不会打印log日常信息,dump文件也不会生成,这个时候基本就是linux系统杀掉了我们的应用程序进程。

查看/var/log/messages文件

messages 日志是核心系统日志文件。它包含了系统启动时的引导消息,以及系统运行时的其他状态消息。在messages里会出现以下信息

out of memory:kill process 8398(java) score 699 or sacrifice child
killed process 8398,UID 505,(java) total-vm:2572232kB,anno-rss:1431292kB,file-rss:908kB

oom killer是linux系统的一个保护进程,当linux系统所剩的内存空间不足以满足系统正常运行时,会触发。oomkiller执行时,会找出系统所有线程的score值最高的那个pid,然后干掉。 这里我们可以看到,JAVA进程的确是被LINUX的oom killer干掉了。

我们的应用程序和日志都只能记录JVM内发生的内存溢出。如果JVM设置的堆大小超出了操作系统允许的内存大小,那么操作系统会直接杀死进程,这种情况JVM就无法记录本次操作。 Linux对于每个进程有一个OOM评分,这个评分在/proc/pid/oom_score文件中。例如/proc/8398/oom_score,如果不希望杀死这个进程,就将oom_adj内容改为-17。 更多关于linux的oom killer机制请自行百度检索。

最正确的姿势:首先调整JVM的heap大小,使得JVM的OOM优先于操作系统的OOM出现,接着设置运行参数,在发生OOM的时候输出heapdump文件。

哪些内存溢出会产生dump文件--intsmaze

请上公交车:JVM各种内存溢出是否产生dump https://blog.csdn.net/stevendbaguo/article/details/51366181

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏专注于主流技术和业务

axios2教程

axios 是一个基于 promise 的 HTTP 库,用于浏览器和node.js的http客户端,支持拦截请求和响应,自动转换 JSON 数据, 客户端支持...

8872
来自专栏程序手艺人

nghttp2 - HTTP/2 C Library 简明教程(一)

43912
来自专栏安富莱嵌入式技术分享

【RL-TCPnet网络教程】第28章 RL-TCPnet之DNS应用

本章节为大家讲解RL-TCPnet的DNS应用,学习本章节前,务必要优先学习第27章的DNS基础知识。有了这些基础知识之后,再搞本章节会有事半功倍的效果。

1065
来自专栏生信宝典

Linux服务器数据定期同步和备份方式

数据安全是做数据分析的人需要关注的一大问题。对于我们分析的关键数据、使用的关键脚本都需要定期备份。 scp 最简单的备份方式,就是使用cp (本地硬盘)或scp...

3899
来自专栏JetpropelledSnake

Python入门之logging日志模块以及多进程日志

本篇文章主要对 python logging 的介绍加深理解。更主要是 讨论在多进程环境下如何使用logging 来输出日志, 如何安全地切分日志文件。 1. ...

9867
来自专栏Elson's web

webpack4实用配置指南-上手篇

算起来已经有3到4个项目的webpack构建打包经历。然而每次搭建起来还是有新手既视感,比较捉急。工具用法的东西,好记性不如烂笔头,有必要系统梳理下webpac...

1.9K14
来自专栏知识分享

二,ESP8266 GPIO和SPI和定时器和串口(基于Lua脚本语言)

我们写lua用这个软件 http://pan.baidu.com/s/1kVN09cr 密码:pfv7 ? 如果点击的时候提示安装,,安装就行,,如果没有提示呢...

3074
来自专栏Jackson0714

不惧面试:HTTP协议(1) - 基础扫盲

3007
来自专栏SDNLAB

Nova虚拟机启动

本来这一节打算写Neutron中各个OVS上的流表逻辑的,突然想起来之前学习Neutron时深入研究过的一个问题——虚拟机接入OVS是如何实现的?既然流表是为了...

3945
来自专栏cloudskyme

C++动态链接库

动态链接库 动态链接库英文为DLL,是Dynamic Link Library 的缩写形式,DLL 是一个包含可由多个程序同时使用的代码和数据的库,DLL不是可...

4855

扫码关注云+社区

领取腾讯云代金券