感悟优化——Netty对JDK缓冲区的内存池零拷贝改造

NIO中缓冲区是数据传输的基础，JDK通过ByteBuffer实现，Netty框架中并未采用JDK原生的ByteBuffer,而是构造了ByteBuf。

ByteBuf对ByteBuffer做了大量的优化，比如说内存池，零拷贝，引用计数（不依赖GC），本文主要是分析这些优化，学习这些优化思想，学以致用，在实际工程中，借鉴这些优化方案和思想。

 

直接内存和堆内存

---

首先先讲一下这里面需要用的基础知识，在JVM中 内存可分为两大块，一个是堆内存，一个是直接内存。这里简单介绍一下

堆内存：

堆内存是Jvm所管理的内存，相比方法区，栈内存，堆内存是最大的一块。所有的对象实例实例以及数组都要在堆上分配。

Java的垃圾收集器是可以在堆上回收垃圾。

直接内存：

JVM使用Native函数在堆外分配内存，之后通过Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。直接内存不会受到Java堆的限制，只受本机内存影响。

Java的GC只会在老年区满了触发Full GC时，才会去顺便清理直接内存的废弃对象。

JDK原生缓冲区ByteBuffer

---

在NIO中，所有数据都是用缓冲区处理的。读写数据，都是在缓冲区中进行的。缓存区实质是是一个数组，通常使用字节缓冲区——ByteBuffer。

属性：

属性	说明
capacity	缓冲区的大小，一旦申请将不能改变
position	位置索引，表示读模式或者写模式数据的位置，读模式和写模式切换的时候position会被重置为0，positon最大可谓capacity-1。
limit	在写模式下，Buffer的limit表示你最多能往Buffer里写多少数据。读模式下，limit等于buffer的capacity
mark	标记，指一个备忘位置，调用mark()来设定mark=position，调用reset()来设定postion=mark，标记未设定前是未定义的.

使用方式：

ByteBuffer可以申请两种方式的内存，分别为堆内存和直接内存，首先看申请堆内存。

 // 申请堆内存
 ByteBuffer HeapbyteBuffer = ByteBuffer.allocate(1024);

 

很简单，就一行代码，再看看allocate方法。

    public static ByteBuffer allocate(int capacity) {
        if (capacity < 0)
            throw new IllegalArgumentException();
        return new HeapByteBuffer(capacity, capacity);
    }

 

其实就是new一个HeapByteBuffer对象。这个 HeapByteBuffer继承自ByteBuffer，构造器采用了父类的构造器，如下所示：

HeapByteBuffer(int cap, int lim) {            // package-private

        super(-1, 0, lim, cap, new byte[cap], 0);
        /*
        hb = new byte[cap];
        offset = 0;
        */
    }

//ByteBuffer构造器
  ByteBuffer(int mark, int pos, int lim, int cap,   // package-private
                 byte[] hb, int offset)
    {
        super(mark, pos, lim, cap);
        this.hb = hb;
        this.offset = offset;
    }

 

结合ByteBuffer的四个属性，初始化的时候就可以赋值capaticy,limit,position,mark，至于byte[] hb， int offsef这两个属性，JDK文档给出的解释是backing array，and array offset。它是一个回滚数组，offset是数组的偏移值。

申请直接内存：

// 申请直接内存
 ByteBuffer DirectbyteBuffer = ByteBuffer.allocateDirect(1024);

allocateDirect（）实际上就是new的一个DirectByteBuffer对象，不过这个new 一个普通对象不一样。这里使用了Native函数来申请内存，在Java中就是调用unsafe对象

    public static ByteBuffer allocateDirect(int capacity) {
        return new DirectByteBuffer(capacity);
    }

 DirectByteBuffer(int cap) {                   // package-private

        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);

        long base = 0;
        try {
            base = unsafe.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;

    }

View Code

 

申请方法不同的内存有不同的用法。接下来看一看ByteBuffer的常用方法与如何使用

ByteBuffer的常用方法与使用方式

Bytebuf的读和写是使用put（）和get（）方法实现的

// 读操作
public byte get() {
    return hb[ix(nextGetIndex())];
}

final int nextGetIndex() {
    if (position >= limit)
        throw new BufferUnderflowException();
    return position++;
}

// 写操作
public ByteBuffer put(byte x) {
    hb[ix(nextPutIndex())] = x;
    return this;
}

final int nextPutIndex() {
    if (position >= limit)
        throw new BufferOverflowException();
    return position++;
}

 

从代码中可以看出，读和写操作都会改变ByteBuffer的position属性，这两个操作是共用的position属性。这样就会带来一个问题，读写操作会导致数据出错啊，数据位置出错。

ByteBuffer提供了flip（）方法，读写模式切换，切换的时候会改变position和limit的位置。看看flip（）怎么实现的：

public final Buffer flip() {
    // 1. 设置 limit 为当前位置
    limit = position;
    // 2. 设置 position 为0
    position = 0;
    mark = -1;
    return this;
}

 这里就不重点介绍了,有些细节可以自己去深究。

 

Netty的ByteBuf

---

Netty使用的自身的ByteBuf对象来进行数据传输，本质上使用了外观模式对JDK的ByteBuffer进行封装。

相较于原生的ByteBuffer，Netty的ByteBuf做了很多优化，零拷贝，内存池加速，读写索引。

 

