JVM 堆外内存泄漏

首先开启：

-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。

为了快速验证是否DirectByteBuffer导致内存泄露，可使用参数

-XX:MaxDirectMemorySize

限制DirectByteBuffer分配的堆外内存大小，如果堆外内存仍然大于MaxDirectMemorySize，可基本排除DirectByteBuffer导致的内存泄露。

DirectByteBuff通常被用于通信框架如netty中，不仅可以减少GC压力，而且避免IO操作时将对象从堆上拷贝到堆外。

用MemoryAnalyzer打开dump的堆，统计所有DirectByteBuffer的capacity之和，计算DirectByteBuffer申请的堆外内存大小。

然后用命令jdk/bin/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的地方。

这个链接不知道为啥打不开：https://coldwalker.com/2018/12/troubleshooter_directbytebuffer_memory_issue/

记一次Netty堆外内存泄漏的排查总结

https://www.jianshu.com/p/44d1a532a038

Netty堆外内存泄露排查盛宴

https://tech.meituan.com/2018/10/18/netty-direct-memory-screening.html

Spring Boot引起的“堆外内存泄漏”排查及经验总结

https://tech.meituan.com/2019/01/03/spring-boot-native-memory-leak.html