Netty源码—六、tiny、small内存分配

tiny内存分配

tiny内存分配流程:

  1. 如果申请的是tiny类型,会先从tiny缓存中尝试分配,如果缓存分配成功则返回
  2. 否则从tinySubpagePools中尝试分配
  3. 如果上面没有分配成功则使用allocateNormal进行分配

从缓存中分配

这里以启用了缓存为例来说明,使用到的缓存类是PoolThreadCache,缓存是通过队列实现的,一个队列中存储的内存大小都是相同的

// io.netty.buffer.PoolArena#allocate(io.netty.buffer.PoolThreadCache, io.netty.buffer.PooledByteBuf<T>, int)
// 这里的cache是PoolThreadCache
if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
    // was able to allocate out of the cache so move on
    return;
}

boolean allocateTiny(PoolArena<?> area, PooledByteBuf<?> buf, int reqCapacity, int normCapacity) {
    // 缓存维护了一个队列,这个队列中存储的内存块大小都相同
    // 找到缓存之后,从队列中取出一个内存块用来初始化buffer
    return allocate(cacheForTiny(area, normCapacity), buf, reqCapacity);
}

// 查找缓存数组中缓存的内存
private MemoryRegionCache<?> cacheForTiny(PoolArena<?> area, int normCapacity) {
    // 计算出申请内存位于缓存数组中的位置,即数组下标
    int idx = PoolArena.tinyIdx(normCapacity);
    if (area.isDirect()) {
        // 使用直接内存的缓存
        return cache(tinySubPageDirectCaches, idx);
    }
    // 使用堆内存的缓存
    return cache(tinySubPageHeapCaches, idx);
}

static int tinyIdx(int normCapacity) {
    // 由于tiny缓存数组大小是32,依次对应的内存大小是16、32...,512,所以数组的下标应该是申请内存的大小除以16
    // normCapacity = normCapacity / 16
    return normCapacity >>> 4;
}

从缓存中分配内存的过程

  1. 寻找缓存tinySubPageDirectCaches
  2. 使用缓存中的chunk初始化buf

关于tiny缓存的数据结构

// tiny缓存
// 是一个SubPageMemoryRegionCache数组,默认缓存数组长度:32,依次存储的内存大小是16、32、48...,512
io.netty.buffer.PoolThreadCache#tinySubPageDirectCaches

// 初始化tiny缓存数组,数组大小是32
// static final int numTinySubpagePools = 512 >>> 4;
tinySubPageDirectCaches = createSubPageCaches(
                    tinyCacheSize, PoolArena.numTinySubpagePools, SizeClass.Tiny);

// 初始化tiny和small缓存数组
private static <T> MemoryRegionCache<T>[] createSubPageCaches(
    int cacheSize, int numCaches, SizeClass sizeClass) {
    if (cacheSize > 0) {
        @SuppressWarnings("unchecked")
        MemoryRegionCache<T>[] cache = new MemoryRegionCache[numCaches];
        for (int i = 0; i < cache.length; i++) {
            // TODO: maybe use cacheSize / cache.length
            cache[i] = new SubPageMemoryRegionCache<T>(cacheSize, sizeClass);
        }
        return cache;
    } else {
        return null;
    }
}

缓存使用队列实现,一个队列最大元素个数

DEFAULT_TINY_CACHE_SIZE = SystemPropertyUtil.getInt("io.netty.allocator.tinyCacheSize", 512);

从tinySubpagePools中分配

上面缓存中如果没有分配到内存的话,会向内存池tinySubpagePools申请,主要逻辑是:

  1. 计算tinySubpagePools数组的index,右移4,除以16(该数组长度是512>>>4)
  2. 取出index出的subpage,也就是这个index处head
  3. 从head.next查找合适的内存
  4. 找到可用内存后使用io.netty.buffer.PoolChunk#initBufWithSubpage(io.netty.buffer.PooledByteBuf

前面已经介绍过tinySubpagePools,是一个数组,数组大小是32,每个元素是一个PoolSubpage,PoolSubpage本身是一个链表,所以要在这个里面查找可用内存,先要计算出数组下表,然后找到该位置的PoolSubpage,取出这个链表的头,然后分配内存。关键代码如下

