Netty源码分析之ByteBuf(一)—ByteBuf中API及类型概述
ByteBuf是Netty中主要的数据容器与操作工具,也是Netty内存管理优化的具体实现,本章我们先从整体上对ByteBuf进行一个概述;
AbstractByteBuf是整个ByteBuf的框架类,定义了各种重要的标志位与API供具体的实现类使用与实现;下面我们就从AbstractByteBuf类入手对ByteBuf的读写机制与API进行一个简单的介绍
private static final InternalLogger logger = InternalLoggerFactory.getInstance(AbstractByteBuf.class); private static final String LEGACY_PROP_CHECK_ACCESSIBLE = "io.netty.buffer.bytebuf.checkAccessible"; private static final String PROP_CHECK_ACCESSIBLE = "io.netty.buffer.checkAccessible"; static final boolean checkAccessible; // accessed from CompositeByteBuf private static final String PROP_CHECK_BOUNDS = "io.netty.buffer.checkBounds"; private static final boolean checkBounds; static { if (SystemPropertyUtil.contains(PROP_CHECK_ACCESSIBLE)) { checkAccessible = SystemPropertyUtil.getBoolean(PROP_CHECK_ACCESSIBLE, true); } else { checkAccessible = SystemPropertyUtil.getBoolean(LEGACY_PROP_CHECK_ACCESSIBLE, true); } checkBounds = SystemPropertyUtil.getBoolean(PROP_CHECK_BOUNDS, true); if (logger.isDebugEnabled()) { logger.debug("-D{}: {}", PROP_CHECK_ACCESSIBLE, checkAccessible); logger.debug("-D{}: {}", PROP_CHECK_BOUNDS, checkBounds); } } static final ResourceLeakDetector<ByteBuf> leakDetector = ResourceLeakDetectorFactory.instance().newResourceLeakDetector(ByteBuf.class); int readerIndex; int writerIndex; private int markedReaderIndex; private int markedWriterIndex; private int maxCapacity;
在上面的代码中,我们需要知道ByteBu维护了两个不同的索引readerIndex与writerIndex,这两个索引默认都是从0开始,一个用于读取,一个用于写入。
当你从ByteBuf读取数据时,readerIndex会递增已经读取的字节数,同理当你写入数据时,writerIndex也会随之递增。可以说ByteBuf中各种读写API都是基于readerIndex与writerIndex来控制的。从索引操作上,ByteBuf中API基本分为两大部分,会引发索引值递增的read(读)和write(写操作),反之不会引发索引值递增的get或set操作。下面我们看下ByteBu中常用API的参考说明
ByteBuf API
read操作
readBoolean() | 返回当前readIndex的Boolean值,readIndex增加1 |
readByte(int) | 返回当前readIndex处的字节值,readIndex增加1 |
readUnsignedByte() | 返回当前readIndex处的无符号字节值,readIndex增加1 |
readInt() | 返回当前readIndex处的int值,readIndex增加4 |
readUnsignedInt() | 返回当前readIndex处的无符号int值,返回类型为long,readIndex增加4 |
readLong() | 返回当前readIndex处的long值,readIndex增加8 |
readShort() |
返回当前readIndex处的short值,readIndex增加2 |
readUnsignedShort() | 返回当前readIndex处的short值,readIndex增加2 |
wirte操作
writeBoolean() | 在当前writerIndex处写入一个Boolean值(1或0),writerIndex增加1 |
writeByte(int) | 在当前writerIndex处写入一个byte值,writerIndex增加1 |
writeShort(int) | 在当前writerIndex处写入一个short值,writerIndex增加2 |
writeInt(int) | 在当前writerIndex处写入一个int值,writerIndex增加4 |
writeLong(int) | 在当前writerIndex处写入一个long值,writerIndex增加4 |
get操作
getBoolean(int) | 返回给的索引处的Boolean值,readIndex值不变 |
getByte(int) | 返回给的索引处的Byte值,readIndex值不变 |
getShort(int) | 返回给的索引处的short值,readIndex值不变 |
getInt(int) | 返回给的索引处的int值,readIndex值不变 |
getLong(int) | 返回给的索引处的long值,readIndex值不变 |
set操作
setBoolean(int,boolean) | 在指定索引处设置一个Boolean值(1或0),writerIndex值不变 |
setByte(int,int) | 在指定索引处设置一个byte值,writerIndex值不变 |
setShort(int,int) | 在指定索引处设置一个short值,writerIndex值不变 |
setInt(int,int) | 在指定索引处设置一个int值,writerIndex值不变 |
setLong(int,int) | 在指定索引处设置一个long值,writerIndex值不变 |
ByteBuf类型
Netty中ByteBuf相关实现类的UML图
Netty在构建ByteBuf时,有以下多种分类:
1、从内存类型上,分为堆内存与直接内存,HeapByteBuf与DirectByteBuf
我们知道Java中大部分对象都是在堆内存中存储,由jvm统一管理,但NIO中 的 ByteBuffer 类允许 JVM 实现通过本地调用来分配内存,Netty中对基于直接内存的ByteBuffer也进行了封装,这主要是为了避免在每次调用本地 I/O 操作之前(或者之后)将缓冲区的内容复 制到一个中间缓冲区(或者从中间缓冲区把内容复制到缓冲区),直接缓冲区不会占用堆的容量。事实上,在通过套接字发送它之前,JVM将会在内部把你的缓冲 区复制到一个直接缓冲区中。所以如果使用直接缓冲区可以节约一次拷贝,提高IO操作性能。使用直接内存的优缺点如下:
(1)优点:由于数据直接在内存中,不存在从JVM拷贝数据到直接缓冲区的过程,提高IO操作性能。
(2)缺点:相对于基于堆的缓冲区,它们的分配和释放都较为昂贵,同时由于直接内存不受JVM垃圾回收统一管理,需要自己手动回收,需要特别注意内存泄露的问题。
2、从分配模式上,分为池化与非池化;PooledByteBuf与UnpooledByteBuf
对于频繁的申请与释放内存带来的性能损耗与碎片化问题,Netty基于池化思想通过预先申请一块专用内存地址作为内存池进行管理,从而不需要每次都进行分配和释放。
从上面的UML图中可以看到,基于AbstractByteBuf父类针对直接内存与堆内存,也都有其对应的池化与非池化实现类;
PooledByteBuf 下有 PooledUnsafeDirectByteBuf、PooledHeapByteBuf、PooledDirectByteBuf三个子类实现
UnpooledByteBuf 下则是 UnpooledDirectByteBuf及其子类UnpooledUnsafeDirectByteBuf 与 UnpooledHeapByteBuf及其子类UnpooledUnsafeHeapByteBuf
3、从具体的操作类上,分为Unsafe与非Unsafe
从上面的子类实现中,我们发现每种分类中又包含Usafe与非Unsafe的区别,我们知道java可以通过Unsafe类直接操作内存区域,所以这些类的区别就是在于是调用jdk的Unsafe直接去操作对象的内存地址还是通过jdk封装的安全方式操作内存。
我们通过PooledByteBuf下Unsafe与非Unsafe实现类的getByte方法,看下具体的区别
PooledUnsafeHeapByteBuf
@Override protected byte _getByte(int index) { return UnsafeByteBufUtil.getByte(addr(index)); }
Netty中封装了一个UnsafeByteBufUtil类,进入内部实现看到调用的是Unsafe对象进行具体操作
static byte getByte(long address) { return UNSAFE.getByte(address); }
PooledHeapByteBuf
跟踪其内部代码则可以看到字节是基于数组操作的
@Override protected byte _getByte(int index) { return HeapByteBufUtil.getByte(memory, idx(index)); } static byte getByte(byte[] memory, int index) { return memory[index]; }
PooledDirectByteBuf
针对DirectByteBuf大家需要灵活理解,PooledUnsafeDirectByteBuf 与PooledUnsafeDirectByteBuf的区别一个是UnsafeByteBufUtil类直接操作,一个是使用java NIO中的DirectByteBuf类进行操作,但因为要操作直接内存,最后还都是要基于jdk的unsafe类实现;
对比他们两种实现,可以看出Unsafe与非Unsafe的区别,前者是通过jdk的Unsafe类去操作数据,后者直接通过数组或者jdk底层的DirectByteBuf去操作数据。
ByteBuf作为Netty中数据操作与内存分配的具体实现,是Netty中最为底层的也是最精细的一部分,本文只是对ByteBuf的一个简单概述,后续我们会进一步对其进行探索与剖析,更好的展示Netty内部具体实现,希望对大家能有所帮助,其中如有不足与不正确的地方还望指出与海涵。
关注微信公众号,查看更多技术文章。
转载说明:未经授权不得转载,授权后务必注明来源(注明:来源于公众号:架构空间, 作者:大凡)
推荐阅读
-
Netty源码分析之ByteBuf(一)—ByteBuf中API及类型概述
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。