使用堆內(nèi)內(nèi)存HeapByteBuffer的注意事項
[導(dǎo)讀]分享一個很多人容易踩的一個坑: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 的復(fù)制問題
廢話不多說,直接來看 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 個線程進(jìn)行讀寫,如果按照線程維度進(jìn)行緩存,每個線程分到 50M 用于內(nèi)存緩存自然是沒有問題。而如果你直接使用上述代碼,在評測中可能會直接得到內(nèi)存溢出相關(guān)的異常。其實我在之前堆外內(nèi)存泄漏的文章中也提到過這個問題,不過角度有所不同。原因很簡單,直接來看源碼。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 時,會走到下面這個分支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 變量來進(jìn)行緩存,從而復(fù)用(實際上這個數(shù)值非常大,幾乎不會走進(jìn)直接分配堆外內(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 時需要復(fù)制到 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ì)上是為了給每個線程維護(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ù)制,從而使得這個過程更加直觀地被我們自己操控,而不是被 FileChannel 的內(nèi)部邏輯左右。這里也需要注意- 單次 IO 使用的 DirectByteBuffer 不宜過大,僅僅作為一個運輸載體,起到一個運輸數(shù)據(jù)的作用。這樣在多線程場景下,才不至于占用過多的堆外內(nèi)存
- 單次 IO 使用的 DirectByteBuffer 不宜過小,否則會出現(xiàn)讀寫放大的問題,一般建議設(shè)置 4kb 的整數(shù)倍,具體以實際測試結(jié)果為準(zhǔn)。





