一文探討堆外內存的監控與回收

引子

記得那是一個風和日麗的週末，太陽紅彤彤，花兒五顏六色，96 年的普哥微信找到我，描述了一個詭異的線上問題：線上程序使用了 NIO FileChannel 的 堆內內存（HeapByteBuffer）作為緩衝區，讀寫文件，邏輯可以說相當簡單，但根據監控，卻發現堆外內存（DirectByteBuffer）飆升，導致了 OutOfMemeory 的異常。

由這個線上問題，引出了這篇文章的主題，主要包括：FileChannel 源碼分析，堆外內存監控，堆外內存回收。

問題分析&源碼分析

根據異常日誌的定位，發現的確使用的是 HeapByteBuffer 來進行讀寫，但卻導致堆外內存飆升，隨即翻了 FileChannel 的源碼，來一探究竟。

FileChannel 使用的是 IOUtil 進行讀寫操作（本文只分析讀的邏輯，寫和讀的代碼邏輯一致，不做重複分析）

//sun.nio.ch.IOUtil#read
static int read(FileDescriptor var0, ByteBuffer var1, long var2, NativeDispatcher var4) throws IOException {
 if (var1.isReadOnly()) {
 throw new IllegalArgumentException("Read-only buffer");
 } else if (var1 instanceof DirectBuffer) {
 return readIntoNativeBuffer(var0, var1, var2, var4);
 } else {
 ByteBuffer var5 = Util.getTemporaryDirectBuffer(var1.remaining());
 int var7;
 try {
 int var6 = readIntoNativeBuffer(var0, var5, var2, var4);
 var5.flip();
 if (var6 > 0) {
 var1.put(var5);
 }
 var7 = var6;
 } finally {
 Util.offerFirstTemporaryDirectBuffer(var5);
 }
 return var7;
 }
}

可以發現當使用 HeapByteBuffer 時，會走到下面這行看似有點疑問的代碼分支：

Util.getTemporaryDirectBuffer(var1.remaining());

這個 Util 封裝了更為底層的一些 IO 邏輯

package sun.nio.ch;
public class Util {
 private static ThreadLocal<util.buffercache> bufferCache;
 
 public static ByteBuffer getTemporaryDirectBuffer(int var0) {
 if (isBufferTooLarge(var0)) {
 return ByteBuffer.allocateDirect(var0);
 } else {
 // FOUCS ON THIS LINE
 Util.BufferCache var1 = (Util.BufferCache)bufferCache.get();
 ByteBuffer var2 = var1.get(var0);
 if (var2 != null) {
 return var2;
 } else {
 if (!var1.isEmpty()) {
 var2 = var1.removeFirst();
 free(var2);
 }
 return ByteBuffer.allocateDirect(var0);
 }
 }
 }
}
/<util.buffercache>

isBufferTooLarge 這個方法會根據傳入 Buffer 的大小決定如何分配堆外內存，如果過大，直接分配大緩衝區；如果不是太大，會使用 bufferCache 這個 ThreadLocal 變量來進行緩存，從而複用（實際上這個數值非常大，幾乎不會走進直接分配堆外內存這個分支）。這麼看來似乎發現了兩個不得了的結論：

1. 使用 HeapByteBuffer 讀寫都會經過 DirectByteBuffer，寫入數據的流轉方式其實是：HeapByteBuffer -> DirectByteBuffer -> PageCache -> Disk，讀取數據的流轉方式正好相反。
2. 使用 HeapByteBuffer 讀寫會申請一塊跟線程綁定的 DirectByteBuffer。這意味著，線程越多，臨時 DirectByteBuffer 就越會佔用越多的空間。

看到這兒，線上的問題似乎有了一點眉目：很有可能是多線程使用 HeapByteBuffer 寫入文件，而額外分配的這塊 DirectByteBuffer 導致了內存溢出。在驗證這個猜測之前，我們最好能直觀地監控到堆外內存的使用量，這才能增加我們定位問題的信心。

實現堆外內存的監控

JDK 提供了一個非常好用的監控工具 —— Java VisualVM。我們只需要為它安裝一個插件，即可很方便地實現堆外內存的監控。

進入本地 JDK 的可執行目錄（在我本地是：/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/bin），找到 jvisualvm 命令，雙擊打開一個可視化的界面

左側樹狀目錄可以選擇需要監控的 Java 進程，右側是監控的維度信息，除了 CPU、線程、堆、類等信息，還可以通過上方的【工具(T)】 安裝插件，增加 MBeans、Buffer Pools 等維度的監控。

Buffer Pools 插件可以監控堆外內存（包含 DirectByteBuffer 和 MappedByteBuffer），如下圖所示：

左側對應 DirectByteBuffer，右側對應 MappedByteBuffer。

復現問題

為了復現線上的問題，我們使用一個程序，不斷開啟線程使用堆內內存作為緩衝區進行文件的讀取操作，並監控該進程的堆外內存使用情況。

