(七) 提高内存分配性能,从线程缓冲分配---PoolThreadCache

从上篇文章(六) 图解netty内存池的核心分配算法—PoolArena/PoolChunk/PoolSubpage中可以知道,netty内存池在分配粒度为tiny/small/normal的内存块时,都首先尝试从线程缓冲池PoolThreadCache分配,线程缓冲分配不成功,才分配新的内存。这么做可以明显地提高内存分配的性能。

那么现在来分析,线程缓冲池中存的是什么?怎么存进去?又怎么取出来?

1. PoolThreadCache

1.1 PoolThreadCache的数据结构

PoolThreadCache的主要属性如下:

    final PoolArena<byte[]> heapArena;
    final PoolArena<ByteBuffer> directArena;

    // Hold the caches for the different size classes, which are tiny, small and normal.
    private final MemoryRegionCache<byte[]>[] tinySubPageHeapCaches;
    private final MemoryRegionCache<byte[]>[] smallSubPageHeapCaches;
    private final MemoryRegionCache<ByteBuffer>[] tinySubPageDirectCaches;
    private final MemoryRegionCache<ByteBuffer>[] smallSubPageDirectCaches;
    private final MemoryRegionCache<byte[]>[] normalHeapCaches;
    private final MemoryRegionCache<ByteBuffer>[] normalDirectCaches;

    private int allocations;

属性的概要说明
heapArena和poolArena这两个属性跟后面说的从缓冲池分配还是两码事,因为它们是表明当前请求分配内存的线程应该从哪个Arena上分配,如之前文章所说,每个通过给每个线程分配Arena,来减小资源竞争。

六个MemoryRegionCache[]数组,缓存的是之前已经分配出去的但是已经不再使用的内存,好处是如果后面需要分配相同粒度的内存,直接从缓冲池分配,以提高效率。tiny和small数组,与Arena中的tinySubpagePools数组和smallSubpagePools数组相对应:tiny数组的大小是32,使用的index从1开始,依次代表大小为16 bytes、32 bytes、48 bytes、… 、496 bytes的内存块;small数组大小为4,一次代表大小为512 bytes、1024 bytes、2048 bytes、4096 bytes的内存块。
而small数组大小是3,但只用到index=1和2两个位置。index=1缓存的内存块大小是1个page大小,即8k。index=2的位置缓存的内存块大小是2个page大小,即16k。

MemoryRegionCache内部有个队列,存放被缓存的内存块,如下:

        private final int size;
        private final Queue<Entry<T>> queue;
        private final SizeClass sizeClass;
        private int allocations;

size是队列queue的大小,对于tiny类型,队列大小是512,small的是256,normal的是64;queue是缓存内存块的队列,queue内的每个Entry对象表示被缓存的内存;sizeClass有tiny/small/normal三个取值,表明当前缓冲所缓存的内存的粒度分类;allocations表示从该缓冲分配的次数。

结合以上属性分析,可知PoolThreadCache对象的每个数组的拓扑结构如下:
在这里插入图片描述

1.2 PoolThreadCache的使用流程

