Java内存泄漏原因

前言

有些人傻傻分不清内存泄漏和内存溢出的区别，这里简单做个科普

• 内存溢出：就是内存不够用了，对象需要的内存大小大于你分配的堆大小，内存溢出最常见的错误就是OutOfMemoryError，简称OOM；
• 内存泄漏：对象用完之后没被垃圾回收器（GC）回收，既然没被回收，那么这个对象就会一直占用着内存空间，这就是内存泄漏。内存泄漏的最终结果就是会导致内存溢出。因为对象一直占用，久而久之，一直叠加到超过最大堆内存时，就会导致OOM。

本次分析内存泄漏的工具主要有2个，一个是arthas，另一个是jdk自带的工具jmap，关于这2个工具的用法，可以参考我之前写的2篇文章：

• arthas ： Arthas使用教程 阿里巴巴开源项目、史上最强java线上诊断工具
• jmap： 原来jdk自带了这么好玩的工具 ＞ jmap 使用教程
  

模拟内存泄漏

下列的java代码是一个模拟线上的内存泄漏的代码，这段代码的业务逻辑是从数据库中读取信用数据，套用模型，并把结果进行记录和传输；

package com.gc;
import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**

• 从数据库中读取信用数据，套用模型，并把结果进行记录和传输
• 启动时加入以下参数 ： -Xms200M -Xmx200M -XX:+UseParallelGC -XX:+PrintGC -XX:+HeapDumpOnOutOfMemoryError
• 发现启动后会频繁GC，最后导致OOM（OutOfMemoryError）
  */

    <span class="token keyword">for</span> <span class="token punctuation">(</span><span class="token keyword">int</span> i <span class="token operator">&#61;</span> <span class="token number">0</span><span class="token punctuation">;</span> i <span class="token operator">&lt;</span> <span class="token number">100</span><span class="token punctuation">;</span> i<span class="token operator">&#43;&#43;</span><span class="token punctuation">)</span> <span class="token punctuation">{<!-- --></span>
        CardInfo ci <span class="token operator">&#61;</span> <span class="token keyword">new</span> <span class="token class-name">CardInfo</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
        taskList<span class="token punctuation">.</span><span class="token function">add</span><span class="token punctuation">(</span>ci<span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>

    <span class="token keyword">return</span> taskList<span class="token punctuation">;</span>
<span class="token punctuation">}</span>

}

启动

启动时加入参数-Xms200M -Xmx200M -XX:+UseParallelGC -XX:+PrintGC -XX:+HeapDumpOnOutOfMemoryError，这段代码运行后，老年代的内存占用会慢慢升高，待内存占用到达顶峰时，会频繁Full GC（回收老年代垃圾），直到撑爆内存，最后会导致OOM异常：Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: GC overhead limit exceeded；也就是内存溢出；

运行监控

运行一段时间后，可以看到一直不停地full GC，并且有些线程的内存已经溢出报出OOM错误；

解决方案：使用arthas

在用arthas 的dashboard命令看一下内存使用情况，这一看，我的天，老年代的内存已经使用了98.64%，并且已经进行了3914次的GC，也就是说Full GC进行了3914次清理都没清掉那些垃圾；

到这时候我们就已经确定发现了内存泄漏，接下来的工作就是要找到是那些顽固的对象没被清理调，然后在做出相应的调整；

首先要分析堆内存有哪些对象，这里使用到一个arthas的工具：heapdump，这个命令类似jdk的jmap，使用arthas导出堆转储文件命令；

[arthas@28747]$ heapdump --live /Users/mac/Downloads/dump.hprof
Dumping heap to /Users/mac/Downloads/dump.hprof ...
Heap dump file created

导出后是一个二进制文件，这个文件直接打开看到的是乱码的，所以我们需要借助一些工具，这边有2个选择，用jhat 和 jvisualVM，因为jhat用的不多，所以我们用大家常用的jvisualVM.

使用jvisual VM加载堆转储文件dump.hprof后如下图：

由此结果可以看到，Date对象和Bigdecimal对象一直无法回收，而每一个定时任务就会创建一个Date对象和Bigdecimal对象，到现在为止已经有55万个了，因为只增不减，撑爆内存是迟早的事。

解决方案二：使用jmap

先使用jps命令找到正在运行的java进程id

macdeMacBook-Pro:Downloads mac$ jps
24240 App
29410 Launcher
29411 T15_FullGC_Problem01
2851 
29414 Jps
29031 Main

我们运行的类为T15_FullGC_Problem01，对应的进程id为29411，记住这个进程id；

接着用jmap命令查看这个进程id，看看内存占用排行前十的对象有哪些：

jmap -histo:live 29411| head -10

• -histo:live ：表示只查看存活的对象
• head - 10 ：这是linux自带的命令，表示查看头部前十行内容；

运行后，结果和上面的jvisual分析结果差不多，Date对象和Bigdecimal对象都是在CardInfo方法里面的。所以排行最高的就是这三个；

macdeMacBook-Pro:Downloads mac$ jmap -histo:live 29411| head -10

[Ljava.util.concurrent.RunnableScheduledFuture;

为什么Date和Bigdecimal对象没被回收

是因为modelFit()方法出现了问题，

    private static void modelFit(){
        List<CardInfo> taskList = getAllCardInfo();
        taskList.forEach(info -> {
            // do something
            executor.scheduleWithFixedDelay(() -> {
                //do sth with info
                info.m();
            }, 2, 3, TimeUnit.SECONDS);
        });
    }

仔细看这个方法内的代码，关于这段代码可以有2种解释，

1、taskList链接着info对象

info是taskList中的元素，每个info元素都taskList这个对象所引用着，每次定时任务执行完后，线程内的对象都会被垃圾回收器清理掉，但是info这个对象不属于定时任务线程内的对象，所以没被清理掉；按理说taskList内的所有对象都遍历完了之后，应该会将taskList给清除掉，但是taskList还有个别元素在线程中，他们之间的引用还在，既然有引用，也就自然不会被清理；引用关系如下图

2、线程引用这info对象

info是taskList中的元素，每个info元素都taskList这个对象所引用着，这个定时任务executor.scheduleWithFixedDelay(() -> { }); 花括号的内容其实是在另一个域里面了，虽然info.m()这个方法已经执行完了，但是执行完后线程并没有被回收，因为线程的核心线程数和最大线程数都设置为50，所以线程执行完后一直在那挂着，既然线程还没回收，线程中GC Roots对info对象的引用就一直在，既然引用还在，垃圾回收器就不会回收被引用的对象；引用关系如下图

解决方案

要解决这个问题，就得解决引用的问题，让对象引用随着线程的执行完毕而清理掉，所以只需要修改modelFit()方法为以下代码即可解决问题。以下这段代码，taskList 在线程内执行，一旦线程执行完后taskList也会随着线程一起被回收掉，另外taskList内的所有CardInfo也会被回收，紧接着Date和Bigdecimal对象就没有引用了，也会被垃圾回收器回收掉，到这里也就解决内存泄漏问题。

  private static void modelFit(){
       executor.scheduleWithFixedDelay(() -> {
           List<CardInfo> taskList = getAllCardInfo();
           taskList.forEach(info -> {
               //do sth with info
               info.m();