Netty源码—七、内存释放

Netty本身在内存分配上支持堆内存和直接内存,我们一般选用直接内存,这也是默认的配置。所以要理解Netty内存的释放我们得先看下直接内存的释放。

Java直接内存释放

我们先来看下直接内存是怎么使用的

ByteBuffer.allocateDirect(capacity)

申请的过程是其实就是创建一个DirectByteBuffer对象的过程,DirectByteBuffer对象只相当于一个holder,包含一个address,这个是直接内存的指针。

  • 调用native方法申请内存
  • 初始化cleaner
public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}

DirectByteBuffer(int cap) {                   // package-private
    // 省略中间代码...
    // 创建一个cleaner,最后会调用Deallocator.run来释放内存
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;
}

Cleaner这个类继承自PhantomReference,也就是所谓的虚引用,这种类型引用的特点是:

  • 使用get方法不能获取到对象
  • 只要引用的对象除了PhantomReference之外没有其他引用了,JVM随时可以将PhantomReference引用的对象回收。

JVM在回前会将将要被回收的对象放在一个队列中,由于Cleaner继承自PhantomReference,队列的实现是使用cleaner的

private static final ReferenceQueue<Object> dummyQueue = new ReferenceQueue<>();

这个队列在PhantomReference的父类Reference中使用到了,Reference这个类在初始化的时候会启动一个线程来调用cleaner.clean方法,在Reference的静态代码块中启动线程

// java.lang.ref.Reference
static {
    ThreadGroup tg = Thread.currentThread().getThreadGroup();
    for (ThreadGroup tgn = tg;
         tgn != null;
         tg = tgn, tgn = tg.getParent());
    Thread handler = new ReferenceHandler(tg, "Reference Handler");
    /* If there were a special system-only priority greater than
         * MAX_PRIORITY, it would be used here
         */
    handler.setPriority(Thread.MAX_PRIORITY);
    handler.setDaemon(true);
    // 启动ReferenceHandler线程
    handler.start();
    // 省略中间代码...
}

该线程的主要作用就是调用tryHandlePending

// java.lang.ref.Reference#tryHandlePending
static boolean tryHandlePending(boolean waitForNotify) {
        Reference<Object> r;
        Cleaner c;
        try {
            synchronized (lock) {
                if (pending != null) {
                    r = pending;
                    // ‘instanceof‘ might throw OutOfMemoryError sometimes
                    // so do this before un-linking ‘r‘ from the ‘pending‘ chain...
                    c = r instanceof Cleaner ? (Cleaner) r : null;
                    // unlink ‘r‘ from ‘pending‘ chain
                    pending = r.discovered;
                    r.discovered = null;
                } else {
                    // The waiting on the lock may cause an OutOfMemoryError
                    // because it may try to allocate exception objects.
                    if (waitForNotify) {
                        lock.wait();
                    }
                    // retry if waited
                    return waitForNotify;
                }
            }
        } catch (OutOfMemoryError x) {
            // Give other threads CPU time so they hopefully drop some live references
            // and GC reclaims some space.
            // Also prevent CPU intensive spinning in case ‘r instanceof Cleaner‘ above
            // persistently throws OOME for some time...
            Thread.yield();
            // retry
            return true;
        } catch (InterruptedException x) {
            // retry
            return true;
        }

        // Fast path for cleaners
        if (c != null) {
            // 调用clean方法
            c.clean();
            return true;
        }

        ReferenceQueue<? super Object> q = r.queue;
        if (q != ReferenceQueue.NULL) q.enqueue(r);
        return true;
}

System.gc不能回收堆外内存,但是会回收已经没有使用了DirectByteBuffer对象,该对象被回收的时候会将cleaner对象放入队列中,在Reference的线程中调用clean方法来回收堆外内存 。cleaner.run执行的是传入参数的thunk.run方法,这里thunk是Deallocator,所以最后执行的Deallocator.run方法

public void run() {
    if (address == 0) {
        // Paranoia
        return;
    }
    // 释放内存
    unsafe.freeMemory(address);
    address = 0;
    Bits.unreserveMemory(size, capacity);
}

