618，核心服务OOM！

P0事故安排上了

原来以为内存溢出这种事情只会发生在书本上，没想到在我们生产环境发生了，而且是618，P0事故安排上了。先回顾一下内存溢出排查的基本思路，然后再来复盘一下内存溢出发生的原因

内存溢出排查

我们先来了解一下Java堆的组成机构。对于大多数应用来说，Java堆（Java Heap）是Java虚拟机锁管理的内存中最大的一块。Java堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存

「堆的结构如下」

「新生代老年代的具体划分比例如下」

「分代的主要作用就是为了更高效的管理内存」

内存泄漏和内存溢出是2个不同的概念

内存泄漏：对象已经不使用了，但是还占用着内存空间，没有被释放内存溢出：堆空间不够用了，通常表现为OutOfMemoryError，内存泄漏通常会导致内存溢出

使用Java VisualVM分析排查

「我们可以通过jdk自带的jvisualvm命令来分析堆的使用情况」

我们写一个程序，来演示内存不断增加的场景

代码语言：javascript复制

public class OomDemo {

    private static final int NUM = 1024;

    public static void main(String[] args) throws InterruptedException {
        List<byte[]> list = Lists.newArrayList();
        for (int i = 0; i < NUM; i  ) {
            TimeUnit.SECONDS.sleep(1);
            list.add(new byte[NUM * NUM]);
        }
    }
}

「命令行中执行jvisualvm即可弹出图形界面，我们可以连接到本机上的程序，也可以连接到远程机器，还可以分析生成快照文件等」。

可以清晰的看到堆空间在不断上涨，用抽样器分析一下内存不断上涨的源头在哪里？

「好家伙，byte数组居然占用了这么多内存」

如果此时你还看不出程序哪里有问题，到监视这个Tab点击堆Dump这个按钮，会生成一个堆的快照，然后分析这个dump文件即可

byte数组实例很少，但是占用内存很多，再看一下具体的引用

可以看到在ArrayList中。

最后推荐一个插件Visual GC，可以清晰的看到堆的使用情况以垃圾收集信息。

点击工具选中插件即可

当然你可以通过jmap命令生成heapdump文件，然后用其他工具分析

代码语言：javascript复制

jmap -dump:file=文件名字 进程id

使用Eclipse Memory Analyzer分析

Java VisualVM只提供了一些基本的功能，堆中各种对象的大小和实例数。以上面的例子为例，你只能排查到ArrayList占用了大量的内存，这个ArrayList在哪，你也不知道

所以我们一般不使用Java VisualVM来分析，而是使用Eclipse Memory Analyzer来分析

Eclipse Memory Analyzer下载地址：https://www.eclipse.org/mat/downloads.php

还是上面的程序，我们启动时设置如下参数，让程序内存溢出时自动生成Dump文件

代码语言：javascript复制

-Xmx30m -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/peng

-Xmx30m：最大堆内存为30m -XX: HeapDumpOnOutOfMemoryError：当JVM发生OOM时，自动生成DUMP文件。-XX:HeapDumpPath：指定文件路径，例如：-XX:HeapDumpPath=${目录}/java_heapdump.hprof。如果不指定文件名，默认为：java_pid<pid>.hprof

生产环境一般都会配置堆溢出时自动生成DUMP文件