JAVA的垃圾回收机制给了程序猿便利，我们可以不需要显式释放资源。但想高枕无忧却是不能，OOM像个隐藏在暗处的幽(hua)灵(nong)，威胁着可怜、弱小又漂亮的程序猿。
一般来说，一个健康的程序，它是不应该出现OOM的。内存里的对象从生到死，井然有序。但由于一些人为的失误，往往会让一些对象逃过GC的制裁，跳出GC外，不在垃圾中。这个时候，内存泄漏就发生了。
内存泄露，是指程序在申请内存并且用完这块内存后（对象不再需要了），没有释放已申请的内存空间。少数偶然的内存泄漏，虽然不太好，但问题不大，我们也不至于对那点内存抠抠搜搜的。但如果是内存不断泄漏，直到新的对象没有足够的空间生成，就会导致OOM。
什么时候可能内存泄漏
抛出OOM异常
当程序抛出OutOfMemoryError，如果你自认不是太抠，给了这个程序足够的空间，那么可以怀疑有内存泄漏
内存持续上升
一个健康的程序应该有平稳的新陈代谢，内存占用应该维持在一定范围。但如果内存持续飙升，甚至到达了一个危险的值，那么可以怀疑有内存泄漏。
查看GC情况
首先获取到应用的pid，可以使用java的jps命令，或者ps -ef|grep 应用名关键词
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
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];
}
}
|
1
2
3
4
5
6
7
|
➜ ~ jps
11617 Launcher
11618 AcuptMain
1353 RemoteMavenServer
1322
11627 Jps
|
1
2
3
|
➜ ~ ps -ef|grep acupt
501 11618 1322 0 10:44下午 ?? 0:00.39 /Library/Java/JavaVirtualMachines...
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| # 查看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）
查看存活对象
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
➜ ~ 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;
|
根据存活对象的不正常增长情况，分析程序中哪些地方用到了这种对象，也可以大致推断出可能的内存泄漏处。
