Java —— 内存泄露排查

最近发现服务器内存使用持续增长且增长速率大，怀疑是内存泄露导致的。
最终定位到是因为程序中存在线程池频繁创建但未销毁问题导致线程泄露，进而影响内存使用增长。
Tips：本文不记录排错过程，只记录可疑点及排错命令。

1. 套路

① 查看内存使用，对相隔一段时间的应用内存使用情况进行对比（top命令等），确认内存存在缓慢上升的情况
② jstat -gccapacity 【pid】查看JVM各部分内存使用增长是否符合top命令展示的应用内存使用增长。

如果符合，则使用MAT工具分析JVM堆栈情况，对比隔一段时间的堆栈对象增长情况，对于增加的对象进行内存泄露排查。
如不符合，这说明内存使用很大概率不是JVM堆栈导致的，可能程序中使用了堆外内存，堆外内存持续增长的这种情况不容易排查，最好开启JVM的NMA功能，使用jcmd命令对堆外内存进行分析。

2. 常见堆外泄露

JNI
gzip
线程栈
不良代码
ThreadLocal
NIO directbuffer泄漏

3. Linux内存相关概念

used区：应用实际占用内存，在+/-buffer计算方式下，used区=实际已用内存。而在Mem计算方式下，used=实际已有+Buffer+Cache （原因是Buffer和Cache在应用需要时会释放出应用所需大小供应用使用，但是不会全部释放）
free区：剩余空闲内存大小，未被应用used或被系统用于缓存（Cache/Buffer）的内存部分。
Cached区：这里的cache指Linux内存中的：Page cache。Page cache主要用来作为文件系统上的文件数据的缓存来用，尤其是针对当进程对文件有read／write操作的时候。如果你仔细想想的话，作为可以映射文件到内存的系统调用：mmap是不是很自然的也应该用到page cache？在当前的系统实现里，page cache也被作为其它文件类型的缓存设备来用，所以事实上page cache也负责了大部分的块设备文件的缓存工作。
Buffer区：Buffer cache则主要是设计用来在系统对块设备进行读写的时候，对块进行数据缓存的系统来使用。这意味着某些对块的操作会使用buffer cache进行缓存，比如我们在格式化文件系统的时候。
一般情况下两个缓存系统是一起配合使用的，比如当我们对一个文件进行写操作的时候，page cache的内容会被改变，而buffer cache则可以用来将page标记为不同的缓冲区，并记录是哪一个缓冲区被修改了。这样，内核在后续执行脏数据的回写（writeback）时，就不用将整个page写回，而只需要写回修改的部分即可。
total：内存总量

4. Linux查看内存相关命令

① free / free -m / free -g
相关参数说明

② cat /proc/meminfo

③ jstat -gccapacity 【pid】 —— 查看堆内存使用情况，包括元空间，老年代，年轻代

- NGCMN：新生代最小容量
- NGCMX：新生代最大容量
- NGC：当前新生代容量
- S0C：第一个幸存区大小
- S1C：第二个幸存区的大小
- EC：伊甸园区的大小
- OGCMN：老年代最小容量
- OGCMX：老年代最大容量
- OGC：当前老年代大小
- OC:当前老年代大小
- MCMN:最小元数据容量
- MCMX：最大元数据容量
- MC：当前元数据空间大小
- CCSMN：最小压缩类空间大小
- CCSMX：最大压缩类空间大小
- CCSC：当前压缩类空间大小
- YGC：年轻代gc次数
- FGC：老年代GC次数

④ top / top 【pid】/ top -Hp【pid】

⑤ ps -aux | grep 【pid】

⑥ jmap命令
jmap -heap 【pid】 —— 查看JVM呈现堆栈使用
jmap -histo 【pid】—— 查看堆中对象数量和大小
jmap -dump:format=b,file=heapdump pid：将内存使用的详细情况输出到文件

⑦ jcmd 【pid】 GC.heap_dump 【输出路径】 —— 查看GC堆栈，同jmap -dump | jcmd [pid] VM.native_memory

⑧ watch -n 1 ps v 【pid】—— 动态查看进程内存使用，每秒刷新

⑨ strace -f -e"brk,mmap,munmap" -p 【pid】追踪进程内存使用

⑩ pmap -x [pid] 与 diff pmap文件1 pmap文件2 -y -w

资料：
https://elasticsearch.cn/article/178
https://my.oschina.net/alchemystar/blog/1603817
https://www.cnblogs.com/xiaohanlin/p/12888396.html
https://blog.csdn.net/hellozhxy/article/details/95203462