一文探讨堆外内存的监控与回收

引子

记得那时一个风和日丽的周末，太阳红彤彤，花儿五颜六色，96 年的普哥微信找到我，描述了一个诡异的线上问题：线上程序使用了 NIO FileChannel 的 堆内内存作为缓冲区，读写文件，逻辑可以说相当简单，但根据监控却发现堆外内存飙升，导致了 OutOfMemeory 的异常。

由这个线上问题，引出了这篇文章的主题，主要包括：FileChannel 源码分析，堆外内存监控，堆外内存回收。

问题分析&源码分析

根据异常日志的定位，发现的确使用的是 HeapByteBuffer 来进行读写，但却导致堆外内存飙升，随记翻了 FileChannel 的源码，来一探究竟：

FileChannel 使用的是 IOUtil 来进行读写（只分析读的逻辑，写的逻辑行为和读其实一致，不进行重复分析）

可以发现当使用 HeapByteBuffer 时，会走到下面这行比较奇怪的代码分支：

Util.getTemporaryDirectBuffer(var1.remaining());

这个 Util 封装了更为底层的一些 IO 逻辑

isBufferTooLarge 这个方法会根据传入 Buffer 的大小决定如何分配堆外内存，如果过大，直接分布大缓冲区；如果不是太大，会使用 bufferCache 这个 ThreadLocal 变量来进行缓存，从而复用（实际上这个数值非常大，几乎不会走进直接分配堆外内存这个分支）。这么看来似乎发现了两个不得了的结论：

1. 使用 HeapByteBuffer 读写都会经过 DirectByteBuffer，写入数据的流转方式其实是：HeapByteBuffer -> DirectByteBuffer -> PageCache -> Disk，读取数据的流转方式正好相反。
2. 大多数情况下，会申请一块跟线程绑定的堆外缓存，这意味着，线程越多，这块临时的堆外缓存就越大。

看到这儿，似乎线上的问题有了一点眉目：很有可能是多线程使用堆内内存写入文件，而额外分配这块堆外缓存导致了内存溢出。在验证这个猜测之前，我们最好能直观地监控到堆外内存的使用量，这才能增加我们定位问题的信心。

实现堆外内存的监控

JDK 提供了一个非常好用的监控工具 —— Java VisualVM。我们只需要为他安装 2 个插件，即可很方便地实现堆外内存的监控。

进入本地 JDK 的可执行目录（在我本地是：
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/bin），找到 jvisualvm 命令，双击即可打开一个可视化的界面

左侧树状目录可以选择需要监控的 Java 进程，右侧是监控的维度信息，除了 CPU、线程、堆、类等信息，还可以通过上方的 安装插件，增加 MBeans、Buffer Pools 等维度的监控。

Buffer Pools 插件可以监控堆外内存（包含 DirectByteBuffer 和 MappedByteBuffer），如下图所示：

左侧对应 DirectByteBuffer，右侧对应 MappedByteBuffer。

复现问题

为了复现线上的问题，我们使用一个程序，不断开启线程使用堆内内存作为缓冲区进行文件的读取操作，并监控该进程的堆外内存使用情况。

运行一段时间后，我们观察下堆外内存的使用情况

如上图左所示，对外内存的确开始疯涨了，的确符合我们的预期，堆外缓存和线程绑定，当线程非常多时，即使只使用了 4M 的堆内内存，也可能会造成极大的堆外内存膨胀，在中间发生了一次断崖，推测是线程执行完毕 or GC，导致了内存的释放。

知晓了这一点，相信大家今后使用堆内内存时可能就会更加注意了，我总结了两个注意点：

1. 使用 HeapByteBuffer 还需要经过一次 DirectByteBuffer 的拷贝，在追求极致性能的场景下是可以通过直接复用堆外内存来避免的。
2. 多线程下使用 HeapByteBuffer 进行文件读写，要注意 ThreadLocal<Util.BufferCache>bufferCache 导致的堆外内存膨胀的问题。

问题深究

那大家有没有想过，为什么 JDK 要如此设计？为什么不直接使用堆内内存写入 PageCache 进而落盘呢？为什么一定要经过 DirectByteBuffer 的拷贝呢？

在知乎的相关问题中，R 大和曾泽堂 两位同学进行了解答，是我比较认同的解释：

总结一下就是：

堆外内存的回收

继续深究一下一个话题，也是我的微信交流群中曾经有人提出过的一个疑问，到底该如何回收 DirectByteBuffer？既然可以监控堆外内存，那验证堆外内存的回收就变得很容易实现了。

CASE 1：分配 1G 的 DirectByteBuffer，等待用户输入后，复制为 null，之后阻塞持续观察堆外内存变化

结论：变量虽然置为了 null，但内存依旧持续占用。

CASE 2：分配 1G DirectByteBuffer，等待用户输入后，复制为 null，手动触发 GC，之后阻塞持续观察堆外内存变化

结论：GC 时会触发堆外空闲内存的回收。

CASE 3：分配 1G DirectByteBuffer，等待用户输入后，手动回收堆外内存，之后阻塞持续观察堆外内存变化

结论：手动回收可以立刻释放堆外内存，不需要等待到 GC 的发生。

对于 MappedByteBuffer 这个有点神秘的类，它的回收机制大概和 DirectByteBuffer 类似，体现在右边的 Mapped 之中，我们就不重复 CASE1 和 CASE2 的测试了，直接给出结论，在 GC 发生或者操作系统主动清理时 MappedByteBuffer 会被回收。但也不是不进行测试，我们会对 MappedByteBuffer 进行更有意思的研究。

CASE 4：手动回收 MappedByteBuffer。

这个类曾经在我的《文件 IO 的一些最佳实践》中有所介绍，在这里我们将验证它的作用。编写测试类：

结论：通过一顿复杂的反射操作，成功地手动回收了 Mmap 的内存映射。

CASE 5：测试 Mmap 的内存占用

我尝试映射了 1000G 的内存，我的电脑显然没有 1000G 这么大内存，那么监控是如何反馈的呢？

几乎在瞬间，控制台打印出了 map finish 的日志，也意味着 1000G 的内存映射几乎是不耗费时间的，为什么要做这个测试？就是为了解释内存映射并不等于内存占用，很多文章认为内存映射这种方式可以大幅度提升文件的读写速度，并宣称“写 MappedByteBuffer 就等于写内存”，实际是非常错误的认知。通过控制面板可以查看到该 Java 进程（pid 39040）实际占用的内存，仅仅不到 100M。(关于 Mmap 的使用场景和方式可以参考我之前的文章)

结论：MappedByteBuffer 映射出一片文件内容之后，不会全部加载到内存中，而是会进行一部分的预读（体现在占用的那 100M 上），MappedByteBuffer 不是文件读写的银弹，它仍然依赖于 PageCache 异步刷盘的机制。通过 Java VisualVM 可以监控到 mmap 总映射的大小，但并不是实际占用的内存量。

总结