public class ReadByHeapByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 File data = new File("/tmp/data.txt");
 FileChannel fileChannel = new RandomAccessFile(data, "rw").getChannel();
 ByteBuffer buffer = ByteBuffer.allocate(4 * 1024 * 1024);
 for (int i = 0; i < 1000; i++) {
 Thread.sleep(1000);
 new Thread(new Runnable() {
 @Override
 public void run() {
 try {
 fileChannel.read(buffer);
 buffer.clear();
 } catch (IOException e) {
 e.printStackTrace();
 }
 }
 }).start();
 }
 }
}

運行一段時間後，我們觀察下堆外內存的使用情況

如上圖左所示，堆外內存的確開始瘋漲了，的確符合我們的預期，堆外緩存和線程綁定，當線程非常多時，即使只使用了 4M 的堆內內存，也可能會造成極大的堆外內存膨脹，在中間發生了一次斷崖，推測是線程執行完畢 or GC，導致了內存的釋放。

知曉了這一點，相信大家今後使用堆內內存時可能就會更加註意了，我總結了兩個注意點：

1. 使用 HeapByteBuffer 還需要經過一次 DirectByteBuffer 的拷貝，在追求極致性能的場景下是可以通過直接複用堆外內存來避免的。
2. 多線程下使用 HeapByteBuffer 進行文件讀寫，要注意 ThreadLocal<util.buffercache> bufferCache 導致的堆外內存膨脹的問題。/<util.buffercache>

問題深究

那大家有沒有想過，為什麼 JDK 要如此設計？為什麼不直接使用堆內內存寫入 PageCache 進而落盤呢？為什麼一定要經過 DirectByteBuffer 的拷貝呢？

在知乎的相關問題中，R 大和曾澤堂 兩位同學進行了解答，是我比較認同的解釋：

這裡其實是在遷就OpenJDK裡的HotSpot VM的一點實現細節。

HotSpot VM 裡的 GC 除了 CMS 之外都是要移動對象的，是所謂“compacting GC”。

如果要把一個Java裡的 byte[] 對象的引用傳給native代碼，讓native代碼直接訪問數組的內容的話，就必須要保證native代碼在訪問的時候這個 byte[] 對象不能被移動，也就是要被“pin”（釘）住。

可惜 HotSpot VM 出於一些取捨而決定不實現單個對象層面的 object pinning，要 pin 的話就得暫時禁用 GC——也就等於把整個 Java 堆都給 pin 住。

所以 Oracle/Sun JDK / OpenJDK 的這個地方就用了點繞彎的做法。它假設把 HeapByteBuffer 背後的 byte[] 裡的內容拷貝一次是一個時間開銷可以接受的操作，同時假設真正的 I/O 可能是一個很慢的操作。

於是它就先把 HeapByteBuffer 背後的 byte[] 的內容拷貝到一個 DirectByteBuffer 背後的 native memory去，這個拷貝會涉及 sun.misc.Unsafe.copyMemory() 的調用，背後是類似 memcpy() 的實現。這個操作本質上是會在整個拷貝過程中暫時不允許發生 GC 的。

然後數據被拷貝到 native memory 之後就好辦了，就去做真正的 I/O，把 DirectByteBuffer 背後的 native memory 地址傳給真正做 I/O 的函數。這邊就不需要再去訪問 Java 對象去讀寫要做 I/O 的數據了。

總結一下就是：

• 為了方便 GC 的實現，DirectByteBuffer 指向的 native memory 是不受 GC 管轄的
• HeapByteBuffer 背後使用的是 byte 數組，其佔用的內存不一定是連續的，不太方便 JNI 方法的調用
• 數組實現在不同 JVM 中可能會不同

堆外內存的回收

繼續深究下一個話題，也是我的微信交流群中曾經有人提出過的一個疑問，到底該如何回收 DirectByteBuffer？既然可以監控堆外內存，那驗證堆外內存的回收就變得很容易實現了。

CASE 1：分配 1G 的 DirectByteBuffer，等待用戶輸入後，複製為 null，之後阻塞持續觀察堆外內存變化

public class WriteByDirectByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
 System.in.read();
 buffer = null;
 new CountDownLatch(1).await();
 }
}

結論：變量雖然置為了 null，但內存依舊持續佔用。

CASE 2：分配 1G DirectByteBuffer，等待用戶輸入後，複製為 null，手動觸發 GC，之後阻塞持續觀察堆外內存變化

public class WriteByDirectByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
 System.in.read();
 buffer = null;
 System.gc();
 new CountDownLatch(1).await();
 }
}

結論：GC 時會觸發堆外空閒內存的回收。

CASE 3：分配 1G DirectByteBuffer，等待用戶輸入後，手動回收堆外內存，之後阻塞持續觀察堆外內存變化

public class WriteByDirectByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
 System.in.read();
 ((DirectBuffer) buffer).cleaner().clean();
 new CountDownLatch(1).await();
 }
}

