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