// io.netty.buffer.PoolArena#allocate(io.netty.buffer.PoolThreadCache, io.netty.buffer.PooledByteBuf<T>, int)
private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
    final int normCapacity = normalizeCapacity(reqCapacity);
    if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
        int tableIdx;
        PoolSubpage<T>[] table;
        boolean tiny = isTiny(normCapacity);
        if (tiny) { // < 512
            // 省略中间代码...
            tableIdx = tinyIdx(normCapacity);
            table = tinySubpagePools;
        } else {
            // 省略中间代码...
        }

        final PoolSubpage<T> head = table[tableIdx];

        /**
             * Synchronize on the head. This is needed as {@link PoolChunk#allocateSubpage(int)} and
             * {@link PoolChunk#free(long)} may modify the doubly linked list as well.
             */
        synchronized (head) {
            final PoolSubpage<T> s = head.next;
            // 空链表的话,head指向自己
            if (s != head) {
                assert s.doNotDestroy && s.elemSize == normCapacity;
                long handle = s.allocate();
                assert handle >= 0;
                s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
                incTinySmallAllocation(tiny);
                return;
            }
        }
        // 省略中间代码...
}

为什么上面没有没有判断head.next是否有可用的内存呢?

tinySubpagePools里面存储的是已经被分配过部分内存的PoolSubpage,PoolSubpage本身是一个链表,如果链表中除了head外有其他PoolSubpage,那么这个subpage一定有可以用的内存块,因为在PoolSubpage.allocate的时候,如果发现没有可用的内存块了,会将subpage从链表中移除。

按照normal的方式分配

如果上面两种方法都没有分配到内存,则调用allocateNormal方法来分配内存,allocateNormal获取内存的方法前面已经说过了,这里不再赘述。

small内存分配

small的分配过程和tiny内存的分配过程几乎一致

small内存分配流程:

  1. 如果申请的是tiny类型,会先从small缓存中尝试分配,如果缓存分配成功则返回
  2. 否则从smallSubpagePools中尝试分配
  3. 如果上面没有分配成功则使用allocateNormal进行分配

small内存的获取过程和tiny的方式类似,可以对照学习,这里不再详述。

原文地址:https://www.cnblogs.com/sunshine-2015/p/9380751.html

时间: 2024-08-02 17:52:07

Netty源码—六、tiny、small内存分配的相关文章

Netty源码分析第5章(ByteBuf)----&gt;第6节: 命中缓存的分配

Netty源码分析第6章: ByteBuf 第六节: 命中缓存的分配 上一小节简单分析了directArena内存分配大概流程, 知道其先命中缓存, 如果命中不到, 则区分配一款连续内存, 这一小节带大家剖析命中缓存的相关逻辑 分析先关逻辑之前, 首先介绍缓存对象的数据结构 回顾上一小节的内容, 我们讲到PoolThreadCache中维护了三个缓存数组(实际上是六个, 这里仅仅以Direct为例, heap类型的逻辑是一样的): tinySubPageDirectCaches, smallSu

Netty源码分析--内存模型(上)(十一)

前两节我们分别看了FastThreadLocal和ThreadLocal的源码分析,并且在第八节的时候讲到了处理一个客户端的接入请求,一个客户端是接入进来的,是怎么注册到多路复用器上的.那么这一节我们来一起看下客户端接入完成之后,是怎么实现读写操作的?我们自己想一下,应该就是为刚刚读取的数据分配一块缓冲区,然后把channel中的信息写入到缓冲区中,然后传入到各个handler链上,分别进行处理.那Netty是怎么去分配一块缓冲区的呢?这个就涉及到了Netty的内存模型. 当然,我们在第一节的时

Netty源码分析第5章(ByteBuf)----&gt;第3节: 内存分配器

