堆外内存泄露揭秘

我不是女神ヾ 2022-02-05 07:39 848阅读 0赞

说实话jvm中堆外内存使用的场景非常多，它可降低GC、减少用户态与内核态切换及数据拷贝，已经成为性能提升的有效手段。比如通讯（[netty之对象池Recycler][netty_Recycler]），MQ（[本地IO之零拷贝之类][IO]）。一般使用堆外内存要重点关注手动释放or 自动释放，从笔者的过往经验中谈，堆外内存一旦发生泄漏，排查起来相对的困难。

你可能比较好奇，为何比较困难呢？笔者认为：涉及泄漏最终会定位到c的代码，一般都是内核级gcc之类（各种.so的包，比如：zjbmalloc.so）就无法再继续定位追踪了，再深挖对java程序员而言的确是心有余而力不足。

关于内存泄漏，其实笔者很早以前就分享过，这里归纳总结下：

**1.** [JVM故障诊断调优][JVM]

**2. **[Netty的资源泄露探测器：ResourceLeakDetector][Netty_ResourceLeakDetector]

**3.** 下面列举一些有用工具

> 查看内存分布
> 
> 项目中添加JVM参数`-XX:NativeMemoryTracking=detail，`然后重启项目，使用命令`jcmd pid VM.native_memory detail`查看到的内存分布，jcmd命令显示的内存包含堆内内存、Code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。

> 查看内存分布
> 
> 通过linux命令pmap，通过这些地址空间判断是否在jcmd命令中，如果不在可以确定是Native Code所引起。

> gperftools + strace + GDB + jstack
> 
> [gperftools][]原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc），可以用个观察Native Code内存使用情况
> 
> 项目启动时使用`strace -f -e"brk,mmap,munmap" -p pid`追踪向OS申请内存请求，找到可疑内存申请
> 
> `gdp -pid pid`进入GDB之后，然后使用命令`dump memory mem.bin startAddress endAddress`dump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用`strings mem.bin`查看dump的内容
> 
> 使用命令jstack pid去查看线程栈，找到对应的线程栈（注意10进制和16进制转换）

> JVM界顶级大佬R的文章
> 
> [借HSDB来探索HotSpot VM的运行时数据][HSDB_HotSpot VM]，说实话个人看了好几遍感觉好深奥

由此可见堆外内存追踪技术手段也确实不少，基本上可以解决你遇到的大多数情况。![73521055][]

**引用资料**

*  [记一次ClassLoader死锁][ClassLoader]
 *  [Spring Boot内存泄露排查记][Spring Boot]

[netty_Recycler]: https://blog.csdn.net/alex_xfboy/article/details/90384332
[IO]: https://blog.csdn.net/alex_xfboy/article/details/90174840
[JVM]: https://blog.csdn.net/alex_xfboy/article/details/77453793
[Netty_ResourceLeakDetector]: https://blog.csdn.net/alex_xfboy/article/details/89643626
[gperftools]: https://github.com/gperftools/gperftools
[HSDB_HotSpot VM]: http://rednaxelafx.iteye.com/blog/1847971
[73521055]: /images/20220205/658c4cafb5c7471a83e6534050a03347.png
[ClassLoader]: http://ju.outofmemory.cn/entry/276281
[Spring Boot]: https://mp.weixin.qq.com/s/aYwIH0TN3nSzNaMR2FN0AA