聊聊 Netty 對(duì)于內(nèi)存方面的優(yōu)化
Netty通過巧妙的內(nèi)存使用技巧盡可能節(jié)約內(nèi)存空間,進(jìn)而減少java中Full gc的STW的時(shí)間,由此間接的提升了程序的性能,本文也將直接從源碼的角度分析一下Netty對(duì)于內(nèi)存方面的使用技巧,希望對(duì)你有所啟發(fā)。
詳解Netty中的內(nèi)存的優(yōu)化思路
1.使用基本類型替代包裝類
內(nèi)存空間算是寶貴的系統(tǒng)資源,為了提升CPU加載數(shù)據(jù)效率以及節(jié)約內(nèi)存空間,對(duì)于某些常見的基本數(shù)據(jù)類型,Netty都是能省則省,最直接的落地方案就是使用基本類型替代包裝類。
這其中totalPendingSize這個(gè)變量,它用于記錄那些待處理的數(shù)據(jù),為了節(jié)約內(nèi)存空間,記錄大小的類型是long而非Long,通過這種方式避免了創(chuàng)建java對(duì)象(java對(duì)象包含對(duì)象頭的信息,相比基本類型更占用內(nèi)存空間):
對(duì)此我們也給出這個(gè)變量的定義:
@SuppressWarnings("UnusedDeclaration")
private volatile long totalPendingSize;
又因?yàn)樵撟侄涡枰WC線程安全,所以Netty設(shè)計(jì)者在此基礎(chǔ)上又將其設(shè)置為AtomicLong原子類型,通過static關(guān)鍵字加以修飾,使所有實(shí)例共享一個(gè)變量,從而避免沒必要的創(chuàng)建開銷和并發(fā)安全:
對(duì)此我們也給出源碼示例,即位于ChannelOutboundBuffer變量定義的位置:
//通過AtomicLongFieldUpdater修飾totalPendingSize
private static final AtomicLongFieldUpdater<ChannelOutboundBuffer> TOTAL_PENDING_SIZE_UPDATER =
AtomicLongFieldUpdater.newUpdater(ChannelOutboundBuffer.class, "totalPendingSize");
2.動(dòng)態(tài)內(nèi)存調(diào)整
除上述內(nèi)存使用技巧以外,netty在進(jìn)行內(nèi)存分配時(shí)也用到的動(dòng)態(tài)調(diào)整的使用技巧,該設(shè)計(jì)理念比較簡單,按照空間與分配思想:后續(xù)使用的內(nèi)存大小大概率是等同于本次使用的空間大小,所以Netty在調(diào)用record進(jìn)行內(nèi)存分配時(shí),如果發(fā)現(xiàn)縮小空間依然可以滿足要求,則進(jìn)行縮容,反之進(jìn)行擴(kuò)容,由此得到一個(gè)盡可能節(jié)約內(nèi)存空間且能滿足業(yè)務(wù)要求的數(shù)值:
private void record(int actualReadBytes) {
//若實(shí)際需要的空間 <= 預(yù)縮小達(dá)到的尺寸,則對(duì)nextReceiveBufferSize進(jìn)行縮減
if (actualReadBytes <= SIZE_TABLE[max(0, index - INDEX_DECREMENT)]) {
if (decreaseNow) {
index = max(index - INDEX_DECREMENT, minIndex);
nextReceiveBufferSize = SIZE_TABLE[index];
decreaseNow = false;
} else {
decreaseNow = true;
}
} else if (actualReadBytes >= nextReceiveBufferSize) {//如果所需空間大于nextReceiveBufferSize,則進(jìn)行擴(kuò)容
index = min(index + INDEX_INCREMENT, maxIndex);
nextReceiveBufferSize = SIZE_TABLE[index];
decreaseNow = false;
}
}
3.應(yīng)用層面的zero-copy
內(nèi)存拷貝也是存在一定的時(shí)間開銷,例如我們現(xiàn)在有一個(gè)字符串的數(shù)據(jù)需要將byte1和byte2拼接起來才能得到,按照傳統(tǒng)的實(shí)現(xiàn)思路,我們需要開發(fā)一個(gè)足夠容納byte1和byte2的內(nèi)存空間,然后將byte1和byte2一并寫入,這種做法有著如下耗時(shí)點(diǎn):
- 開辟內(nèi)存空間所占用的時(shí)間。
- 將byte1內(nèi)存新開辟空間的耗時(shí)。
- 將byte2寫入新開辟的內(nèi)存空間耗時(shí)。
而Netty則不是這樣做,它的設(shè)計(jì)思路是直接將兩個(gè)數(shù)組,邏輯上組合,即通過一個(gè)數(shù)組指向這兩個(gè)引用,從邏輯上視為一個(gè)整體,而不是物理操作上的組合:
對(duì)此我們給出CompositeByteBuf的addComponent0方法,可以看到對(duì)于需要組合的數(shù)據(jù)buffer,它會(huì)通過addComp方法將這個(gè)ByteBuf 存到CompositeByteBuf底層的數(shù)組中,由此保證數(shù)據(jù)邏輯上的一致:
private int addComponent0(boolean increaseWriterIndex, int cIndex, ByteBuf buffer) {
assert buffer != null;
boolean wasAdded = false;
try {
checkComponentIndex(cIndex);
//將其包裝為Component
Component c = newComponent(ensureAccessible(buffer), 0);
int readableBytes = c.length();
//......
//添加到CompositeByteBuf底層的components數(shù)組中,通過邏輯完成組合
addComp(cIndex, c);
//......
return cIndex;
} finally {
//......
}
}
//添加到components數(shù)組中保證邏輯上的一致
private void addComp(int i, Component c) {
//......
components[i] = c;
}
4.使用堆外內(nèi)存
將數(shù)據(jù)存放在JVM非堆內(nèi)存空間,通過減少?zèng)]必要的GC確保操作和執(zhí)行性能的高效,這也是Netty中對(duì)于內(nèi)存方面的優(yōu)化,這其中最經(jīng)典的就是PooledHeapByteBuf,它直接操作的就是堆外內(nèi)存的數(shù)據(jù):
對(duì)此我們也給處PooledDirectByteBuf 獲取直接內(nèi)存的源碼實(shí)現(xiàn):
//從內(nèi)存池中獲取直接內(nèi)存空間返回給用戶使用
static PooledDirectByteBuf newInstance(int maxCapacity) {
PooledDirectByteBuf buf = RECYCLER.get();
buf.reuse(maxCapacity);
return buf;
}
需要補(bǔ)充的是,這種做法也存在的一定的風(fēng)險(xiǎn):
- 創(chuàng)建速度慢。
- 存放在非堆內(nèi)存空間,使用不當(dāng)可能造成內(nèi)存泄漏。
5.內(nèi)存池化復(fù)用
上文的堆內(nèi)存就是PooledHeapByteBuf即池化過的內(nèi)存,通過池化:
- 保證對(duì)象復(fù)用,減小沒必要的創(chuàng)建開銷。
- 提升程序并發(fā)執(zhí)行性能。
對(duì)此我們給出相應(yīng)的源碼實(shí)現(xiàn):
//初始化直接內(nèi)存池化工廠RECYCLER
private static final ObjectPool<PooledDirectByteBuf> RECYCLER = ObjectPool.newPool(
new ObjectCreator<PooledDirectByteBuf>() {
@Override
public PooledDirectByteBuf newObject(Handle<PooledDirectByteBuf> handle) {
return new PooledDirectByteBuf(handle, 0);
}
});
//從內(nèi)存池中獲取直接內(nèi)存空間返回給用戶使用
static PooledDirectByteBuf newInstance(int maxCapacity) {
//從內(nèi)存池中獲取直接內(nèi)存空間
PooledDirectByteBuf buf = RECYCLER.get();
buf.reuse(maxCapacity);
return buf;
}
6.對(duì)jdk零拷貝的封裝
我們?cè)谏鲜鏊v的零復(fù)制更多強(qiáng)調(diào)的是應(yīng)用層面上的零復(fù)制,也就是通過減少應(yīng)用層面上數(shù)據(jù)的拷貝提升程序的執(zhí)行效率。實(shí)際上Netty也有基于操作系統(tǒng)層面的零拷貝實(shí)現(xiàn),這其中最典型的實(shí)現(xiàn)就是DefaultFileRegion的transferTo函數(shù),它底層調(diào)用JDK自帶的NIO零拷貝方法transferTo實(shí)現(xiàn)當(dāng)前文件數(shù)據(jù)通過sendfile調(diào)用傳輸?shù)絪ocket通道中,由此避免數(shù)據(jù)傳輸時(shí)多次切態(tài)、內(nèi)核緩沖區(qū)和用戶緩沖區(qū)來回拷貝的開銷:
對(duì)此我們也給出DefaultFileRegion類中transferTo的源碼,可以看到其底層就是將JDK默認(rèn)的NIO零拷貝方法進(jìn)行封裝,將DefaultFileRegion封裝的FileChannel 的文件數(shù)據(jù)拷貝到target的文件通道中,其底層就用到內(nèi)核函數(shù)sendfile:
private FileChannel file;
@Override
public long transferTo(WritableByteChannel target, long position) throws IOException {
//......
long written = file.transferTo(this.position + position, count, target);
if (written > 0) {
transferred += written;
} else if (written == 0) {
//......
}
return written;
}