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.Poolsync.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

作為對比實驗我們直接使用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)
		}
	}
}

bytes.Buffer池

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分支申請新對象。

這裡我們直接使用minio的實現: github.com/minio/minio…

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又能提供強大的功能。

上面介紹的幾種都是比較常用的,而且實現也非常簡單的字節池,如果在業務中有更加復雜的需求,也可以根據需求實現一個字節池。

代碼地址:github.com/jiaxwu/gomm…

總結

到此這篇關於Go如何優雅的使用字節池的文章就介紹到這瞭,更多相關Go優雅使用字節池內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: