使用Java工具解决生产故障（二）- 内存泄漏及OOM异常分析

1.工具准备

本章节除了用到上一章提到的jcmd之外，还会使用到VisualVM工具。此工具在JDK安装目录\bin下，文件名为jvisualvm。你也可以在
http://visualvm.github.io/download.html
下载到最新的版本。

VisualVM使用各种技术（包括jvmstat，JMX，Serviceability Agent（SA）和Attach API）来进行故障定位。至少需要具备JDK的版本1.4+。

我使用的是上述链接中下载的jvisualvm1.4版本。
官方中文教程：
http://visualvm.github.io/documentation.html

建议：将etc下visualvm配置文件中的-Xmx最大堆内存的大小调大一些，否则在加载dump文件过程中很容易发生oom。

2.故障模拟

今天我们要模拟的故障是一种常见的内存泄漏。源代码如下：

package com.brianxia.error;

import java.util.HashMap;
import java.util.Map;
import java.util.Random;

public class MemoryLeak {

    //存储内存泄漏的数据
    public static Map<String, String> data = new HashMap<>();

    public static void addData(String key) {

        data.put(key, "");
    }

    public static void deleteData(String key) {

        data.remove(key, "");
    }

    public static void throwEx() throws Exception {
        throw new RuntimeException("leak");

    }

    //内存泄漏代码，添加数据之后抛出异常，从而无法执行删除数据的代码，造成内存泄漏的现象
    public static void leak() throws Exception {
        Random random = new Random();
        String key = String.valueOf(random.nextInt());
        addData(key);

        throwEx();

        deleteData(key);

    }

    public static void main(String[] args) {

        while (true) {
            try {
                leak();
                Thread.sleep(100);
            } catch (Exception e) {
                if (!(e instanceof RuntimeException))
                    e.printStackTrace();
            }
        }

    }

}

这是一段最简单的内存泄漏代码，本意是在leak函数中，通过add和delete，回收掉添加到hashmap中的数据，但是在执行add和delete的中间发生了异常，所以代码路经直接会跑到main函数中的异常捕获中，从而hashmap中的数据永远不会被回收了。

3.故障分析

关于如何识别是否有内存泄漏，不在本文讨论范畴内，后续会更新相应的文章。首先我们用上一次提到的jcmd来生成dump文件。

g>jcmd 6172 GC.heap_dump d:\dump_leak
6172:
Heap dump file created

打开visualvm，选择load刚才生成的文件。

Image 1.png

选择Objects，查看下目前JVM中的对象状态。

Image 2.png

Image 3.png

从上图中可以看到，我们的代码产生了非常多的对象，其中主要是char[]、Hashmap的Node、String。那么这个时候我们就需要根据我们的项目具体进行分析了，首先我们的代码中存在HashMap， key的数据类型是String，而String的底层实现又是char[]，这三个的数量可以看到基本一致。
从上面的信息我们可以推断出，我们代码实现中存在内存泄漏（当然也有可能是未进行GC，因为是演示用例，我们可以在visualvm上手动执行GC）。

image.png

点开详细的Object列表，可以看到相关的reference信息。从上图可以知道，我们的Hashmap Node主要是在MemoryLeak类中的static变量data中被引用到，无法得到释放。
之后就需要各位小伙伴去查验整个变量的生命周期，确认为何资源没有被回收。

4.总结

以上就是基本的生产下处理问题的流程，需要注意的是，生产上可以打开

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=${目录}

这两个参数，让发生OOM的时候自动生成dump用于后续分析。当然最好的情况是在测试环境中能够通过分析heap信息发现问题，而不是到生产上再去解决。
下一章中，我会讲解JVM内存的基本原理及如何分析内存状态。

作者：BrianXia
转载请注明 //www.greatytc.com/p/065d12dd3e44

最后编辑于：2018.02.13 23:18:40