所以最后通过unsafe.freeMemory释放了申请到的内存。

总结一下,在申请内存的时候调用的是java.nio.ByteBuffer#allocateDirect

会new DirectByteBuffer,通过Cleaner.create创建Cleaner,同时传入Deallocator作为Runnable参数,在Cleaner.clean的时候会调用该Deallocator.run来处理

Cleaner继承自PhantomReference,包含一个ReferenceQueue,在DirectByteBuffer不再使用的时候,该对象是处于Java堆的,除了该PhantomReference引用了DirectByteBuffer外,没有其他引用的时候,jvm会把cleaner对象放入ReferenceQueue队列中。

PhantomReference继承了Reference,Reference会启动一个线程(java.lang.ref.Reference.ReferenceHandler#run)去调用队列中的cleaner.clean方法。

Netty内存释放

Netty使用的直接内存的释放方式和JDK的释放方式略有不同。Netty开始释放内存的时候是调用free方法的时候

io.netty.buffer.PoolArena#free
io.netty.buffer.PoolArena.DirectArena#destroyChunk

最终释放内存的方法有两种

  1. 利用反射获取unsafe,调用Unsafe#freeMemory
  2. 利用反射获取DirectByteBuffer#cleaner,通过反射调用cleaner.clean方法

两种不同的方式依赖的条件不同,使用场景也不同

使用反射调用cleaner.clean

要满足以下条件之一的时候使用这种方式

  1. 没有可使用的直接内存
  2. 不能获取unsafe
  3. directBuffer没有传入long、int的构造方法

使用unsafe

不能使用上面这种方式的都使用unsafe

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

时间: 2024-07-31 04:53:16

Netty源码—七、内存释放的相关文章

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

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

Netty源码分析--内存模型(下)(十二)

这一节我们一起看下分配过程 1 PooledByteBuf<T> allocate(PoolThreadCache cache, int reqCapacity, int maxCapacity) { 2 PooledByteBuf<T> buf = newByteBuf(maxCapacity); // 初始化一块容量为 2^31 - 1的ByteBuf 3 allocate(cache, buf, reqCapacity); // reqCapacity = 1024 进入分配

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

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

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

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

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

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

Netty源码分析第7章(编码器和写数据)----&gt;第3节: 写buffer队列

Netty源码分析七章: 编码器和写数据 第三节: 写buffer队列 之前的小结我们介绍过, writeAndFlush方法其实最终会调用write和flush方法 write方法最终会传递到head节点, 调用HeadContext的write方法: public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception { unsafe.write(msg, prom

Netty源码分析-- 处理客户端接入请求(八)

这一节我们来一起看下,一个客户端接入进来是什么情况.首先我们根据之前的分析,先启动服务端,然后打一个断点. 这个断点打在哪里呢?就是NioEventLoop上的select方法上. 然后我们启动一个客户端. 然后我们debug看到,selectedKey的数量 = 1,说明有accept或者读写等事件发生. 接下就会进 processSelectedKeys() 我们上一节讲到,这里的attach就是NioServerSocketChannel, 我们进入 processSelectedKey(

4. Netty源码分析之Unsafe

Unsafe类实际上是Channel接口的辅助类,实际的IO操作都是由Unsafe接口完成的. 一.Unsafe继承关系图 二.AbstractUnsafe源码分析 1. register方法 register方法主要用于将当前Unsafe对应的Channel注册到EventLoop的多路复用器上,然后调用DefaultChannelPipeline的fireChannelRegisted方法,如果Channel被激活,则调用fireChannelActive方法. public final v

Netty源码阅读(一) ServerBootstrap启动

Netty源码阅读(一) ServerBootstrap启动 转自我的Github Netty是由JBOSS提供的一个java开源框架.Netty提供异步的.事件驱动的网络应用程序框架和工具,用以快速开发高性能.高可靠性的网络服务器和客户端程序.本文讲会对Netty服务启动的过程进行分析,主要关注启动的调用过程,从这里面进一步理解Netty的线程模型,以及Reactor模式. 这是我画的一个Netty启动过程中使用到的主要的类的概要类图,当然是用到的类比这个多得多,而且我也忽略了各个类的继承关系