Netty源码 之 ByteBuf自适应扩缩容源码

Netty体系如何使得ByteBuf根据实际IO收发数据场景进行自适应扩容缩容的?

IO收发数据的过程:

read 读取("I"):网卡硬件通过网络传输介质读取对端传输过来的数据,网卡硬件再把数据写到recv-socket缓冲区,应用程序编写逻辑把recv-socket缓冲区的数据读取到ByteBuf。

write 写出("O"): 应用程序写到ByteBuf,ByteBuf的数据再flush刷新到send-socket缓冲区,send-socket再把数据写到网卡硬件,网卡硬件通过网络传输介质传输给对端。

像之前我们使用Netty进行开发时,最寻常的方式是如何申请一个ByteBuf空间?

ByteBuf byteBuf = ByteBufAllocator.DEFAULT.buffer();

但是这样申请ByteBuf空间具有一个弊端:ByteBuf是固定空间大小的,导致收发socket缓冲区的数据时,ByteBuf可能过大或过小,如果Netty体系可以封装一种方法逻辑去使得ByteBuf自适应的扩容缩容,那么可以最大程度的利用ByteBuf 并且最大利用的提升IO收发数据的性能。

Netty是怎么做的?

是由如下AbstractNioByteChannel类中核心逻辑链路read方法:

Netty源码 之 ByteBuf自适应扩缩容源码_第1张图片

  • 开始分析

1.Netty封装了一个自适应实际场景变化大小的ByteBuf,比原生直接通过ByteBufAllocator.allocate()创建ByteBuf要灵活的多。原生创建ByteBuf的方式导致ByteBuf的大小固定不可变。

Netty源码 之 ByteBuf自适应扩缩容源码_第2张图片

2.

Netty源码 之 ByteBuf自适应扩缩容源码_第3张图片

为什么IO基本上都是使用直接内存?

因为对于IO这种强阻塞,高数据量的传输操作,其实使用直接内存的目的就是为了减少数据的拷贝,实现零拷贝。IO收发数据量过大,使用直接内存可以极大的减少数据的拷贝次数。

如何申请直接内存?通过Unsafe。

Unsafe:跳过JVM虚拟机,直接操控操作系统所管理的内存资源。

原来:java--->JVM--->OS--->计算机内存

引入Unsafe后:java(Unsafe)--->OS--->计算机内存

直接内存的创建,其实底层就是使用Unsafe这个类去直接向操作系统申请了一块内存。

非直接内存其实就是堆内存,也就是向JVM申请的堆内存。JVM通过自身的C++程序再向OS操作系统去申请真正的内存空间。这样性能就差了很多。

JUC的CAS很多类底层都是Unsafe做的,所以性能高。比如说:AtomicInteger

3.

Netty源码 之 ByteBuf自适应扩缩容源码_第4张图片

4.guess()方法,返回nextReceiveBufferSize。该属性值代表当前我们应该把ByteBuf缓冲区的大小设置成nextReceiveBufferSize大小。该值的大小是通过上一次ByteBuf的读取情况进行动态变化的,具体是如何进行自适应变化得出的?后续慢慢分析。

Netty源码 之 ByteBuf自适应扩缩容源码_第5张图片

5.

Netty源码 之 ByteBuf自适应扩缩容源码_第6张图片

6.doReadBytes方法

Netty源码 之 ByteBuf自适应扩缩容源码_第7张图片

Netty源码 之 ByteBuf自适应扩缩容源码_第8张图片

recvBufAllocatorHandle()

Netty源码 之 ByteBuf自适应扩缩容源码_第9张图片

Netty源码 之 ByteBuf自适应扩缩容源码_第10张图片

7.

Netty源码 之 ByteBuf自适应扩缩容源码_第11张图片

Netty源码 之 ByteBuf自适应扩缩容源码_第12张图片

8.static静态代码块中的代码会执行加载一次

Netty源码 之 ByteBuf自适应扩缩容源码_第13张图片

分析static静态代码块的代码逻辑:

ByteBuf自适应扩容池sizeTable中有许多ByteBuf可选的值大小,但是sizeTable中的数据值是具有一定规律的,规律如下:

1.当可选值大小小于512时,从16开始递增,每次递增16,把每一个可选值加入到sizeTable中。在第一个for循环结束后,sizeTable这一自适应扩容池中有可选值:16,32,48,64,80,96,112,.........,512

2.当可选值达到512,且不超过int整型最大值【不包含int整型最大值】的范围之间,可选值按照2倍的大小进行递增。所以在第二个for循环结束后,sizeTable这一自适应扩容池中有可选值:16,..........,512,1024,2048,.........,Integer.MAX_VALUE / 2

当sizeTable集合初始化完成后,创建SIZE_TABLE数组,把集合中的所有元素都放入到SIZE_TABLE数组中。

9.传入一个size,在扩容池SIZE_TABLE中找到一个与size最相近的可选值,并且返回该可选值所对应的索引下标。查找利用的是二分查找法。

Netty源码 之 ByteBuf自适应扩缩容源码_第14张图片

10.

Netty源码 之 ByteBuf自适应扩缩容源码_第15张图片

11.前面的准备工作,属性初始化工作都做完后,这里展开分析record自适应扩缩容ByteBuf的核心逻辑:

Netty源码 之 ByteBuf自适应扩缩容源码_第16张图片

分支1:INDEX_DECREMENT=1,为递减频率。

max(0,index-INDEX_DECREMENT):二者找到一个最大值。意思就是最小递减到0

SIZE_TABLE[max(0,index-INDEX_DECREMENT)]:表示最低递减到可选值为16的ByteBuf,也就是索引值为0所对应的元素值

如果actualReadBytes(实际要从socket缓冲区读取到ByteBuf的数据大小) 小于等于 SIZE_TABLE[max(0,index-INDEX_DECREMENT)],说明可以自适应缩容。你思考一下,你都往前找一个可选值了,结果实际读取的ByteBuf数据大小还是小于等于该已经假设递减过的数据值了,那么说明当前ByteBuf在往前缩小一个后还是使用不完全,那么你是不是可以把ByteBuf缩小到该假设递减到的大小。

但是Netty这里又做了一层逻辑,兜底,第一次判断为true后,由于decreaseNow=false,不会真正的缩容。但是当第二次读取又一次进入该record方法时,还是判断出if为true,那么又一次说明真的用不完,那么因为此时decrease=true,所以可以进入内层if分支,那么可以真正的执行缩容逻辑,并且把decreaseNow置为false。eg:把32执行一次这个缩容逻辑,最终变为16

分支2:INDEX_INCREMENT=4

如果actualReadBytes(实际要从socket缓冲区读取到ByteBuf的数据大小) 大于或等于当前ByteBuf的大小时,我们需要进行扩容操作。扩容时是按照频率INDEX_INCREMENT=4进行扩容,也就是每次向后跳四个可选值的频率进行递增。但是ByteBuf最大值不可以超过Integer.MAX_VALUE/2。同理会做很多处理逻辑。eg:把16执行一遍这个扩容逻辑,最终变为80

并且把decreaseNow置为false。

12.

所以:

这一轮我们通过record方法可能设置出的nextReceiveBufferSize的变量值大小,最终下一次do while再循环到调用allocate方法时,其中调用ioBuffer方法申请大小时,参数使用的guess()方法就会使用到上一次设置的nextReceiveBufferSize的值大小。

Netty源码 之 ByteBuf自适应扩缩容源码_第17张图片

13.至此,Netty构建的ByteBuf的扩容缩容机制也就分析结束了。

你可能感兴趣的:(Netty源码,java,netty,后端)