Netty源码分析第五章: ByteBuf 第三节: 内存分配器 内存分配器, 顾明思议就是分配内存的工具, 在netty中, 内存分配器的顶级抽象是接口ByteBufAllocator, 里面定义了有关内存分配的相关api 抽象类AbstractByteBufAllocator实现了ByteBufAllocator接口, 并且实现了其大部分功能 和AbstractByteBuf一样, AbstractByteBufAllocator也实现了缓冲区分配的骨架逻辑, 剩余的交给其子类 以其中的分配

Netty源码分析第5章(ByteBuf)----&gt;第4节: PooledByteBufAllocator简述

Netty源码分析第五章: ByteBuf 第四节: PooledByteBufAllocator简述 上一小节简单介绍了ByteBufAllocator以及其子类UnPooledByteBufAllocator的缓冲区分类的逻辑, 这一小节开始带大家剖析更为复杂的PooledByteBufAllocator, 我们知道PooledByteBufAllocator是通过自己取一块连续的内存进行ByteBuf的封装, 所以这里更为复杂, 在这一小节简单讲解有关PooledByteBufAlloca

深入浅出Netty源码剖析

课程目录:任务1:课程版权声明任务2: Netty源码剖析简介任务3: Netty服务器的构建任务4: Netty客户端的构建任务5: Netty客户端实现接服务器收响应数据任务6: Netty线程模型任务7: NettyServerBootstrap启动的详细过程类图分析任务8: NioEventLoop如何开启和处理channel的Accept事件任务9: NioEventLoop接收客户端请求过程任务10: NioEventLoop接收channelread事件剖析任务11: 读半包处理分

Netty源码分析第5章(ByteBuf)----&gt;第1节: AbstractByteBuf

Netty源码分析第五章: ByteBuf 概述: 熟悉Nio的小伙伴应该对jdk底层byteBuffer不会陌生, 也就是字节缓冲区, 主要用于对网络底层io进行读写, 当channel中有数据时, 将channel中的数据读取到字节缓冲区, 当要往对方写数据的时候, 将字节缓冲区的数据写到channel中 但是jdk的byteBuffer是使用起来有诸多不便, 比如只有一个标记位置的指针position, 在进行读写操作时要频繁的通过flip()方法进行指针位置的移动, 极易出错, 并且by

Netty源码分析第6章(解码器)----&gt;第1节: ByteToMessageDecoder

Netty源码分析第六章: 解码器 概述: 在我们上一个章节遗留过一个问题, 就是如果Server在读取客户端的数据的时候, 如果一次读取不完整, 就触发channelRead事件, 那么Netty是如何处理这类问题的, 在这一章中, 会对此做详细剖析 之前的章节我们学习过pipeline, 事件在pipeline中传递, handler可以将事件截取并对其处理, 而之后剖析的编解码器, 其实就是一个handler, 截取byteBuf中的字节, 然后组建成业务需要的数据进行继续传播 编码器,

Netty源码分析第7章(编码器和写数据)----&gt;第2节: MessageToByteEncoder

Netty源码分析第七章: Netty源码分析 第二节: MessageToByteEncoder 同解码器一样, 编码器中也有一个抽象类叫MessageToByteEncoder, 其中定义了编码器的骨架方法, 具体编码逻辑交给子类实现 解码器同样也是个handler, 将写出的数据进行截取处理, 我们在学习pipeline中我们知道, 写数据的时候会传递write事件, 传递过程中会调用handler的write方法, 所以编码器码器可以重写write方法, 将数据编码成二进制字节流然后再继

Netty源码分析第8章(高性能工具类FastThreadLocal和Recycler)----&gt;第6节: 异线程回收对象

Netty源码分析第八章: 高性能工具类FastThreadLocal和Recycler 第六节: 异线程回收对象 异线程回收对象, 就是创建对象和回收对象不在同一条线程的情况下, 对象回收的逻辑 我们之前小节简单介绍过, 异线程回收对象, 是不会放在当前线程的stack中的, 而是放在一个WeakOrderQueue的数据结构中, 回顾我们之前的一个图: 8-6-1 相关的逻辑, 我们跟到源码中: 首先从回收对象的入口方法开始, DefualtHandle的recycle方法: public