使用堆內(nèi)內(nèi)存HeapByteBuffer的注意事項
[導讀]分享一個很多人容易踩的一個坑：HeapByteBuffer的使用問題。我們都知道NIO分裝了ByteBuffer接口，使得filechannel的文件IOAPI變得非常的簡單。ByteBuffer主要有兩個實現(xiàn)類HeapByteBuffer堆內(nèi)內(nèi)存DirectByteBuffer...
分享一個很多人容易踩的一個坑：HeapByteBuffer 的使用問題。我們都知道 NIO 分裝了 ByteBuffer 接口，使得 filechannel 的文件 IO API 變得非常的簡單。ByteBuffer 主要有兩個實現(xiàn)類
- HeapByteBuffer 堆內(nèi)內(nèi)存
- DirectByteBuffer 堆外內(nèi)存
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);
}
上述的代碼，將文件中的數(shù)據(jù)緩存到了內(nèi)存中，無論是賽題還是生產(chǎn)場景，這個行為通常都是多線程的，例如在云原生編程挑戰(zhàn)賽的評測下，有 40 個線程進行讀寫，如果按照線程維度進行緩存，每個線程分到 50M 用于內(nèi)存緩存自然是沒有問題。而如果你直接使用上述代碼，在評測中可能會直接得到內(nèi)存溢出相關(guān)的異常。其實我在之前堆外內(nèi)存泄漏的文章中也提到過這個問題，不過角度有所不同。原因很簡單，直接來看源碼。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;
????}
}
可以發(fā)現(xiàn)當使用 HeapByteBuffer 時，會走到下面這個分支Util.getTemporaryDirectBuffer(var1.remaining());
這個 Util 封裝了更為底層的一些 IO 邏輯package?sun.nio.ch;
public?class?Util?{
????private?static?ThreadLocal?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 這個方法會根據(jù)傳入 Buffer 的大小決定如何分配堆外內(nèi)存，如果過大，直接分配大緩沖區(qū)；如果不是太大，會使用 bufferCache 這個 ThreadLocal 變量來進行緩存，從而復用（實際上這個數(shù)值非常大，幾乎不會走進直接分配堆外內(nèi)存這個分支）。這么看來似乎發(fā)現(xiàn)了兩個不得了的結(jié)論：- 使用 HeapByteBuffer 讀寫都會經(jīng)過 DirectByteBuffer，寫入數(shù)據(jù)的流轉(zhuǎn)方式其實是：HeapByteBuffer -> DirectByteBuffer -> PageCache -> Disk，讀取數(shù)據(jù)的流轉(zhuǎn)方式正好相反。
- 使用 HeapByteBuffer 讀寫會申請一塊跟線程綁定的 DirectByteBuffer。這意味著，線程越多，臨時 DirectByteBuffer 就越會占用越多的空間。
為什么 HeapByteBuffer 在 IO 時需要復制到 DirectByteBuffer
這個我之前也介紹過，詳情可以參考我的一篇舊文：《一文探討堆外內(nèi)存的監(jiān)控與回收》?？偨Y(jié)如下：- 為了方便 GC 的實現(xiàn)，DirectByteBuffer 指向的 native memory 是不受 GC 管轄的
- HeapByteBuffer 背后使用的是 byte 數(shù)組，其占用的內(nèi)存不一定是連續(xù)的，不太方便 JNI 方法的調(diào)用
- 數(shù)組實現(xiàn)在不同 JVM 中可能會不同
解決方案
其實我們本質(zhì)上是為了給每個線程維護一塊 HeapByteBuffer，用于緩存數(shù)據(jù)，并沒有必要以 ByteBuffer 的大小為維度來進行 IO?？梢越梃b IOUtil 中復制 DirectByteBuffer 的思路來優(yōu)化這一過程。代碼示例如下：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 中，從磁盤到堆內(nèi)內(nèi)存，一定無法省略堆外內(nèi)存的復制，但我們可以自己復制，從而使得這個過程更加直觀地被我們自己操控，而不是被 FileChannel 的內(nèi)部邏輯左右。這里也需要注意- 單次 IO 使用的 DirectByteBuffer 不宜過大，僅僅作為一個運輸載體，起到一個運輸數(shù)據(jù)的作用。這樣在多線程場景下，才不至于占用過多的堆外內(nèi)存
- 單次 IO 使用的 DirectByteBuffer 不宜過小，否則會出現(xiàn)讀寫放大的問題，一般建議設置 4kb 的整數(shù)倍，具體以實際測試結(jié)果為準。
下載文檔
