专栏首页飞雪无情的博客Go语言|基于channel实现的并发安全的字节池

Go语言|基于channel实现的并发安全的字节池

字节切片[]byte是我们在编码中经常使用到的,比如要读取文件的内容,或者从io.Reader获取数据等,都需要[]byte做缓冲。

1 2

func ReadFull(r Reader, buf []byte) (n int, err error) func (f *File) Read(b []byte) (n int, err error)

以上是两个使用到[]byte作为缓冲区的方法。那么现在问题来了,如果对于以上方法我们有大量的调用,那么就要声明很多个[]byte,这需要太多的内存的申请和释放,也就会有太多的GC。

MinIO 的字节池

这个时候,我们需要重用已经创建好的[]byte来提高对象的使用率,降低内存的申请和GC。这时候我们可以使用sync.Pool来实现,不过最近我在研究开源项目MinIO的时候,发现他们使用channel的方式实现字节池。

1 2 3 4 5

type BytePoolCap struct { c chan []byte w int wcap int }

BytePoolCap结构体的定义比较简单,共有三个字段:

  1. c是一个chan,用于充当字节缓存池
  2. w是指使用make函数创建[]byte时候的len参数
  3. wcap指使用make函数创建[]byte时候的cap参数

有了BytePoolCap结构体,就可以为其定义Get方法,用于获取一个缓存的[]byte了。

1 2 3 4 5 6 7 8 9 10 11 12 13 14

func (bp *BytePoolCap) Get() (b []byte) { select { case b = <-bp.c: // reuse existing buffer default: // create new buffer if bp.wcap > 0 { b = make([]byte, bp.w, bp.wcap) } else { b = make([]byte, bp.w) } } return }

以上是采用经典的select+chan的方式,能获取到[]byte缓存则获取,获取不到就执行default分支,使用make函数生成一个[]byte

从这里也可以看到,结构体中定义的wwcap字段,用于make函数的lencap参数。

有了Get方法,还要有Put方法,这样就可以把使用过的[]byte放回字节池,便于重用。

1 2 3 4 5 6 7 8

func (bp *BytePoolCap) Put(b []byte) { select { case bp.c <- b: // buffer went back into pool default: // buffer didn't go back into pool, just discard } }

Put方法也是采用select+chan,能放则放,不能放就丢弃这个[]byte

使用BytePoolCap

已经定义好了GetPut就可以使用了,在使用前,BytePoolCap还定义了一个工厂函数,用于生成*BytePoolCap,比较方便。

1 2 3 4 5 6 7

func NewBytePoolCap(maxSize int, width int, capwidth int) (bp *BytePoolCap) { return &BytePoolCap{ c: make(chan []byte, maxSize), w: width, wcap: capwidth, } }

把相关的参数暴露出去,可以让调用者自己定制。这里的maxSize表示要创建的chan有多大,也就是字节池的大小,最大存放数量。

1 2 3 4 5

bp := bpool.NewBytePoolCap(500, 1024, 1024) buf:=bp.Get() defer bp.Put(buf) //使用buf,不再举例

以上就是使用字节池的一般套路,使用后记得放回以便复用。

和sync.Pool对比

两者原理基本上差不多,都多协程安全。sync.Pool可以存放任何对象,BytePoolCap只能存放[]byte,不过也正因为其自定义,存放的对象类型明确,不用经过一层类型断言转换,同时也可以自己定制对象池的大小等。

关于二者的性能,我做了下Benchmark测试,整体看MinIO的BytePoolCap更好一些。

1 2 3 4 5 6

var bp = bpool.NewBytePoolCap(500, 1024, 1024) var sp = &sync.Pool{ New: func() interface{} { return make([]byte, 1024, 1024) }, }

模拟的两个字节池,[]byte的长度和容量都是1024。然后是两个模拟使用字节池,这里我启动500协程,模拟并发,使用不模拟并发的话,BytePoolCap完全是一个[]byte的分配,完全秒杀sync.Pool,对sync.Pool不公平。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

func opBytePool(bp *bpool.BytePoolCap) { var wg sync.WaitGroup wg.Add(500) for i := 0; i < 500; i++ { go func(bp *bpool.BytePoolCap) { buffer := bp.Get() defer bp.Put(buffer) mockReadFile(buffer) wg.Done() }(bp) } wg.Wait() } func opSyncPool(sp *sync.Pool) { var wg sync.WaitGroup wg.Add(500) for i := 0; i < 500; i++ { go func(sp *sync.Pool) { buffer := sp.Get().([]byte) defer sp.Put(buffer) mockReadFile(buffer) wg.Done() }(sp) } wg.Wait() }

接下来就是我模拟的读取我本机文件的一个函数mockReadFile(buffer):

1 2 3 4 5 6 7 8 9

func mockReadFile(b []byte) { f, _ := os.Open("water") for { n, err := io.ReadFull(f, b) if n == 0 || err == io.EOF { break } } }

然后运行go test -bench=. -benchmem -run=none 查看测试结果:

1 2 3

pkg: flysnow.org/hello BenchmarkBytePool-8 1489 979113 ns/op 36504 B/op 1152 allocs/op BenchmarkSyncPool-8 1008 1172429 ns/op 57788 B/op 1744 allocs/op

从测试结果看BytePoolCap在内存分配,每次操作分配字节,每次操作耗时来看,都比sync.Pool更有优势。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 干货 | Go开发中,如何有效控制Goroutine的并发数量

    洋洋,携程高级安全研发工程师,擅长Python、Golang开发,负责安全工具研发。

    携程技术
  • golang插件化方案

    业务线的活动,每一次新活动都做独立项目开发,有大量重复代码,并且浪费数据服务的连接资源;排序服务也许要经常添加业务代码,目前是停服务发布……这些场景为了开发维护...

    李海彬
  • 100 行写一个 go 的协程池 (任务池)

    go 的 goroutine 提供了一种较线程而言更廉价的方式处理并发场景, go 使用二级线程的模式, 将 goroutine 以 M:N 的形式复用到系统线...

    会呼吸的Coder
  • golang插件化方案

    业务线的活动,每一次新活动都做独立项目开发,有大量重复代码,并且浪费数据服务的连接资源;排序服务也许要经常添加业务代码,目前是停服务发布……这些场景为了开发维护...

    李海彬
  • Gopher 2019 Go并发编程的分享

    昨天参加了 Gopher China 2019 大会,分享了《Go并发编程实践》的主题,在这一篇博客中总结一下。

    李海彬
  • 当我们讨论swoole的时候,我们在讨论什么?

    首先,我们需要肯定的是,它的出现是为了弥补php更准确的是laravel的短板:性能和资源利用率。其次,就我们现有的场景来说,更多的是开发http的相关功能。

    槽痞
  • Go语言并发机制

    Go语言的并发通过goroutine(直译应该是Go程)实现。goroutine是用户态的轻量级线程,因此上下文切换要比线程的上下文切换开销要小很多。

    Steve Wang
  • 深入浅出Golang的协程池设计

    虽然go语言在调度Goroutine已经优化的非常完成,并且Goroutine作为轻量级执行流程,也不需要CPU调度器的切换,我们一般在使用的时候,如果想处理一...

    李海彬
  • Golang并发编写初探

    Go 语言中没有线程的概念,只有协程,也称为 goroutine。相比线程来说,协程更加轻量,一个程序可以随意启动成千上万个 goroutine。

    PayneWu

扫码关注云+社区

领取腾讯云代金券