创建的时机
当线程初次调用PooledByteBufAllocator的allocate方法,申请分配内存时,会创建PoolThreadCache对象,并放到线程本地存储变量PoolThreadLocalCache中,后面每次使用时,从PoolThreadLocalCache中拿出再使用。(PoolThreadLocalCache继承自FastThreadLocal,可参考:图解netty:FastThreadLocal实现原理分析

创建PoolThreadCache时,会分别为其分配一个heapArena和directArena,并初始化其各个缓冲数组。

内存块什么时候会被放到PoolThreadCache?
我们知道,当ByteBuf的引用计数器为0时,会调用deallocation()方法,释放掉内存。这时如果ByteBuf是个PooledByteBuf对象,就会调用其所属的Arena的free方法来释放内存。

在Arena的free方法中,首先尝试调用PoolThreadCache的add方法,将内存块缓存到其中:

	 SizeClass sizeClass = sizeClass(normCapacity);
	 if (cache != null && cache.add(this, chunk, nioBuffer, handle, normCapacity, sizeClass)) {
	      // cached so not free it.
	      return;
	  }

如果缓冲未满,那就会成功将内存块放到缓冲里面。

对于何时从缓冲分配内存,上一篇文章已经说明,在分配内存时都先尝试从Cache分配,能分配成功那就结束分配过程。

既然缓冲有容量限制,那么就必定有相应的清理策略,见下一小节。

何时清理缓冲里的内存
在PoolThreadCache的数据结构一节,可以看到它有一个allocations属性,同时还有个freeSweepAllocationThreshold属性:

    private int allocations;
    private final int freeSweepAllocationThreshold;

每从该Cache分配一次内存,allocations都增加一次,当次数达到freeSweepAllocationThreshold(默认是8192次)时,将allocations清零,并调用trim()方法清理缓存。这个清理动作,会清理每个数组每个MemoryRegionCache元素内的缓存。而对每个MemoryRegionCache的清理策略是:
(1)计算需要清理的内存块个数。在每个MemoryRegionCache内部,也有个分配计数器,使用队列的大小size减去该计数器,得到需要从MemoryRegionCache缓冲队列中清楚的内存块个数toFreeCount。
(2)从队列头部开始清理,一直清理toFreeCount个。

好了,对PoolThreadCache的讲解就到此结束了。由于时间关系,应该不会再写关于netty的文章了,其实netty内存池技术,还有两个重要的组件还没介绍:一个是Recycler,一个是内存泄露探测器ResourceLeakDetector。下面分别介绍它们的大概原理。

附录1 Recycler的作用与原理

Recyler其实就是一个空对象的缓存,它的作用就是在应用需要某个类的一个对象时,优先从Recyler中分配,尽量避免调用new来创建新对象(只有从Recyler无法获取到空对象时,才调用new分配新对象)。当不再使用该类对象时,回收到Recyler中。

Recyler一般作为类的静态变量,专门缓存该类的空对象,所以从数据结构的关系上看,Recyler和它缓存对象的类是一对一的关系。

从Recyler的作用,可以推断到Recyler使用的时机也很明显。当对象被释放时,调用Recyler的recycle进行回收,Recyler会把这个对象缓存起来,其实就是放到它内部的一个stack栈里面,避免对象被GC回收。当需要该类的对象时,先从Recyler内部的stack里面获取,stack没有了再调用new关键字创建新对象。

在netty中,有两个重要场景使用到了Recycler,都与内存分配有关。一个是内存池的字节缓冲对象,PooledHeapByteBuf和PooledDirectByteBuf两个类分别有一个RECYCLER静态变量,以PooledDirectByteBuf源码为例:

final class PooledDirectByteBuf extends PooledByteBuf<ByteBuffer> {

    private static final Recycler<PooledDirectByteBuf> RECYCLER = new Recycler<PooledDirectByteBuf>() {
        @Override
        protected PooledDirectByteBuf newObject(Handle<PooledDirectByteBuf> handle) {
            return new PooledDirectByteBuf(handle, 0);
        }
    };
    ......
}    

当需要PooledDirectByteBuf对象时,调用RECYCLER.get()方法获取,这个get()方法,会优先尝试从RECYCLER内部的stack获取PooledDirectByteBuf对象,获取不到,再调用RECYCLER的newObject方法,newObject方法会调用PooledDirectByteBuf构造器来创建出PooledDirectByteBuf对象。

当PooledDirectByteBuf对象的引用计数器减为0,调用deallocate()释放内存时,该PooledDirectByteBuf空对象会被放入到RECYCLER的stack中。

RECYCLER内部存放对象的stack,也是使用了ThreadLocal技术,每个线程会有一个。

**何为空对象?**这与具体的类有关,比如PooledDirectByteBuf,其对象如果持有内存,memory属性是会指向内存块的,如果将其memory属性置为null,就表明它不持有任何内存,那么它就是一个空对象。

netty中另外一个使用Recycler的场景,正是本文讲解的PoolThreadCache,具体略,读者感兴趣可自行研究其源码。

附录2 内存泄露探测器ResourceLeakDetector

netty中,如果是通过内存池分配器PooledByteBufAllocator来分配ByteBuf,那么该ByteBuf肯定会有内存泄露探测功能。如果是通过非池化的分配器UnpooledByteBufAllocator来分配内存,那么这个功能是可选的。

netty内存泄露探测主要是用于内存池的场景,原理是:
(1)在成功分配一个ByteBuf后,创建一个弱引用指向该ByteBuf,创建弱引用时会同时使用一个引用队列。
(2)ByteBuf使用了引用计数器技术,当ByteBuf使用完之后,正常情况下引用计数器变为0,这时ByteBuf对应的内存会正常被归还到内存池中,这时不会发生内存泄露。
(3)但是如果ByteBuf使用完之后没有调用其release()方法,那么其引用计数器就不会减少到0,其内存也就不会归还到内存池中。而JVM的垃圾收集器是不会感知该计数器的,计数器只是netty自己内部的东西,所以只要没有对象引用该ByteBuf了,这个对象就会被回收掉。这里,内存泄露就发生了:ByteBuf占用的内存还没归还到内存池中,就被回收掉了,那么它所占用的内存段,一直标识为已占用,但是其实没任何东西占用它。
(4)泄露探测:由于在创建ByteBuf时,同时创建了一个指向它的弱引用,以及使用了一个引用队列。当ByteBuf被GC回收时,这个弱引用就会被放到引用队列中,所以,netty只需要观察这个引用队列是否有元素,就可以知道是否发生了内存泄露。

全文完~

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值