JVM内存泄漏

内存泄露表现

调大堆内存、重启应用

        发生内存泄漏后，进程的可用内存会慢慢变少，最后的结果就是抛出OOM错误。发生OOM错误后可能会想到是内存不够大，于是把-Xmx参数调大，然后重启应用。这么做的结果就是，过了一段时间后，OOM依然会出现。最后无法再调大最大堆内存了，结果就是只能每隔一段时间重启一下应用。

内存泄露将导致GC频繁、请求响应慢

因为频繁发生的GC会暂停其它所有线程（Stop The World）造成的，所以内存泄漏的另一个可能的表现是请求的响应时间变长了。

内存泄露定位分析

JVM参数设置如下：

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=heap.bin

意思是发生OOM时把堆内存信息dump出来。运行程序直至异常，于是得到heap.dump文件

然后File->Open Heap Dump... ，然后选择刚才dump出来的文件，选择Leak Suspects.

        生产环境上的应用，内存往往会设置得很大，这样发生OOM再把内存快照dump出来的文件就会很大，可能大到在本地的电脑中已经无法分析了（因为内存不足够打开这个dump文件）。打开一个大的txt试试这种卡顿或者死机...

方法二：

（1）用jps定位到进程号 jps -l 找到进程号

（2）用jstat分析gc活动情况 jstat是一个统计java进程内存使用情况和gc活动的工具

jstat -gcutil -t -h8 24836 1000
        Timestamp   S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
           29.1  32.81   0.00  23.48  85.92  92.84  84.13     14    0.339     0    0.000    0.339
           30.1  32.81   0.00  78.12  85.92  92.84  84.13     14    0.339     0    0.000    0.339
           31.1   0.00   0.00  22.70  91.74  92.72  83.71     15    0.389     1    0.233    0.622

（3）用jmap工具dump出内存快照

jmap可以把指定java进程的内存快照dump出来，效果和第一种处理办法一样，不同的是它不用等OOM就可以做到，而且dump出来的快照也会小很多。

jmap -dump:live,format=b,file=heap.bin 24836 然后利用工具分析内存快照即可。