Go标准库中的bytes.Buffer(下文用Buffer
表示)类似于一个FIFO的队列,它是一个流式字节缓冲区。
我们可以持续向Buffer尾部写入数据,从Buffer头部读取数据。当Buffer内部空间不足以满足写入数据的大小时,会自动扩容。
伸缩策略
1 | ....................................... |
流式字节缓冲区一般会有两个下标位置:写入位置(下文用ePos
表示),读取位置(下文用bPos
表示)。
bPos和ePos一开始都为0,ePos随写入内容时后移,bPos随读取内容时后移。
bPos永远小于等于ePos。
ePos减bPos即为待读取的内容大小(下文用content
以及contentSize
表示)。
整个内存块的大小(下文用capacity
表示)减去ePos,即为可直接写入内容的大小(下文用eIdle
表示)。
写入时,逻辑如下:
当需写入内容的大小(下文用neededSize
表示)小于eIdle时,直接在尾部追加写入即可。
当neededSize超过eIdle时,此时有两种情况:
第一,由于已写入Buffer的内容有一些可能已被上层读取,所以实际上bpos前面的空间(下文用bIdle
表示)也是空闲的。
如果eIdle加上bIdle大于neededSize,可以将content向左平移拷贝至从0位置开始,将bPos设置为0,ePos设置为刚才的(epos-bpos)。此时,eIdle变大,可直接在尾部追加写入。
第二,如果eIdle加上bIdle仍然小于neededSize,只能重新申请一块更大的内存,将当前待读取内容拷贝至新内存块,并将老内存块释放。然后在新内存块的尾部追加需写入的内容。
但是实际上,Buffer的实现和上面所说有些细微区别,或者可以说是一种优化吧:
当neededSize超过eIdle时,只要contentSize加neededSize超过当前capacity的一半时,就进行扩容。即扩容策略更为激进,目的是减少后续平移拷贝频率,空间换效率。
另外,Buffer扩容后新内存块的大小为:(2 * 当前capacity) + neededSize
。
最后,Buffer只有扩容策略,没有缩容策略,即扩容到多大就占多大的内存,即使内部contentSize很小,而capacity已增长到非常大。当前使用的内存块只有在Buffer对象释放时才能随之释放。
Buffer在创建时并不会申请内存块,只有在往里写数据时才会申请,首次申请的大小即为写入数据的大小。如果写入的数据小于64字节,则按64字节申请。
底层数据结构
Buffer底层使用单个[]byte
切片实现。
capacity,即切片的cap。
bPos使用了一个整型变量存储,即off。
ePos运用了Go切片的特性。Go的切片实际上是一个结构体,包含了len, cap, p三个数据成员。当我们操作Buffer时,除了初始化和扩容时会重新申请底层内存块,其他时候只是对切片重新切片,也即只是改变了切片的len属性,以及p的指向,底层被指向的那整块内存块并不会发生改变。切片当前的len就是当前的ePos。
结合暴露的方法做些说明
先做个总的说明吧。
Buffer满足了挺多常见的读、写interface,可以非常方便的和其他模块进行集成、交互。
除了通过[]byte与外部进行数据交互,也支持byte,rune,string,使得用起来比较方便。还支持与外部的io.Reader,io.Writer进行数据交互,有时可以减少一些中间层的内存拷贝。
常规的一些获取内部状态的方法都有,比如Len,Cap等。
提供了Bytes,Next方法,可以预览Buffer的内容而不真正消费读取走。
另外,紧跟上一条,Buffer还提供了一些对读操作的撤销方法,但是有一些限制。个人感觉有预览就足够了。
提供Grow方法,在某些场景由外部手动扩容,可以减少自动扩容的次数、消耗。
提供Truncate方法,直接丢弃待读取的部分内容,虽然用Read方法也可以把数据读走,但是用Truncate就不用申请内存来获取Read的结果了。
提供了两个构造方法,在构造时即可写入一些内容。
以下是所有方法的注释:
1 | // ---------- 满足了一些比较重要的interface |
最后
放一个几年前写的一个c++版本的buffer,功能类似,感兴趣的好兄弟们可以来个star吗。
github地址:https://github.com/q191201771/libchef/blob/master/include/chef_base/chef_buffer.hpp
本文完,作者yoko,尊重劳动人民成果,转载请注明原文出处: https://pengrl.com/p/60618/