netty5学习笔记-内存池3-PoolChunkList

前面我们介绍了PoolChunk以及针对page的更细粒度的PoolSubpage，其实在chunk的上层还有一个管理类：PoolChunkList，PoolChunkList负责管理多个chunk的生命周期，在此基础上对内存分配进行进一步的优化，那它是如何去做的呢？我们来简单的了解下，先看看它的几个属性：

 

PoolArena<T> arena; // 这个东西又出现了，看来是个终极boss啊，后面再提
// 没有list还有自己的next和prev节点，最终组成一个list的link list
PoolChunkList<T> nextList;
PoolChunkList<T> prevList;

// chunk有prev和next两个属性，因此这里只用一个节点就可以维护一个chunk链
PoolChunk<T> head;
// 当前list中的chunk最小使用比例
int minUsage; 
// 当前list中的chunk最大使用比例
int maxUsage; 

上面第二行第三行出现了nextList,prevList，可以想到在netty内存分配(其实并不是netty发明的，这里只是代称，不要太纠结）里，除了chunk是被一个list管理的，连list本身也组成了一个更大的list。 为什么这么做了，先不急，我们先简单的看下PoolChunkList中的方法：

 

        // 为buf分配指定大小的内存
    boolean allocate(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
	// 如果list中没有chunk则直接返回，看来这个list本身没有创建chunk的能力啊，只是负责维护chunk链。
        // PoolChunkList旁白：我不是内存的创建者，只是内存的搬运工
       if (head == null) {
            return false;
        }

	// 我们一个一个chunk开始找
        for (PoolChunk<T> cur = head;;) {
            long handle = cur.allocate(normCapacity);
            if (handle < 0) {
		// handle < 0表示分配失败，继续到下一个chunk尝试
                cur = cur.next;
                if (cur == null) {
                    return false;
                }
            } else {
		// 分配成功则将分配到的资源赋给ByteBuf
                cur.initBuf(buf, handle, reqCapacity);
		// 当前chunk的使用量超过一个上限阈值，则将其从当前list转移到下一个list
                if (cur.usage() >= maxUsage) {
                    remove(cur);
                    nextList.add(cur);
                }
                return true;
            }
        }
    }

这段代码有一处比较重要，当一个chunk的用量超过一定的比例，会将该chunk从当前list挪到下一个list中，这样挪有什么好处呢？ 我们知道chunk本身是从连续的内存中分配一小段连续的内存，这样实际使用内存者读写很方便，然而这种策略也带来了一个坏处，随着内存的不断分配和回收，chunk中可能存在很多碎片。 碎片越来越多后我们想分配一段连续内存的失败几率就会提高。针对这种情况我们可以把使用比例较大的chunk放到更后面，而先从使用比例更小的chunk中更早，这样成功的几率就提高了。然而光把chunk往后放是不科学的，因为随着内存的释放，原先被严重瓜分的chunk中会存在越来越多的大块连续内存，所以还得在特定条件下把chunk从后往前调。调整的时机当然就是在内存释放的时候了：

 

    // 释放指定chunk内的指定page或page内的subpage
    void free(PoolChunk<T> chunk, long handle) {
        // handle代表了chunk中的某个page
        chunk.free(handle);
	// 用量少于阈值则从当前list移到前一个list,如果不存在前一个list,则销毁chunk
        if (chunk.usage() < minUsage) {
            remove(chunk);
            if (prevList == null) {
                // 从这里我们可以看出在一个chunk经历了一些列的分配内存、释放内存之后，list会将整个chunk释放掉
                // 这样如果在流量高峰期分配了较多内存，随着流量的慢慢回落，内存会慢慢的释放出来。
               assert chunk.usage() == 0;
                arena.destroyChunk(chunk);
            } else {
                prevList.add(chunk);
            }
        }
    }

上面的代码可以看到，一个chunk最终是会被释放的，但释放的条件是当前chunk已经没有内存被使用了，所以我们必须保证在这个可以释放的PoolChunkList的minUsage=0，否则就会出现在使用中的chunk被回收的状况。

看完上面两个方法，我们会发现一个chunk的生命周期并不是在一个固定的list中的，随着内存的分配和释放，他也会进入到不同的list中去。这样我们就必须得注意，两个相邻的PoolChunkList,前一个list的maxUsage和后一个list的minUsage的值必须得有一段交叉得值来缓冲，否则会出现某个usage在临界值的chunk不停的在两个list之间来回移动。比如前一个list是【0,50】则后一个list可以是【25-75】而不能是【50-75】。同时也要注意尾节点上的maxUsage一定要等于100，这样chunk占满后才不会被继续往后挪（后面也没有可用list了）。

从前面的allocate方法可以看出，PoolChunkList本身没有chunk的创建，因此还需要给外部开放一个添加chunk的方法：

 

	// 增加节点
    void add(PoolChunk<T> chunk) {
	// 如果超过当前list的上限阈值，则放入下一个list
        if (chunk.usage() >= maxUsage) {
            nextList.add(chunk);
            return;
        }

        chunk.parent = this;
        if (head == null) {
	    //  不存在头结点则该节点作为头结点
            head = chunk;
            chunk.prev = null;
            chunk.next = null;
        } else {
	    // 存在头结点则将该节点放到头结点之前，该节点成为头结点。
	    // 刚放入的节点使用比例相对更小，分配到资源的可能性更大，因此放到头结点
            chunk.prev = null;
            chunk.next = head;
            head.prev = chunk;
            head = chunk;
        }
    }

移除方法(remove)比较简单就是从list中去掉该chunk，并改变相邻节点的指向，这里就不贴代码了。一个chunk被移除后有三种可能的去向：

1、由于使用量增大被添加到后面的list中；

2、由于使用量减小被添加到前面的list中；

3、由于所有内存被释放而直接被释放(destroy)。

先小小的总结下，PoolChunkList主要是为了提高内存分配的效率，每个list中包含多个chunk，而多个list又可以形成一个大的link list，在进行内存分配时，我们可以先从比较靠前的list中分配内存，这样分配到的几率更大。在高峰期申请过多的内存后，随着流量下降慢慢的释放掉多余内存，形成一个良性的循环。需要注意的时由于需要对无用的chunk进行释放，PoolChunkList形成的link list并不是一个完整的双向链表，而是一个包含出口的链表（这里说法可能不够准确，意思就是这个双向链表中的其中一个分头结点的节点只有一个next节点没有prev节点。

最后我们看看加入list后的样子：