結論：手動回收可以立刻釋放堆外內存，不需要等待到 GC 的發生。

對於 MappedByteBuffer 這個有點神秘的類，它的回收機制大概和 DirectByteBuffer 類似，體現在右邊的 Mapped 之中，我們就不重複 CASE1 和 CASE2 的測試了，直接給出結論，在 GC 發生或者操作系統主動清理時 MappedByteBuffer 會被回收。但也不是不進行測試，我們會對 MappedByteBuffer 進行更有意思的研究。

CASE 4：手動回收 MappedByteBuffer。

public class MmapUtil {
 public static void clean(MappedByteBuffer mappedByteBuffer) {
 ByteBuffer buffer = mappedByteBuffer;
 if (buffer == null || !buffer.isDirect() || buffer.capacity() == 0)
 return;
 invoke(invoke(viewed(buffer), "cleaner"), "clean");
 }
 private static Object invoke(final Object target, final String methodName, final Class>... args) {
 return AccessController.doPrivileged(new PrivilegedAction<object>() {
 public Object run() {
 try {
 Method method = method(target, methodName, args);
 method.setAccessible(true);
 return method.invoke(target);
 } catch (Exception e) {
 throw new IllegalStateException(e);
 }
 }
 });
 }
 private static Method method(Object target, String methodName, Class>[] args)
 throws NoSuchMethodException {
 try {
 return target.getClass().getMethod(methodName, args);
 } catch (NoSuchMethodException e) {
 return target.getClass().getDeclaredMethod(methodName, args);
 }
 } 

 private static ByteBuffer viewed(ByteBuffer buffer) {
 String methodName = "viewedBuffer";
 Method[] methods = buffer.getClass().getMethods();
 for (int i = 0; i < methods.length; i++) {
 if (methods[i].getName().equals("attachment")) {
 methodName = "attachment";
 break;
 }
 }
 ByteBuffer viewedBuffer = (ByteBuffer) invoke(buffer, methodName);
 if (viewedBuffer == null)
 return buffer;
 else
 return viewed(viewedBuffer);
 }
}
/<object>

這個類曾經在我的《文件 IO 的一些最佳實踐》中有所介紹，在這裡我們將驗證它的作用。編寫測試類：

public class WriteByMappedByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 File data = new File("/tmp/data.txt");
 data.createNewFile();
 FileChannel fileChannel = new RandomAccessFile(data, "rw").getChannel();
 MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, 1024L * 1024 * 1024);
 System.in.read();
 MmapUtil.clean(map);
 new CountDownLatch(1).await();
 }
}

結論：通過一頓複雜的反射操作，成功地手動回收了 Mmap 的內存映射。

CASE 5：測試 Mmap 的內存佔用

public class WriteByMappedByteBufferTest {
 public static void main(String[] args) throws IOException, InterruptedException {
 File data = new File("/tmp/data.txt");
 data.createNewFile();
 FileChannel fileChannel = new RandomAccessFile(data, "rw").getChannel();
 for (int i = 0; i < 1000; i++) {
 fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, 1024L * 1024 * 1024);
 }
 System.out.println("map finish");
 new CountDownLatch(1).await();
 }
}

我嘗試映射了 1000G 的內存，我的電腦顯然沒有 1000G 這麼大內存，那麼監控是如何反饋的呢？

幾乎在瞬間，控制檯打印出了 map finish 的日誌，也意味著 1000G 的內存映射幾乎是不耗費時間的，為什麼要做這個測試？就是為了解釋內存映射並不等於內存佔用，很多文章認為內存映射這種方式可以大幅度提升文件的讀寫速度，並宣稱“寫 MappedByteBuffer 就等於寫內存”，實際是非常錯誤的認知。通過控制面板可以查看到該 Java 進程（pid 39040）實際佔用的內存，僅僅不到 100M。(關於 Mmap 的使用場景和方式可以參考我之前的文章)

結論：MappedByteBuffer 映射出一片文件內容之後，不會全部加載到內存中，而是會進行一部分的預讀（體現在佔用的那 100M 上），MappedByteBuffer 不是文件讀寫的銀彈，它仍然依賴於 PageCache 異步刷盤的機制。通過 Java VisualVM 可以監控到 mmap 總映射的大小，但並不是實際佔用的內存量。

總結

本文藉助一個線上問題，分析了使用堆內內存仍然會導致堆外內存分析的現象以及背後 JDK 如此設計的原因，並藉助安裝了插件之後的 Java VisualVM 工具進行了堆外內存的監控，進而討論瞭如何正確的回收堆外內存，以及糾正了一個關於 MappedByteBuffer 的錯誤認知。

關注我：私信回覆“555”獲取往期Java高級架構資料、源碼、筆記、視頻Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等架構技術往期架構視頻

閱讀更多 來一杯82年的Java 的文章

關鍵字: 內存 堆外 new