java 堆外内存泄露排查

参考：http://blog.itpub.net/70016482/viewspace-2908649/

一、原理

JDK提供绕过JVM直接在操作系统申请内存的接口，例如通过Unsafe类的allocateMemory、freeMemory直接分配、释放内存，内存对象的引用在堆上，但内存在堆外。排查此类内存泄露，首先开启-XX:NativeMemoryTracking=detail，然后jcmd pid VM.native_memory detail，打出内存分配信息，注意NativeMemoryTracking显示的内存不包含C++分配的内存。此处需要关注两个点，第一，Total行的committed数值是否等于进程占用的物理内存，如果不等，说明有C++等native code分配的内存，可参考Java调用C++组件 分析；第二，Native Memory Tracking的committed数值是否过大，如果过大，说明有Unsafe.allocateMemory分配了太多内存。

Unsafe.allocateMemory的使用场景有两个：第一，封装在DirectByteBuffer内；第二，业务直接使用Unsafe.allocateMemory。
DirectByteBuff通常被用于通信框架如netty中，不仅可以减少GC压力，而且避免IO操作时将对象从堆上拷贝到堆外。为了快速验证是否DirectByteBuffer导致内存泄露，可使用参数-XX:MaxDirectMemorySize限制DirectByteBuffer分配的堆外内存大小，如果堆外内存仍然大于MaxDirectMemorySize，可基本排除DirectByteBuffer导致的内存泄露。
分析DirectByteBuffer的内存首先可用Java Mission Control，绑定到进程，并查看DirectByteBuffer占的内存如2.24GB。此处也可直接用MemoryAnalyzer打开dump的堆，统计所有DirectByteBuffer的capacity之和，计算DirectByteBuffer申请的堆外内存大小。

然后用命令jmap -dump:live,format=b,file=heap.hprof {pid}，导出堆里所有活着的对象，并用MemoryAnalyzer打开dump的堆，分析所有的DirectByteBuffe：Merge shortest path to GC Roots ->with all references。
如果排除DirectByteBuffer，那就是应用程序直接用Unsafe类的allocateMemory分配的内存，例如Spark的off heap memory[1]。此时可排查代码所有Unsafe.allocateMemory的地方。

二、jemalloc使用

(1)下载
https://github.com/jemalloc/jemalloc/releases

(2)安装autoconf/automake
yum -y install autoconf automake

(3)安装jemalloc
./autogen.sh
./configure --enable-prof --enable-stats --enable-debug --enable-fill
make
make install

(4)
启动java脚本加上：
export LD_PRELOAD=/usr/local/lib/libjemalloc.so
export MALLOC_CONF=prof:true,lg_prof_interval:30

java -XX:+PreserveFramePointer -jar xxx.jar

(5)分析
jeprof --pdf /home/sail/jdk/bin/java *.heap > leak.pdf