面试杂谈 - 内存泄漏如何排查

JAVA的垃圾回收机制给了程序猿便利，我们可以不需要显式释放资源。但想高枕无忧却是不能，OOM像个隐藏在暗处的幽(hua)灵(nong)，威胁着可怜、弱小又漂亮的程序猿。

一般来说，一个健康的程序，它是不应该出现OOM的。内存里的对象从生到死，井然有序。但由于一些人为的失误，往往会让一些对象逃过GC的制裁，跳出GC外，不在垃圾中。这个时候，内存泄漏就发生了。

内存泄露，是指程序在申请内存并且用完这块内存后（对象不再需要了），没有释放已申请的内存空间。少数偶然的内存泄漏，虽然不太好，但问题不大，我们也不至于对那点内存抠抠搜搜的。但如果是内存不断泄漏，直到新的对象没有足够的空间生成，就会导致OOM。

什么时候可能内存泄漏

抛出OOM异常

当程序抛出OutOfMemoryError，如果你自认不是太抠，给了这个程序足够的空间，那么可以怀疑有内存泄漏

内存持续上升

一个健康的程序应该有平稳的新陈代谢，内存占用应该维持在一定范围。但如果内存持续飙升，甚至到达了一个危险的值，那么可以怀疑有内存泄漏。

查看GC情况

首先获取到应用的pid，可以使用java的jps命令，或者ps -ef|grep 应用名关键词

/**	
 * 启动个应用，持续造对象	
 */	
public class AcuptMain {	
    public static void main(String[] args) throws InterruptedException {	
        List<Liangzai> liangzais = new ArrayList<>();	
        while (true) {	
            liangzais.add(new Liangzai());	
            Thread.sleep(1000);	
        }	
    }	
    private static class Liangzai {	
        byte[] body = new byte[1024 * 1024];	
    }	
}

// 执行命令jps查看java进程	
➜  ~ jps	
11617 Launcher	
11618 AcuptMain	
1353 RemoteMavenServer	
1322 	
11627 Jps

// 根据关键词查看，进程id为 11618 ，和jps查到的一致	
➜  ~ ps -ef|grep acupt	
  501 11618  1322   0 10:44下午 ??         0:00.39 /Library/Java/JavaVirtualMachines...

# 查看gc总体情况，各个区的使用率变化，3秒更新一次	
➜  ~ jstat -gcutil 11618 3000 	
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT	
  0.00   0.00  56.20   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  60.89   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  65.58   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  70.26   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  74.95   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  79.64   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  84.33   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  89.01   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  93.70   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00   0.00  98.39   0.00  17.39  19.90      0    0.000     0    0.000    0.000	
  0.00  98.48   5.02  26.91  79.14  82.73      1    0.021     0    0.000    0.021	
  (以下略...)

可以看到Eden(E)持续造对象，并且满了之后，老年代(O)增加，E区腾空后继续造对象。（程序多执行一段时间，或者造对象速度提快点，最终会抛出OOM）

查看存活对象

// 查看存活对象，可以看到排名第一的是byte数组，而且多观察会会发现其数量也是一直在增加	
➜  ~ jmap -histo:live 11618	
 num     #instances         #bytes  class name	
----------------------------------------------	
   1:           644      103949616  [B	
   2:          4342         416736  [C	
   3:          4326         103824  java.lang.String	
   4:           721          82056  java.lang.Class	
   5:           746          49224  [Ljava.lang.Object;	
   6:           738          29520  java.util.LinkedHashMap$Entry	
   7:           609          19488  java.util.HashMap$Node	
   8:           303          19392  java.net.URL	
   9:           303          13560  [Ljava.lang.String;

根据存活对象的不正常增长情况，分析程序中哪些地方用到了这种对象，也可以大致推断出可能的内存泄漏处。

最佳阅读体验请点击下方 阅读原文

关注我，每天一杯82年的JAVA~ (长按下方二维码添加关注)