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

Netty源码分析第五章: ByteBuf

第三节: 内存分配器

内存分配器, 顾明思议就是分配内存的工具, 在netty中, 内存分配器的顶级抽象是接口ByteBufAllocator, 里面定义了有关内存分配的相关api

抽象类AbstractByteBufAllocator实现了ByteBufAllocator接口, 并且实现了其大部分功能

和AbstractByteBuf一样, AbstractByteBufAllocator也实现了缓冲区分配的骨架逻辑, 剩余的交给其子类

以其中的分配ByteBuf的方法为例, 对其做简单的介绍:

public ByteBuf buffer() {
    if (directByDefault) {
        return directBuffer();
    }
    return heapBuffer();
}

这里if (directByDefault)会判断默认创建的ByteBuf是不是一个基于直接内存的ByteBuf, 也就是direct类型的ByteBuf, 如果是, 则通过directBuffer()方法返回direct类型的ByteBuf, 否则, 会通过heapBuffer()返回heap类型的ByteBuf

跟到directBuffer()方法中:

public ByteBuf directBuffer() {
    return directBuffer(DEFAULT_INITIAL_CAPACITY, Integer.MAX_VALUE);
}

这里又调用了一个重载directBuffer方法, 其中DEFAULT_INITIAL_CAPACITY代表分配的默认容量, Integer.MAX_VALUE表示分配的ByteBuf可扩容的最大容量, 也就是Integer类型的最大值, 我们再跟进去:

public ByteBuf directBuffer(int initialCapacity, int maxCapacity) {
    if (initialCapacity == 0 && maxCapacity == 0) {
        return emptyBuf;
    }
    validate(initialCapacity, maxCapacity);
    return newDirectBuffer(initialCapacity, maxCapacity);
}

这里判断如果初始容量和最大容量都为0的话, 则返回一个emptyBuf的成员变量, emptyBuf代表一个空的ByteBuf

然后通过validate方法进行参数验证

最后newDirectBuffer创建一个Direct类型的ByteBuf, 并将初始容量和最大容量传入

在AbstractByteBufAllocator中, newDirectBuffer是一个抽象方法, 由其子类实现

protected abstract ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity);

我们回到缓冲区分配的方法:

public ByteBuf buffer() {
    if (directByDefault) {
        return directBuffer();
    }
    return heapBuffer();
}

刚才简单剖析了directBuffer()的分配, 现在在继续跟到heapBuffer()中, 看其分配heap类型的ByteBuf的抽象逻辑:

public ByteBuf heapBuffer() {
    return heapBuffer(DEFAULT_INITIAL_CAPACITY, Integer.MAX_VALUE);
}

这里同样调用了重载的heapBuffer, 并传入了初始容量和最大容量

再继续跟heapBuffer方法:

public ByteBuf heapBuffer(int initialCapacity, int maxCapacity) {
    if (initialCapacity == 0 && maxCapacity == 0) {
        return emptyBuf;
    }
    validate(initialCapacity, maxCapacity);
    return newHeapBuffer(initialCapacity, maxCapacity);
}

同样, 这里如果初始容量和最大容量都为空的话, 返回一个代表空的ByteBuf

然后通过validate方法进行参数验证

最后通过newHeapBuffer方法创建一个新的heap类型的ByteBuf

同样, newHeapBuffer方法在AbstractByteBufAllocator中也是一个抽象方法, 具体逻辑交给其子类实现

protected abstract ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity);

newDirectBuffer和newHeapBuffer两个抽象方法中, 在其子类PooledByteBufAllocator和UnpooledByteBufAllocator中都有实现

我们以UnpooledByteBufAllocator的newHeapBuffer方法为例, 看其实现:

protected ByteBuf newHeapBuffer(int initialCapacity, int maxCapacity) {
    return PlatformDependent.hasUnsafe() ? new UnpooledUnsafeHeapByteBuf(this, initialCapacity, maxCapacity)
            : new UnpooledHeapByteBuf(this, initialCapacity, maxCapacity);
}

