Netty 的内存管理

  • Post author:
  • Post category:其他


原文地址

mp.weixin.qq.com



说明

在学习 Netty 的时候,ByteBuf 随处可见,但是如何高效分配 ByteBuf 还是很复杂的,Netty 的池化内存分配这块还是比较难的,很多人学习过,看过但是还是云里雾里的,本篇文章就是主要来讲解:**Netty 分配池化的堆外内存的细节,**期待可以让你明白!!!


由于为了更好的表达,文章中的图我最少画了 6 小时,画的不熟悉,并且也强调一些细节上。

由于该源码中涉及到大量的二进制操作,建议看看我之前写的 2 篇二进制文章:

java 二进制相关基础



二进制实战技巧



ByteBuf 重要性

ByteBuf 在 Netty 中一直存在,读写必备!

ByteBuf 是 Netty 的数据容器,高效分配 ByteBuf 至关重要!


Netty 从 socket 读取数据。


Netty 准备把数据写到 socket 中去。


通过这里我们就可以看到,再把数据写 socket 的之前会判断是否是堆外内存,如果不是会构造一个 directbuffer 对象的,细节代码如下:

if (msg instanceof ByteBuf) {
            ByteBuf buf = (ByteBuf) msg;
            if (buf.isDirect()) {
                return msg;
            }

            return newDirectBuffer(buf);
        }



所以本篇文章就是主要来讲解:**Netty 分配池化的堆外内存的细节,**其实分配堆内存的细节很多也是类似的。


备注:

为什么不是堆外内存还要转堆外内存,为什么加这个判断,我之前也不理解,忽然有天和涤生大佬讨论,讨论讨论就清晰了,后续有空写篇。



总览


本次主要讨论的是关于池化内存的分配

,PooledByteBufAllocator 就是 netty 分配池化内存的操作入口。

其提供对外常用操作 api:

Netty 在发送数据的时候会判断是否是堆外内存,如果不是会进行封装的:

所有这里我们以**分配池化的堆外内存为例,进行本文说明。**池化的堆内存分配其实流程都差不多的。

下面我们来看看分配示例 demo:

public static void main(String[] args) {
    ByteBufAllocator alloc = PooledByteBufAllocator.DEFAULT;

    //tiny规格内存分配 会变成大于等于16的整数倍的数:这里254 会规格化为256
    ByteBuf byteBuf = alloc.directBuffer(254);

    //读写bytebuf
    byteBuf.writeInt(126);
    System.out.println(byteBuf.readInt());

    //很重要,内存释放
    byteBuf.release();
}


后续我们都会根据这段简单的 demo 进行分析。



操作入口类

PooledByteBufAllocator 的初始化:

进去之后可以看到核心类的一初始化操作:

分配理论是 jemalloc,可以理解为 java 版本的 jemalloc 实现。



PoolThreadCache

通过上图可以清晰的了解到 PoolThreadCache 的主要数据结构。

开始的时候,这些 Cache 里面都是没有值的,只有在调用 free 释放的时候(在后续释放内存中会讲解),才会把之前分配的内存大小放到该 cache 的 queue 里面,其实每次分配的时候都是先看看是否缓存里面有,如果有直接返回,没有则进行正常的分配流程(内存分配会讲解)。

我们来看看 PoolArena directArena 内容:

下面我们来看看 PoolArena 结构。



PoolArena

通过下图可以清晰的了解到 PoolArena 的主要数据结构。

在 PoolArena 里面涉及到 PoolChunkList 和 PoolSubpage 对应的结构有 PoolChunk 和 PoolSubpage,我们来详细的看看这 2 块内容。



PoolChunk

第一次的时候,PoolChunkList、PoolSubpage 都是默认值,需要新增一个 Chunk,默认一个 Chunk 是 16M。内部会结构是完全二叉树一共有 4096 个节点,有 2048 个叶子节点(每个叶子节点大小为一个 page,就是 8k),非叶子节点的内存大小等于左子树内存大小加上右子树内存大小。


完全二叉树结构如下:

这颗完全二叉树在 java 中是使用数组来进行表示的。

唯一需要注意的是,下标是从 1 开始而不是 0.


depthMap

的值初始化后不再改变,

memoryMap

的值则随着节点分配而改变。

这个值太多就不都截图了,就是把上面那颗完全二叉树用数组表示了而已,只是值存的不是节点的下标而是存的树的深度而已。

