Netty源码之内存管理(二)(4.1.44)
前面做了很多铺垫(Netty源码之内存管理(一)),带着大家熟悉了与内存分配相关的类的定义和分配逻辑。但并没有真正落实到 jemalloc 思想在源码是如何体现的。本章就是对 PoolChunk
逐字解析,死扣细节。在分析源码之前我们需要对分配的内存级别有一个清晰的定位,当分配 Huge
级别对象,直接使用 PoolChunk
包装,并没有复杂的分配逻辑。而对于 tiny&small&normal
级别来说,进行精细化的内存管理十分有必要的。
开局一张图:
PoolChunk
本质就是维护这一棵满二叉树,这棵树默认管理 16MB
内存(这个值是可以手动设置)。memoryMap[]
是可变的数组,Netty 在这个数组上逻辑构建一棵满二叉树(当然也可以用链表之类的数据结构,但是随机索引效率不高,我们可以根据数组索引快速定位到某一层的第一个节点。但链表是不能做到的),depthMap[]
表示每个节点对应的深度,这是不可变的。一个 Long
型被分成高、低两部分,高 32 位记录小内存分配信息,低 32 位记录节点下标值。当分配 normal
级别内存时,只有低 32 位信息有用,它的值表示节点序号(起始值为 1),当分配 tiny&normal
级别内存时,高、低两部分确定某个 page
下的某个 subpage
。
还有一个比较有意思的是任意节点所管理的内存大小都是 2 的次幂,因此 Netty 会对用户申请的内存大小进行规格化的原因就在这里。任意规格值(当然不能超过 PoolChunkSize
)都能找到合适的节点,除非没有节点可满足当前内存申请,那只能新创建一个 PoolChunk
。还有另外一个疑问就是如何更新 memoryMap[]
数组呢,请看大屏幕:
index 表示节点索引,value 表示对应 memoryMap[index] 。
用户第一次申请 4MB 大小内存,由于内存大小确定,因此所在的层的位置也可以通过 maxOrder - (log2(normCapacity) - pageShifts)
确定,4MB 对应层数(也可理解为深度)为 2。
内存分配过程如下,其实对应方法 allocateNode(int)
实现逻辑: 首先判断节点 1 的使用状态: memoryMap1 != unusable(12) 表示节点 1 可用,但由于层数不匹配,所以获取子树节点 2,同时判断使用状态,发现 != 12 且层数不匹配,那就继续获取子节点 4,发现 !=12 且层数匹配,所以节点 4 就用作此次内存分配的节点,并更新 memoryMap[4]=12 表示节点 4 已使用,变量 handle
的低 32 位记录子节点位置信息,同时循环更新父节点的 memoryMap,父节点的值是子节点的 memoryMap 的最小值,所以 memoryMap[2]=2,memoryMap[1] =1。这样,第一次申请 4MB 大小内存就算完成了。
第二次申请 4MB 大小内存,当在第 2 层判断节点 4 的 memoryMap 值等于 12,会判断兄弟节点 5 是否满足分配。大家好好体会。
PoolChunk 内存分配
PoolChunk 是 jemalloc3.x 算法思想的体现,里面以 allocate
开头的 API 就是内存分配算法的实现。入口方法是 allocate(PooledByteBuf, int, int)
。
allocate(PooledByteBuf, int, int)
这个方法做的事情有:
- 根据申请内存大小选择合适的分配策略。具体为如果 >=pageSize,使用
allocateRun()
方法分配,否则使用allocateSubpage()
分配,它们都会返回句柄值 handle。 - 初始化
ByteBuf
。
源码如下:
// io.netty.buffer.PoolChunk#allocate
/**
*
* @param buf 「ByteBuf」对象,它是物理内存的承托
* @param reqCapacity 用户所需内存大小
* @param normCapacity 规格值
* @return
*/
boolean allocate(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
// 低32位: 节点索引
// 高32位: 位图索引
final long handle;
// 位操作判断大小
if ((normCapacity & subpageOverflowMask) != 0) {
// #1 申请>=8KB
handle = allocateRun(normCapacity);
} else {
// #2 申请<8KB
handle = allocateSubpage(normCapacity);
}
if (handle < 0) {
return false;
}
// #3 如果「PoolChunk」存在缓存的「ByteBuffer」就复用
ByteBuffer nioBuffer = cachedNioBuffers != null ? cachedNioBuffers.pollLast() : null;
// #4 初始化ByteBuf内存相关信息
initBuf(buf, nioBuffer, handle, reqCapacity);
return true;
}
allocateRun(int)
方法 allocateRun(int) 做的事情也不多,主要有:
- 根据规格值计算所对应的深度
d
- 调用
allocateNode(d)
完成内存分配 - 更新剩余空闲值
// io.netty.buffer.PoolChunk#allocateRun
/**
* 申请大小为「norCapacity」的内存块
*/
private long allocateRun(int normCapacity) {
// #1 计算当前规格值所对应树的深度d
// log2(normCapacity): 获取当前值所对应最高位1的序号,
// pageShifts: 默认值为 13,也就是 pageSize=8192 最高位为1的序号,因为这里分配的是 >=8192,
// 所以需要减去它的偏移量,即从0开始。
// maxOrder: 默认值为 11,maxOrder - 偏移量 = 确切(合适)的树高度
// 可以想象normCapacity 从 8192 不断向上增长,那树的高度也不断变小
int d = maxOrder - (log2(normCapacity) - pageShifts);
// #2 △在深度d的节点中寻找空闲节点并分配内存
int id = allocateNode(d);
if (id < 0) {
return id;
}
// #3 更新剩余空闲值
freeBytes -= runLength(id);
// #4 返回信息
return id;
}
private static final int INTEGER_SIZE_MINUS_ONE = Integer.SIZE - 1; // 31
/**
* 获取以2为底的对数值
* 思路是数有多少个0
*/
private static int log2(int val) {
// compute the (0-based, with lsb = 0) position of highest set bit i.e, log2
// Integer.numberOfLeadingZeros(int): 返回无符号整型的最高非零位前面的0的个数(包括符号位在内)
// 31-0位数量=非0位数量,比如 0000...1000 Integer.numberOfLeadingZeros(0000...1000) = 28,
// 31-28=3,其实就是获取最高位1的序号(从右至左,起始序号为0)
return INTEGER_SIZE_MINUS_ONE - Integer.numberOfLeadingZeros(val);
}
allocateNode(int)
终于到了内存分配的重头戏,它属于节点粒度的分配逻辑。整体思路并不难,前面也通过图解讲述过,但由于采用了太多位运算所以看起来有点头晕。所以我们先熟悉一下部分位运算公式,规定
id^=1
: id 为奇数则 -1,id 为偶数则 +1。这里用来获取偶数的兄弟节点。比如 id=2,则其兄弟节点为 id^=1 = 3。id<<=1
: 相当于id=id*2
,目的是跳转到节点 id 的左子节点。比如 id = 2,它的左子节点值为 4。1<<d
: 表示 1*2 。对在任意深度为d的节点,节点的索引值在 2 到 2-1 范围内。比如深度为 1,则索引值在 [2, 3],当深度为 2,索引值在 [4, 7] 范围内。initial=-(1 << d)
: 对 2取反,目的是用来判断与目标深度值 d 是否匹配,可以把 initial 可以看成是掩码。当匹配目标深度,有 id & initial == initial,若当前深度<目标深度,有 id & initial ==0。比如目标深度为 2,那 initial=-4,当id=1时,id&initial=0,说明还没有到达目标深度,获取最左子节点(id=id*2)2,此时 2 & initial=0,说明还没有到达目标深度,继续获取最左子节点 4,此时 4&-4=4,此时就找到了目标深度。然后就可以从左到右找寻空闲节点并进行内存分配。
allocateNode(int depth)
目标是在深度 d 中找到空闲的节点并,如果存在按规则更新 memoryMap 相应节点的值并返回节点序号。思路也是比较清晰,从头结点开始判断,如果可分配但深度不匹配则获取左子节点,如果不可分配就返回 -1。继续判断左子节点是否可分配以及深度是否匹配,如果都不匹配,继续重复上面步骤。如果深度匹配但当前节点不可分配(val>d=true),那就获取兄弟节点继续重复上述步骤。如果深度匹配且当前节点可分配,则该节点就是此次申请的目标节点,并将它设置为 unusable 不可用状态,同时,按公式 memoryMap[父节点] = Min(子节点1,子节点2) 循环更新 memoryMap。
还有一个有意思的点需要注意,就是 memoryMap 存储的值,它是这棵树的核心。初始化的值以及后续更新也做得非常巧妙,我说不上来,大家慢慢休会吧。通过内存分配示意图再来休会一下上面的文字描述:
相关源码解析如下
allocateNode(int depth)
是分配 Normal
级别的核心方法,本质是维护 memoryMap[]
数组,遍历树查找空闲内存满足本次内存申请。
allocateSubpage(int)
这个方法是申请 Tiny&Small
级别内存。上一章节讲过对该内存分配的思想: 简单一句话,将某个空闲的 page 拆分成若干个 subpage,使用对象 PoolSubpage
对这些若干个 subpage 进行管理。
这里对 allocateSubpage(int)
源码做个小总结: 这个方法主要的目的是创建一个 PoolSubpage
对象,然后委托这个对象完成 tiny&small
级别内存分配。PoolChunk 在内部使用 PoolSubage[] 数组保存 PoolSubpage 对象引用。PoolSubage[] 长度和二叉树的叶子节点个数相同,它们一一对应。PoolSubpage 对象是 page 的化身,它拥有管理 pageSize 大小内存的能力。PoolChunk 只需管理 page,两者分工明确。
PoolSubpage 内存分配
PoolSubpage 内部相关变量之前已经解释过,在这里解释的。它管理内存的逻辑是将 pageSize 大小的内存块等分成若干个子块,子块个数是根据本次申请内存大小所决定,比如申请 1KB 内存,那么会找到一个空闲的 page 并将其拆分成 8 等份(8KB/1KB=8)。并使用位图记录每份子块的使用状态,1 表示已使用,0 表示未使用。最多可分为 512 等份,底层使用 long[] 数组存储位图信息。64 位的句柄值的高 32 位存储位信息,低 32 位存储储节点索引值。因此,核心的问题是如何使用 long[] 数组记录使用情况呢?
源码之下无秘密:
bitmap 填充示意图
小结上面的源码: PoolSubpage 使用 8 个 long 值存储子块的使用情况,句柄高 32 位存储位图索引值,低 32 位存储 节点索引值。通过大量的位运算提高了性能,通过源码阅读,也提升了位编程应用技巧。
这有一个关于 PoolSubpage 的是如何和 PoolArena 配合使用,因为我们知道,PoolArena 也存有 PoolSubpage[] 数组对象,这些数组对象是怎么被添加的呢?答案在在初始化 PoolSubpage 时就添加到对应的 PoolArena#poolsubpage[] 中了。源码如下:
// io.netty.buffer.PoolSubpage
/**
* 「PoolSubpage」构造器
* @param head 从「PoolArena」对象中获取「PoolSubpage」结点做头结点
* @param chunk 当前「PoolSubpage」属性的「PoolChunk」对象
* @param memoryMapIdx 所属的「Page」的节点值
* @param runOffset 对存储容器为「byte[]」有用,表示偏移量
* @param pageSize 页大小,默认值为: 8KB
* @param elemSize 元素个数
*/
PoolSubpage(PoolSubpage<T> head,
PoolChunk<T> chunk,
int memoryMapIdx, int runOffset, int pageSize, int elemSize) {
this.chunk = chunk;
this.memoryMapIdx = memoryMapIdx;
this.runOffset = runOffset;
this.pageSize = pageSize;
bitmap = new long[pageSize >>> 10]; // pageSize / 16 / 64
// 添加到「head」链表中
init(head, elemSize);
}
// 初始化「PoolSubpage」
void init(PoolSubpage<T> head, int elemSize) {
doNotDestroy = true;
this.elemSize = elemSize;
if (elemSize != 0) {
// 初始化各类参数
maxNumElems = numAvail = pageSize / elemSize;
nextAvail = 0;
// 根据元素个数确定所需要bitmap个数,即确认「bitmapLength」值
bitmapLength = maxNumElems >>> 6;
if ((maxNumElems & 63) != 0) {
bitmapLength ++;
}
for (int i = 0; i < bitmapLength; i ++) {
bitmap[i] = 0;
}
}
// 添加至双向链表中,供后续分配使用
addToPool(head);
}
private void addToPool(PoolSubpage<T> head) {
assert prev == null && next == null;
prev = head;
next = head.next;
next.prev = this;
head.next = this;
}
以上,就是对 PoolSubpage 内存分析的源码解析,理清思路,功能拆解之后并不困难。
PoolChunk 如何回收内存
讲完了物理内存分配,还没有讲 PoolChunk 是如何回收内存。
// io.netty.buffer.PoolChunk#free
/**
* 「PoolChunk」释放「handle」表示的内存块。
* 本质是修改对应节点的「memoryMap」值。
* 参数「nioByteBuf」如果不为空,则会放入「Deque」队列中缓存,减少GC
*/
void free(long handle, ByteBuffer nioBuffer) {
// #1 获取句柄「handle」低32位数值,该值表示节点id
int memoryMapIdx = memoryMapIdx(handle);
// #2 获取句柄「handle」高32位数值,该值表示bitmap索引值
int bitmapIdx = bitmapIdx(handle);
// #3 如果bitmqpIdx不为0,说明当前属于subpage释放
if (bitmapIdx != 0) { // free a subpage
PoolSubpage<T> subpage = subpages[subpageIdx(memoryMapIdx)];
assert subpage != null && subpage.doNotDestroy;
// #4 别忘记,「PoolArena」对象中也存有「PoolSubpage」的引用哦
PoolSubpage<T> head = arena.findSubpagePoolHead(subpage.elemSize);
synchronized (head) {
// 交给「PoolSubpage」专业人员释放吧
// 0x3FFFFFFF: 0011 1111 1111 1111 1111 1111 1111 1111,
// bitmapIdx & 0x3FFFFFFF: 保留低30位的值
// 为什么要抹去最高2位呢?因为生成handle是通过 |0x4000000000000000L 操作
if (subpage.free(head, bitmapIdx & 0x3FFFFFFF)) {
return;
}
}
}
// #5 更新空闲内存信息
freeBytes += runLength(memoryMapIdx);
// #6 更新memoryMap信息
setValue(memoryMapIdx, depth(memoryMapIdx));
// #6 循环更新父节点的值
// 注意: 当更新父节点值时,有可能遇到两个兄弟节点的值都为初始值,
// 此时,父节点的值也为初始化而非两者之中最小值
updateParentsFree(memoryMapIdx);
// #7 缓存「ByteBuffer」对象
if (nioBuffer != null && cachedNioBuffers != null &&
cachedNioBuffers.size() < PooledByteBufAllocator.DEFAULT_MAX_CACHED_BYTEBUFFERS_PER_CHUNK) {
cachedNioBuffers.offer(nioBuffer);
}
}
// 无符号右移32位即可
private static int bitmapIdx(long handle) {
return (int) (handle >>> Integer.SIZE);
}
从源码可看出,PoolChunk 回收一块内存十分简单。回收 PoolSubpage 稍微麻烦一点,因为还需要和 PoolArena 中的 PoolSubpage 保持同步。
PoolSubpage 如何回收内存
// io.netty.buffer.PoolSubpage#free
/**
*「PoolSubpage」释放内存块
* 目标是修改相应「bitmap」的值
*
* @param head 来自「PooArena#PoolSubpage[]」数组的head节点
* @param bitmapIdx bitmap索引值
*/
boolean free(PoolSubpage<T> head, int bitmapIdx) {
if (elemSize == 0) {
return true;
}
// 确认bitmap[] 数组索引值
int q = bitmapIdx >>> 6;
// 确认在64位中的哪一位
int r = bitmapIdx & 63;
assert (bitmap[q] >>> r & 1) != 0;
// 修改对应位为0
bitmap[q] ^= 1L << r;
// 设置可用位信息,待下次分配时直接使用
setNextAvail(bitmapIdx);
// 因为当numAvail=0时,表示无可用内存块,则会从「PoolArena#PoolSubpage[]」数组中移除
// 这次添加后就可以从新回到「PoolArena[]」队列中
if (numAvail ++ == 0) {
// 添加队列
addToPool(head);
return true;
}
if (numAvail != maxNumElems) {
// 还没有到达饱和,即完成这次分配后还有可用空闲,那直接返回
return true;
} else {
// 达到饱和,无内存块可用
if (prev == next) {
// 如果当前链表只有这么一个PoolSubpage对象,就不移除了
return true;
}
// 移除链表
doNotDestroy = false;
removeFromPool();
return false;
}
}
PoolSubpage 需要照顾到 PoolArena 的 PoolSubpage[] 变量,所以稍微代码量多一点。但逻辑十分清楚。看代码就十分明白,我就不强行总结了。
如何回收整个 PoolChunk
核心代码在 PoolArena
,根据有无 Cleaner
释放内存 memory
对象即可。
// io.netty.buffer.PoolArena.DirectArena#destroyChunk
@Override
protected void destroyChunk(PoolChunk<ByteBuffer> chunk) {
if (PlatformDependent.useDirectBufferNoCleaner()) {
PlatformDependent.freeDirectNoCleaner(chunk.memory);
} else {
PlatformDependent.freeDirectBuffer(chunk.memory);
}
}
小结
Netty 的内存回收是庞大的,两篇文章从 ByteBuf 体系结构讲到源码级的内存分配实现,似乎还是没有讲全讲透。这里只不过把最核心的代码拧出来给大家口味,最终还是希望看到这些文章的各位 DEBUG 调试走一遍。我深知自己的知识能力水平有限,文章部分地方的表达能力欠缺,有些简单的地方描述过于复杂,而恰恰需要讲清楚的地方一笔带过,敬请读者斧正。