netty源码阅读之ByteBuf之内存subpage级别内存的分配

朴灿烈づ我的快乐病毒、 2022-05-13 01:28 169阅读 0赞

subpage级别的内存分配的主要方法为：allocateTiny()。

主要分为以下三个步骤：

1、定位一个subpage对象

2、初始化subpage

3、初始化pooledByteBuf

这一次，我们的用户代码是分配16B的内存

public class Test {
        public static void main(String[] args) {
            PooledByteBufAllocator allocator = PooledByteBufAllocator.DEFAULT;
            allocator.directBuffer(16);
        }
    }

### 一、定位一个subpage对象  ###

毫无疑问，tiny加上第一次分配不会有cache的，我们走到了这里：

![70][]

我们看tinyIdx的实现：

static int tinyIdx(int normCapacity) {
            return normCapacity >>> 4;
        }

也就是，normCapacity向右移动4位。

然后把tinySubpagePools赋给table。这个是什么意思呢？先看tinySubpagePools的构成，其实和之前MemoryRegionCache的tiny类型的组成类似，是由一个从0到496b的数组组成的。

tinySubpagePools（在arena里面）：

tiny\[32\]=\{0,16B,32B,48B,...,480B,496B\}

由于tinySubpagePools是以0为首项，16为公差的等差数列。16右移4位也就是16除以16就是1，所以取tinySubpagePools的第二位，也就是下标为1，对的。

然后继续step over

![70 1][]

我们取到table的index为tableIdx的tiny数组的节点也就是，tinySubpagePools的第二个节点，容量为16。

继续往下走，

![70 2][]

s!=head这个条件是不满足的，我们会直接走到allocateNormal。

这里先解释一下，我们知道jdk1.7之前，hashmap的组成是数组加链表。这个tinySubpagePools也是一样的。现在index为1的位置只有一个节点，head.next还是自己，所以不走这里条件里面。继续看allocateNormal(buf,reqCapacity,normCapacity)：

![70 3][]

流程和page的是一样的，不过在c.allocate这里有所不同，进入：

![70 4][]

这一次就进入了allocateSubpage，上一篇是allocateRun()，然后进入allocateSubpage()：

![70 5][]

从第11层开始进入，所以取maxOrder，有一段注释：

subpages are only be allocaed from pages i.e.,leaves d:11

这里就是说，subpage只能从叶子节点也就是8k为单位的节点分配，我们又拿这个图来：

![846961-20180726234953241-661643120.png][]

也就是在8k的这些节点里面分配subpage，说得很明白：

![70 6][]

在memoryMap里面，第2048个节点是能够分配subpage的，验证了我们的说法。

继续往下走：

![70 7][]

我们刚刚说过了tinySubpagePools是数组加链表的方式，我们使用的是index为1的节点，这个节点刚开始是没有数的，所以subpage为空，所以进去新建一个：

![70 8][]

我们看PoolSubpage的构造函数：

![70 9][]

我们首先要给chunk赋值，让PoolSubpage知道自己属于哪个chunk。然后属于memoryMapIdx里面的第几个memoryMapIdx，偏移量是多少，pageSize的大小为8192也就是8k。

我们注意到elemSize=16，也就是我们要分配的内存大小，进入init：  
![70 10][]

刚刚说的elemSize在这里用上了，根据需要分配的大小，把pageSize分配为多少等分：

maxNumElems=numAvail=pageSize/elemSize;

然后它的bitmap也进行初始化，未使用就标记为0，使用就标记为1，这里是初始化，所以都是未使用，都为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;
        }

也就是，把这个节点和head节点组成双向链表。

### 二、初始化subpage ###

回来这里：

![70 11][]

进入allocate方法：

![70 12][]

上面的那些操作就是通过一定的算法找到bitmapIdx，toHandle(bitmapIdx)这个方法很关键：

private long toHandle(int bitmapIdx) {
            return 0x4000000000000000L | (long) bitmapIdx << 32 | memoryMapIdx;
        }

这里的操作就是bitmapIdx左移32位，或上0x4000000000000000，最后或上memoryMapIdx。

也就是吧memoryMapIdx作为低32位，bitmapIdx作为高32位，拼接起来。

memoryMapIdx就是chunk里面page的位置，或上0x4000000000000000的时候，在[上一篇文章][Link 1]bitmapIdx(handle)是的时候，得到的值才能不为0。

拿到的这个handle就是：在一个chunk里面第几个节点，然后节点的第几个subpage，也就是能够拿到一块内存里面的哪一块连续内存。

拿到了之后，就给ByteBuf进行初始化：

### 三、初始化pooledByteBuf ###

最后回到这里：

![70 13][]

进去：

![70 14][]

刚刚说的，若是subpage的，handle为4开头的大数，bitmapIdx()之后，bitmapIdx不为0，所以等下会走initBufWithSubpage这个方法：

![70 15][]

然后继续进入：

![70 16][]

我们看runOffset(memoryMapIdx)+(bitmapIdx&0X3FFFFFFF)\*subpage.elemSize这个表达式的值：

runOffset(memoryMapIdx)因为没有偏移量，所以为0（因为是page的第一个节点，page没有偏移）；(bitmapIdx&0X3FFFFFFF)为page的初始位置，如果现在是page里面的第1块，所以(bitmapIdx&0X3FFFFFFF)为0，如果是第2块，(bitmapIdx&0X3FFFFFFF)为1，乘上subpage.elemSize也就是16b之后，偏移量也是对的。

page的偏移加上subpage的偏移，最终就是真个内存的偏移量。把这个偏移量传递给buf，那buf在进行内存读写的时候，就可以基于这个偏移量进行内存的读写，通过这些值去初始化buf。

![70 17][]

最后，我们就把这个流程走完了。

[70]: /images/20220513/c076d23b2f0746c5a1992d5750809bc9.png
[70 1]: /images/20220513/73b15c1574ca426ba96442b956bf5d95.png
[70 2]: /images/20220513/1d570b470c1e4496bab032547d743d52.png
[70 3]: /images/20220513/9fbde78bf14c4b188abbd7d91b633648.png
[70 4]: /images/20220513/ef6ce2c7d47947a0b3b583653894eb61.png
[70 5]: /images/20220513/04bdea650ed44c299ace11832f2b3205.png
[846961-20180726234953241-661643120.png]: /images/20220513/fba4c38e9fbd4b95a00f690b0a882683.png
[70 6]: /images/20220513/5ee200fdfca34859977c8b302f9fb748.png
[70 7]: /images/20220513/dbaf2a79f6d04b65a58308995f149f7e.png
[70 8]: /images/20220513/9c2f301c15d64a2891cb244424962536.png
[70 9]: /images/20220513/b18c2eabbe89401dad92930c186b6259.png
[70 10]: /images/20220513/6d37d7fe6f1e411f8f2dd93676aeb595.png
[70 11]: /images/20220513/7303c8a40f4b4e52b73663579c6fffeb.png
[70 12]: /images/20220513/ea30af3916d748c59332cec4e3282475.png
[Link 1]: https://blog.csdn.net/fst438060684/article/details/82532093
[70 13]: /images/20220513/8674d87e6f9845a4bf3d92b3654ddc49.png
[70 14]: /images/20220513/e3b4c041cd074bd6bf0ea59f57d5e23e.png
[70 15]: /images/20220513/c948d6cd448140368cd734684c144f85.png
[70 16]: /images/20220513/64beb791070c4a6fba7e4f321f06a731.png
[70 17]: /images/20220513/cd28247f29034309bf05617035e6099c.png