里实现方式其实很简单, 首先通过PlatformDependent.hasUnsafe()判断当前运行环境是否能创建unsafe对象, 如果能, 则直接通过new UnpooledUnsafeHeapByteBuf(this, initialCapacity, maxCapacity)方式创建一个UnpooledUnsafeHeapByteBuf对象, 也就是一个Unsafe的ByteBuf对象

如果当前环境不能创建unsafe对象, 则通过new UnpooledHeapByteBuf(this, initialCapacity, maxCapacity)这种方方式创建一个UnpooledHeapByteBuf对象, 也就是非Unsafe的ByteBuf对象

从这里能看出, 其实在创建ByteBuf对象时, 是否创建unsafe类型的对象并不是我们自己控制的, 而是通过程序判断当前环境来决定是否创建unsafe类型的ByteBuf对象的

有关ByteBufAllocator的继承关系如下:

5-3-1

原文地址:https://www.cnblogs.com/xiangnan6122/p/10205379.html

时间: 2024-10-09 23:11:00

Netty源码分析第5章(ByteBuf)---->第3节: 内存分配器的相关文章

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

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

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

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

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

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

Netty源码分析第4章(pipeline)---->第4节: 传播inbound事件

Netty源码分析第四章: pipeline 第四节: 传播inbound事件 有关于inbound事件, 在概述中做过简单的介绍, 就是以自己为基准, 流向自己的事件, 比如最常见的channelRead事件, 就是对方发来数据流的所触发的事件, 己方要对这些数据进行处理, 这一小节, 以激活channelRead为例讲解有关inbound事件的处理流程 在业务代码中, 我们自己的handler往往会通过重写channelRead方法来处理对方发来的数据, 那么对方发来的数据是如何走到chan

Netty源码分析第4章(pipeline)---->第7节: 前章节内容回顾

Netty源码分析第四章: pipeline 第七节: 前章节内容回顾 我们在第一章和第三章中, 遗留了很多有关事件传输的相关逻辑, 这里带大家一一回顾 首先看两个问题: 1.在客户端接入的时候, NioMessageUnsafe的read方法中pipeline.fireChannelRead(readBuf.get(i))为什么会调用到ServerBootstrap的内部类ServerBootstrapAcceptor中的channelRead()方法 2.客户端handler是什么时候被添加

Netty源码分析第6章(解码器)---->第3节: 行解码器

Netty源码分析第六章: 解码器 第三节: 行解码器 这一小节了解下行解码器LineBasedFrameDecoder, 行解码器的功能是一个字节流, 以\r\n或者直接以\n结尾进行解码, 也就是以换行符为分隔进行解析 同样, 这个解码器也继承了ByteToMessageDecoder 首先看其参数: //数据包的最大长度, 超过该长度会进行丢弃模式 private final int maxLength; //超出最大长度是否要抛出异常 private final boolean fail

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

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

Netty源码分析第6章(解码器)---->第2节: 固定长度解码器

Netty源码分析第六章: 解码器 第二节: 固定长度解码器 上一小节我们了解到, 解码器需要继承ByteToMessageDecoder, 并重写decode方法, 将解析出来的对象放入集合中集合, ByteToMessageDecoder中可以将解析出来的对象向下进行传播, 这一小节带大家剖析一个最简单的解码器FixedLengthFrameDecoder, 从它入手了解码器的相关原理 FixedLengthFrameDecoder是一个固定长度的解码器, 功能就是根据固定长度, 截取固定大

Netty源码分析第2章(NioEventLoop)---->第7节: 处理IO事件

Netty源码分析第二章: NioEventLoop 第七节:处理IO事件 上一小节我们了解了执行select()操作的相关逻辑, 这一小节我们继续学习select()之后, 轮询到io事件的相关逻辑: 回到NioEventLoop的run()方法: protected void run() { for (;;) { try { switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) { case Sele