[[427434]]

本文轉載自微信公眾號「Kirito的技術分享」，作者kiritomoe。轉載本文請聯系Kirito的技術分享公眾號。

前言

國慶假期一眨眼就過去了，本來在家躺平的很舒服，沒怎么肝云原生編程挑戰賽，傳送門：https://tianchi.aliyun.com/s/8bf1fe4ae2aea736e692c31c6952042d ，偏偏對手們假期開始卷起來了，眼看就要被人反超了，嚇得我趕緊繼續優化了。比賽大概還有一個月才結束，Kirito 的詳細方案也會在比賽結束后分享，這期間我會分享一些比賽中的一些通用優化或者細節知識點，例如本文就是這么一個例子。

趁著假期最后一天，分享一個很多人容易踩的一個坑：HeapByteBuffer 的使用問題。我們都知道 NIO 分裝了 ByteBuffer 接口，使得 filechannel 的文件 IO API 變得非常的簡單。ByteBuffer 主要有兩個實現類

• HeapByteBuffer 堆內內存
• DirectByteBuffer 堆外內存

按我的個人經驗，大多數情況，無論是讀操作還是寫操作，我都傾向于使用 DirectByteBuffer，主要是因為 HeapByteBuffer 在和 FileChannel 交互時，可能會有一些出乎大家意料的內部操作，也就是這篇文章的標題中提到的注意事項，這里先賣個關子。

先來看看這次比賽為什么要用到 HeapByteBuffer 呢?

原因一：賽題需要設計分級存儲，并且提供了 6G 堆內內存 + 2G 堆外內存，一個最直接的思路便是使用內存來存儲熱點數據，而內存存儲數據最方便的數據結構便是 ByteBuffer 了。

原因二：由于堆內 6G 遠大于堆外 2G，且 JVM 參數不能調整，所以要想利用好堆內富余的內存去做緩存，非 HeapByteBuffer 莫屬了。

可能有一些讀者并沒有關注賽題，我這里簡化一下前言，可以直接理解為：有一塊 2G 的 HeapByteBuffer 用于文件 IO，我們該如何利用。

HeapByteBuffer 的復制問題

廢話不多說，直接來看 HeapByteBuffer 的坑在哪兒。

使用代碼描述 HeapByteBuffer 的文件 IO 操作，大概率會寫出如下的代碼：

public void readInOneThread() throws Exception { 
    int bufferSize = 50 * 1024 * 1024; 
    File file = new File("/essd"); 
    FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel(); 
    ByteBuffer byteBuffer = ByteBuffer.allocate(bufferSize); 
    fileChannel.read(byteBuffer); 
} 

上述的代碼，將文件中的數據緩存到了內存中，無論是賽題還是生產場景，這個行為通常都是多線程的，例如在云原生編程挑戰賽的評測下，有 40 個線程進行讀寫，如果按照線程維度進行緩存，每個線程分到 50M 用于內存緩存自然是沒有問題。

而如果你直接使用上述代碼，在評測中可能會直接得到內存溢出相關的異常。其實我在之前堆外內存泄漏的文章中也提到過這個問題，不過角度有所不同。原因很簡單，直接來看源碼。

FileChannel 使用的是 IOUtil 進行讀寫操作

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); 
            } 
        } 
    } 
} 

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

使用 HeapByteBuffer 讀寫都會經過 DirectByteBuffer，寫入數據的流轉方式其實是：HeapByteBuffer -> DirectByteBuffer -> PageCache -> Disk，讀取數據的流轉方式正好相反。

使用 HeapByteBuffer 讀寫會申請一塊跟線程綁定的 DirectByteBuffer。這意味著，線程越多，臨時 DirectByteBuffer 就越會占用越多的空間。

根據這兩個結論，我們再回到賽題中，如果直接按照上述的方式進行讀寫，40 個線程每個都持有一個 50M 的堆內內存，同時又因為 IOUtil 的內部行為，額外分配了 40*50M 的堆外內存， 堆外內存在不經意間就被用光了!出現堆外內存溢出的異常也就不奇怪了。

為什么 HeapByteBuffer 在 IO 時需要復制到 DirectByteBuffer

這個我之前也介紹過，詳情可以參考我的一篇舊文：《一文探討堆外內存的監控與回收》。總結如下：

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

解決方案

其實我們本質上是為了給每個線程維護一塊 HeapByteBuffer，用于緩存數據，并沒有必要以 ByteBuffer 的大小為維度來進行 IO。可以借鑒 IOUtil 中復制 DirectByteBuffer 的思路來優化這一過程。代碼示例如下：

public void directBufferCopy() throws Exception { 
    File file = new File("/essd"); 
    FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel(); 
    ByteBuffer byteBuffer = ByteBuffer.allocate(50 * 1024 * 1024); 
    ByteBuffer directByteBuffer = ByteBuffer.allocateDirect(4 * 1024); 
    for (int i = 0; i < 12800; i++) { 
        directByteBuffer.clear(); 
        fileChannel.read(directByteBuffer, i * 4 * 1024); 
        directByteBuffer.flip(); 
        byteBuffer.put(directByteBuffer); 
    } 
} 

在 Java 中，從磁盤到堆內內存，一定無法省略堆外內存的復制，但我們可以自己復制，從而使得這個過程更加直觀地被我們自己操控，而不是被 FileChannel 的內部邏輯左右。

這里也需要注意

單次 IO 使用的 DirectByteBuffer 不宜過大，僅僅作為一個運輸載體，起到一個運輸數據的作用。這樣在多線程場景下，才不至于占用過多的堆外內存

單次 IO 使用的 DirectByteBuffer 不宜過小，否則會出現讀寫放大的問題，一般建議設置 4kb 的整數倍，具體以實際測試結果為準。

其他注意事項

HeapByteBuffer 讀寫時的復制問題是本文的主角，但使用 HeapByteBuffer 作為緩存時，也需要注意一些其他問題。例如比賽場景中，你可能希望開辟一大塊 HeapByteBuffer，6G 堆內內存，分配個 4G 用作緩存總可以吧?可不可以我說了不算，你感興趣的話倒是可以測試一下是否可行，還需要考慮 GC 情況，需要綜合考慮老年代和新生代的配比，如果你分配了過多堆內內存給 HeapByteBuffer 緩存，可能會直接導致 OutOfMemory 或者觸發 GC。

同時，如果 HeapByteBuffer 占用了過多內存，留給操作系統的 PageCache 也會非常有限，這兩者使用的可是同一塊內存!如果你的程序利用到了 PageCache 的特性，可能會由于 PageCache 空間不夠，導致 IO 速度變慢。

總結

本文介紹了在文件 IO 中使用 HeapByteBuffer 的注意事項，需要考慮到 FileChannel 內部的復制問題，意識到這一過程會有堆外內存的復制開銷。在實際使用場景中，個人更加推薦直接使用 DirectByteBuffer 進行 IO 操作。如果出于某些原因，一定需要使用 HeapByteBuffer 存儲作為緩存，可以參考文中分批使用 DirectByteBuffer 進行 IO 并復制的方案。