为什么要使用内存池？

---

首先要明白一点，Netty的内存池是不依赖于JVM本身的GC的。

回顾一下直接内存的GC：

上文提到Java的GC只会在老年区满了触发Full GC时，才会去顺便清理直接内存的废弃对象。

JVM中的直接内存，存在堆内存中其实就是DirectByteBuffer类，它本身其实很小，真的内存是在堆外，这里是映射关系。

每次申请直接内存，都先看看是否超限 —— 直接内存的限额默认(可用 -XX:MaxDirectMemorySize 重新设定)。

如果超过限额，就会主动执行System.gc(),这样会带来一个影响，系统会中断100ms。如果没有成功回收直接内存，并且还是超过直接内存的限额，就会抛出OOM——内存溢出。

继续从GC角度分析，DirectByteBuffer熬过了几次young gc之后，会进入老年代。当老年代满了之后，会触发Full GC。

因为本身很小，很难占满老年代，因此基本不会触发Full GC,带来的后果是大量堆外内存一直占着不放，无法进行内存回收。

还有最后一个办法，就是依靠申请额度超限时触发的system.gc()，但是前面提到，它会中断进程100ms,如果在这100ms的之间，系统未完成GC，仍会抛出OOM。

所以这个最后一个办法也不是完全保险的。

 

Netty使用了引用计数的方式，主动回收内存。回收的对象包括非池直接内存，和内存池中的内存。

 

内存池的内存泄露检测？

---

 Netty中使用引用计数机制来管理资源，ByteBuf实际上是实现了ReferenceCounted接口，当实例化ByteBuf对象时，引用计数加1。

当应用代码保持一个对象引用时，会调用retain方法将计数增加1，对象使用完毕进行释放，调用release将计数器减1.

当引用计数变为0时，对象将释放所有的资源，返回内存池。

Netty内存泄漏检测级别：

    禁用（DISABLED）   - 完全禁止泄露检测。不推荐。
    简单（SIMPLE）     - 告诉我们取样的1%的缓冲是否发生了泄露。默认。
    高级（ADVANCED）   - 告诉我们取样的1%的缓冲发生泄露的地方
    偏执（PARANOID）   - 跟高级选项类似，但此选项检测所有缓冲，而不仅仅是取样的那1%。此选项在自动测试阶段很有用。如果构建（build）输出包含了LEAK，可认为构建失败 
也可以使用JVM的-Dio.netty.leakDetectionLevel选项来指定泄漏检测级别。

 

内存跟踪

在内存池中分配内存，得到的ByteBuf对象都是经过toLeakAwareBuffer()方法封装的，该方法作用就是对ByteBuf对象进行引用计数，使用SimpleLeakAwareByteBuf或者AdvancedLeakAwareByteBuf来包装ByteBuf。此外该方法只对非池内存中的直接内存和内存池中的内存进行内存泄露检测。

//装饰器模式,用SimpleLeakAwareByteBuf或AdvancedLeakAwareByteBuf来包装原始的ByteBuf
protected static ByteBuf toLeakAwareBuffer(ByteBuf buf) {
        ResourceLeakTracker leak; 　　　　//根据设置的Level来选择使用何种装饰器 switch (ResourceLeakDetector.getLevel()) { case SIMPLE: 　　　　　　　　　　//创建用于跟踪和表示内容泄露的ResourcLeak对象 leak = AbstractByteBuf.leakDetector.track(buf); if (leak != null) { 　　　　　　　　　　//只在ByteBuf.order方法中调用ResourceLeak.record buf = new SimpleLeakAwareByteBuf(buf, leak); } break; case ADVANCED: case PARANOID: leak = AbstractByteBuf.leakDetector.track(buf); if (leak != null) { 　　　　　　　　　　//只在ByteBuf.order方法中调用ResourceLeak.record buf = new AdvancedLeakAwareByteBuf(buf, leak); } break; default: break; } return buf; }

实际上，内存泄露检测是在AbstractByteBuf.leakDetector.track(buf)进行的，来看看track方法的具体实现。

    /**
     * Creates a new {@link ResourceLeakTracker} which is expected to be closed via
     * {@link ResourceLeakTracker#close(Object)} when the related resource is deallocated. * * @return the {@link ResourceLeakTracker} or {@code null} */ @SuppressWarnings("unchecked") public final ResourceLeakTracker track(T obj) { return track0(obj); } @SuppressWarnings("unchecked") private DefaultResourceLeak track0(T obj) { Level level = ResourceLeakDetector.level; 　　　　　　// 不进行内存跟踪 if (level == Level.DISABLED) { return null; } if (level.ordinal() < Level.PARANOID.ordinal()) { //如果监控级别低于PARANOID,在一定的采样频率下报告内存泄露 if ((PlatformDependent.threadLocalRandom().nextInt(samplingInterval)) == 0) { reportLeak(); return new DefaultResourceLeak(obj, refQueue, allLeaks); } return null; } //每次需要分配 ByteBuf 时,报告内存泄露情况  reportLeak(); return new DefaultResourceLeak(obj, refQueue, allLeaks); }

 再来看看返回对象——DefaultResourceLeak，他的实现方式如下：

    private static final class DefaultResourceLeak
            extends WeakReference