depthMap 数组值为 0 表示可以分配 16M 空间,如果为 1 表示可以分配 8M,,如果为 2 表示嗯可以分配 4M,如果为 3 表示可以分配 2M …………………… 如果为 11 表示可以分配 8k 空间。


如果该节点已经分配完成,就设置为 12 即可。

怎么确定需要分配的大小在深度是多少?

如果需要分配的内存规格化之后,是小于 8k,那么在 8k 上面分配即可(即深度为 11)。

如果为 8k 或者大于 8k 那么通过下面代码就可以定位到深度了:

int d = maxOrder - (log2(normCapacity) - pageShifts);


知道深度之后,怎么进行定位到那个节点呢???

找到该节点之后,先把该节点显示占用,在更新起父节点父节点的父……………… 如下:



SubpagePool

上面的图就是关于 SubpagePool 的内存结构了。我们在分配 page 的时候,根据 memoryMap 对于的值就知道是否被分配了,那么如果是 subpagePool 呢?

subpagePool 分为 2 类:tinySubpagePools 和 smallSubpagePools,大小对于也对于上面的图里面了,每类都是固定大小的,如果分配 256b 的大小,那么一个 page 就是 8k,8*1024/256 = 32 块。那么怎么怎么表示每个还被分配了呢?

private final long[] bitmap;


由于一个 long 占用的字节数为 64,我们这里仅仅是需要表示 32 个,所以使用一个 long 即可了,二进制每位 1 表示已经使用了,0 表示还未使用。

由于 subpage 不仅仅需要定位到完全二叉树在那个节点,还需要知道在 long 的第几个 并且是第几位,所以要复杂一些:

通过一个 long 的前 32 位来表示 subpage 的第几个 long 的第几位上面,通过后 32 来表示在完全二叉树的那个节点上面,完美。



分配核心

分配入口:ByteBuf byteBuf = alloc.directBuffer(256);

进行跟进代码:

我们来看:PooledByteBuf buf = newByteBuf(maxCapacity);

构建 PooledByteBuf 对象。最后返回 PooledByteBuf 对象。

我们来看下类继承结构:

所有 ByteBuf byteBuf = alloc.directBuffer(256); 这句话是没有什么问题的,不会报错。

我们来看看 newByteBuf(maxCapacity) 的细节实现:

这里借助了 Netty 增加实现的 Recycler 对象池技术。Recycler 设计也非常精巧,后续可以专门写篇 Recycler 文章,今天不是重点,

我们只要知道由于分配 PolledByteBuf 对象的代价有点大,如果需要频繁使用到 PolledByteBuf 对象,并且对性能有所要求,那么池化技术是一个不错的选择

(比如我们以前使用的线程池、数据库连接池等都是类似道理),**池化技术在一定程度上面减少了频繁创建对象带来的性能开销。**其实这个类似的思想非常常见(比如我们查询数据库成本高,缓存到 redis,思路也是一样的),在本篇后续中还可以体会到(PoolThreadCache)。

通过 PooledByteBuf buf = newByteBuf(maxCapacity); 仅仅是获取到了一个初始对象而已。

分配的核心在:allocate(cache, buf, reqCapacity);

  • 先尝试在 1 步骤 进行分配,根据不同的类型定位到不同的 Caches,如果有进行分配直接返回。

  • 如果 1 步骤 分配不了,进行 2 步骤上面分配。

2 步骤分配细节:看看需要分配的是什么类型 page 还是 subpage,如果是 subpage 在根据看看是 tinySubpagePools 还是 smallSubpagePools,找到对应的槽位,看看链表里是否有可用的 PoolSubpage,如果有就进行分配修改标记退出,如果没有就现需要在先分配一个 page 了,根据 chunklist 的这些看看是否有合适的,如果有合适的,那么在这些已经有的 chunk 上面进行分配一个 page (分配 page 也是这个情况了)

之后在根据分配到的 page,进行该请求大小的分配 (由于一个 page 可以存储很多同大小的数量)需要用 long 的位标记,表示该位置分配了,并且修改完全二叉树的父等值,分配结束。如果没有 chunk 那么需要新分配一块 chunk 之后重复上面步骤即可。



释放核心

释放入口 :byteBuf.release();

进行跟进代码:

通过这段代码我们就这段放入到相应的 queue 了:

缓存到了对应的 Cache 的 queue 里面了。