您好,登录后才能下订单哦!
今天小编给大家分享一下Go怎么优雅的使用字节池的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。
在某些场景下,我们可能会大量的使用字节数组,比如IO操作、编解码,如果不进行优化,大量的申请和释放字节数组会造成一定的性能损耗,因此有必要复用字节数组。
在 Go 语言编程中,在从 io.Reader 中读取数据时,我们都要创建一个字节切片 []byte 去存储,在高频调用或并发比较高的场景中,需要频繁的进行内存申请和释放,增大了 GC 的压力,所以这时候需要采用 “字节池” 来优化。
对于Go语言来说,我们第一个想到的就是使用sync.Pool来做字节数组的对象池,比如这样:
package bufferpool import "sync" type BytePool struct { p sync.Pool } func NewBytePool(size, cap int) *BytePool { if size > cap { panic("size must be less then cap") } p := &BytePool{} p.p.New = func() any { return make([]byte, size, cap) } return p } // 获取字节数组 func (p *BytePool) Get() []byte { return p.p.Get().([]byte) } // 归还字节数组 func (p *BytePool) Put(b []byte) { // 重置已用大小 b = b[:0] p.p.Put(b) }
我们简单的封装了sync.Pool
,sync.Pool.New
根据指定的初始大小申请新的字节数组,在Put
的时候重置字节数组的已用空间(这样下次才能从头开始使用)。
我们进行一个简单性能测试,也就是不断的申请字节数组,然后写入长度为1024的字节数组块,共64块,也就是64KB,测试样例共3个:
这个样例我们不预先申请字节数组空间,因此在append的过程中会不断的申请新的更大的空间,然后转移字节数组内容。
func BenchmarkByte(b *testing.B) { for n := 0; n < b.N; n++ { // 从长度为0的字节数组开始 var b []byte for i := 0; i < blocks; i++ { b = append(b, block...) } } }
由于这个测试的总大小的预先知道的,因此我们可以先提前申请空间,这样就不用在append过程中不断的申请新的更大空间,然后转移字节数组内容了。
func BenchmarkMake(b *testing.B) { for n := 0; n < b.N; n++ { // 预先保留需要的空间 b := make([]byte, 0, blocks*blockSize) for i := 0; i < blocks; i++ { b = append(b, block...) } } }
这里我们每次先从字节池拿一个字节数组Get()
,使用完之后归还字节池Put()
。
func BenchmarkBytePool(b *testing.B) { pool := NewBytePool(0, blocks*blockSize) for n := 0; n < b.N; n++ { // 拿字节数组 b := pool.Get() for i := 0; i < blocks; i++ { b = append(b, block...) } // 归还 pool.Put(b) } }
可以看到我们简单的字节池就可以带来很大的性能提升!
BenchmarkByte-16 32470 38136 ns/op BenchmarkMake-16 605449 1962 ns/op BenchmarkBytePool-16 1000000 1162 ns/op
在实际的编程中,我们在使用字节数组时,很多时候都需要以一个流的形式去读写,同时也可能很难提前计算出需要的大小,因此bytes.Buffer
可能更加适合实际的编程。
package bufferpool import ( "bytes" "sync" ) type BufferPool struct { p sync.Pool } func NewBufferPool(size, cap int) *BufferPool { if size > cap { panic("size must be less then cap") } p := &BufferPool{} p.p.New = func() any { var b []byte if cap > 0 { b = make([]byte, size, cap) } return bytes.NewBuffer(b) } return p } // 获取字节数组 func (p *BufferPool) Get() *bytes.Buffer { return p.p.Get().(*bytes.Buffer) } // 归还字节数组 func (p *BufferPool) Put(b *bytes.Buffer) { // 重置已用大小 b.Reset() p.p.Put(b) }
测试条件与上面相同。
作为对比实验我们直接使用Buffer。
func BenchmarkBuffer(b *testing.B) { for n := 0; n < b.N; n++ { b := bytes.NewBuffer(make([]byte, 0, blocks*blockSize)) for i := 0; i < blocks; i++ { b.Write(block) } } }
func BenchmarkBufferPool(b *testing.B) { pool := NewBufferPool(0, blocks*blockSize) for n := 0; n < b.N; n++ { b := pool.Get() for i := 0; i < blocks; i++ { b.Write(block) } pool.Put(b) } }
可以看到使用bytes.Buffer池
比字节数组池性能差了一点,主要是因为bytes.Buffer比较复杂,但是bytes.Buffer的功能比字节数组强大很多。
BenchmarkByte-16 31748 38131 ns/op BenchmarkMake-16 605847 1964 ns/op BenchmarkBytePool-16 1000000 1162 ns/op BenchmarkBuffer-16 589336 2030 ns/op BenchmarkBufferPool-16 962132 1235 ns/op
有时候我们不想对象池无限大,因此我们需要限制对象池的大小,对于Go语言来说,我们可以使用channel+select
,也就是申请一个固定长度缓冲区的channel,配合select的default分支。
Put:channel不满则put,否则default分支丢弃这个对象。
Get:channel不空则get,否则default分支申请新对象。
package bufferpool type ByteFixPool struct { cache chan []byte size int cap int } // cacheSize: 字节池缓存长度 // size: 字节数组长度 // cap: 字节数组容量 func NewByteFixPool(cacheSize, size, cap int) *ByteFixPool { if size > cap { panic("size must be less then cap") } return &ByteFixPool{ cache: make(chan []byte, cacheSize), size: size, cap: cap, } } func (p *ByteFixPool) Get() []byte { select { // 从channel读 case b := <-p.cache: return b // 如果channel空则申请一个新的字节数组 default: return make([]byte, p.size, p.cap) } } func (p *ByteFixPool) Put(b []byte) { // 重置已用大小 b = b[:0] select { // 放入channel case p.cache <- b: // channel满了则丢弃字节数组 default: } }
这里使用固定大小字节池,同时预先分配空间。
func BenchmarkByteFixPool(b *testing.B) { pool := NewByteFixPool(16, 0, blocks*blockSize) for n := 0; n < b.N; n++ { b := pool.Get() for i := 0; i < blocks; i++ { b = append(b, block...) } pool.Put(b) } }
可以看到使用channel+select
的性能甚至更好一点,而且还能限制字节池大小,当然相比于sync.Pool
的实现,它在字节池channel里面的空间是没办法自动回收的。
BenchmarkByte-16 31748 38131 ns/op BenchmarkMake-16 605847 1964 ns/op BenchmarkBytePool-16 1000000 1162 ns/op BenchmarkBuffer-16 589336 2030 ns/op BenchmarkBufferPool-16 962132 1235 ns/op BenchmarkByteFixPool-16 1000000 1130 ns/op
对于字节池来说。
字节对象可以是:
[]byte
:字节数组
bytes.Buffer
:功能更加强大的字节数组
其他:比如一组bytes.Buffer
实现方式可以是:
sync.Pool
:根据GC期间对象是否使用回收对象
channel+select
:限制字节池长度
其他:比如限制对象池使用空间
当然,最通用的实现是sync.Pool+bytes.Buffer
,因为sync.Pool
能够自动回收字节对象,bytes.Buffer
又能提供强大的功能。
上面介绍的几种都是比较常用的,而且实现也非常简单的字节池,如果在业务中有更加复杂的需求,也可以根据需求实现一个字节池。
以上就是“Go怎么优雅的使用字节池”这篇文章的所有内容,感谢各位的阅读!相信大家阅读完这篇文章都有很大的收获,小编每天都会为大家更新不同的知识,如果还想学习更多的知识,请关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。