快捷導(dǎo)航

Go如何優(yōu)雅的使用字節(jié)池示例詳解

更新時(shí)間：2022年08月21日 16:54:03 作者：jiaxwu

在編程開(kāi)發(fā)中,我們經(jīng)常會(huì)需要頻繁創(chuàng)建和銷(xiāo)毀同類(lèi)對(duì)象的情形,這樣的操作很可能會(huì)對(duì)性能造成影響,這時(shí)常用的優(yōu)化手段就是使用對(duì)象池（object pool）,這篇文章主要給大家介紹了關(guān)于Go如何優(yōu)雅的使用字節(jié)池的相關(guān)資料,需要的朋友可以參考下

背景

在某些場(chǎng)景下，我們可能會(huì)大量的使用字節(jié)數(shù)組，比如IO操作、編解碼，如果不進(jìn)行優(yōu)化，大量的申請(qǐng)和釋放字節(jié)數(shù)組會(huì)造成一定的性能損耗，因此有必要復(fù)用字節(jié)數(shù)組。

為何需要字節(jié)池

在 Go 語(yǔ)言編程中，在從 io.Reader 中讀取數(shù)據(jù)時(shí)，我們都要?jiǎng)?chuàng)建一個(gè)字節(jié)切片 []byte 去存儲(chǔ)，在高頻調(diào)用或并發(fā)比較高的場(chǎng)景中，需要頻繁的進(jìn)行內(nèi)存申請(qǐng)和釋放，增大了 GC 的壓力，所以這時(shí)候需要采用 “字節(jié)池” 來(lái)優(yōu)化。

最簡(jiǎn)單的方式

對(duì)于Go語(yǔ)言來(lái)說(shuō)，我們第一個(gè)想到的就是使用sync.Pool來(lái)做字節(jié)數(shù)組的對(duì)象池，比如這樣：

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
}

// 獲取字節(jié)數(shù)組
func (p *BytePool) Get() []byte {
	return p.p.Get().([]byte)
}

// 歸還字節(jié)數(shù)組
func (p *BytePool) Put(b []byte) {
	// 重置已用大小
	b = b[:0]
	p.p.Put(b)
}

我們簡(jiǎn)單的封裝了sync.Pool，sync.Pool.New根據(jù)指定的初始大小申請(qǐng)新的字節(jié)數(shù)組，在Put的時(shí)候重置字節(jié)數(shù)組的已用空間（這樣下次才能從頭開(kāi)始使用）。

測(cè)試

我們進(jìn)行一個(gè)簡(jiǎn)單性能測(cè)試，也就是不斷的申請(qǐng)字節(jié)數(shù)組，然后寫(xiě)入長(zhǎng)度為1024的字節(jié)數(shù)組塊，共64塊，也就是64KB，測(cè)試樣例共3個(gè)：

不預(yù)先申請(qǐng)空間

這個(gè)樣例我們不預(yù)先申請(qǐng)字節(jié)數(shù)組空間，因此在append的過(guò)程中會(huì)不斷的申請(qǐng)新的更大的空間，然后轉(zhuǎn)移字節(jié)數(shù)組內(nèi)容。

func BenchmarkByte(b *testing.B) {
	for n := 0; n < b.N; n++ {
                // 從長(zhǎng)度為0的字節(jié)數(shù)組開(kāi)始
		var b []byte
		for i := 0; i < blocks; i++ {
			b = append(b, block...)
		}
	}
}

預(yù)先申請(qǐng)空間

由于這個(gè)測(cè)試的總大小的預(yù)先知道的，因此我們可以先提前申請(qǐng)空間，這樣就不用在append過(guò)程中不斷的申請(qǐng)新的更大空間，然后轉(zhuǎn)移字節(jié)數(shù)組內(nèi)容了。

func BenchmarkMake(b *testing.B) {
	for n := 0; n < b.N; n++ {
                // 預(yù)先保留需要的空間
		b := make([]byte, 0, blocks*blockSize)
		for i := 0; i < blocks; i++ {
			b = append(b, block...)
		}
	}
}

字節(jié)數(shù)組池

這里我們每次先從字節(jié)池拿一個(gè)字節(jié)數(shù)組Get()，使用完之后歸還字節(jié)池Put()。

func BenchmarkBytePool(b *testing.B) {
	pool := NewBytePool(0, blocks*blockSize)
	for n := 0; n < b.N; n++ {
                // 拿字節(jié)數(shù)組
		b := pool.Get()
		for i := 0; i < blocks; i++ {
			b = append(b, block...)
		}
                // 歸還
		pool.Put(b)
	}
}

測(cè)試結(jié)果

可以看到我們簡(jiǎn)單的字節(jié)池就可以帶來(lái)很大的性能提升！

BenchmarkByte-16                   32470             38136 ns/op
BenchmarkMake-16                  605449              1962 ns/op
BenchmarkBytePool-16             1000000              1162 ns/op

更優(yōu)雅的方式

在實(shí)際的編程中，我們?cè)谑褂米止?jié)數(shù)組時(shí)，很多時(shí)候都需要以一個(gè)流的形式去讀寫(xiě)，同時(shí)也可能很難提前計(jì)算出需要的大小，因此bytes.Buffer可能更加適合實(shí)際的編程。

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
}

// 獲取字節(jié)數(shù)組
func (p *BufferPool) Get() *bytes.Buffer {
	return p.p.Get().(*bytes.Buffer)
}

// 歸還字節(jié)數(shù)組
func (p *BufferPool) Put(b *bytes.Buffer) {
	// 重置已用大小
	b.Reset()
	p.p.Put(b)
}

測(cè)試

測(cè)試條件與上面相同。

直接使用Buffer

作為對(duì)比實(shí)驗(yàn)我們直接使用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)
	}
}

測(cè)試結(jié)果

可以看到使用bytes.Buffer池比字節(jié)數(shù)組池性能差了一點(diǎn)，主要是因?yàn)閎ytes.Buffer比較復(fù)雜，但是bytes.Buffer的功能比字節(jié)數(shù)組強(qiáng)大很多。

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

限制池大小

有時(shí)候我們不想對(duì)象池?zé)o限大，因此我們需要限制對(duì)象池的大小，對(duì)于Go語(yǔ)言來(lái)說(shuō)，我們可以使用channel+select，也就是申請(qǐng)一個(gè)固定長(zhǎng)度緩沖區(qū)的channel，配合select的default分支。

Put：channel不滿則put，否則default分支丟棄這個(gè)對(duì)象。
Get：channel不空則get，否則default分支申請(qǐng)新對(duì)象。

這里我們直接使用minio的實(shí)現(xiàn)： github.com/minio/minio…

package bufferpool

type ByteFixPool struct {
	cache chan []byte
	size  int
	cap   int
}

// cacheSize: 字節(jié)池緩存長(zhǎng)度
// size: 字節(jié)數(shù)組長(zhǎng)度
// cap: 字節(jié)數(shù)組容量
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空則申請(qǐng)一個(gè)新的字節(jié)數(shù)組
	default:
		return make([]byte, p.size, p.cap)
	}
}

func (p *ByteFixPool) Put(b []byte) {
	// 重置已用大小
	b = b[:0]
	select {
	// 放入channel
	case p.cache <- b:
	// channel滿了則丟棄字節(jié)數(shù)組
	default:
	}
}

測(cè)試

固定大小字節(jié)池

這里使用固定大小字節(jié)池，同時(shí)預(yù)先分配空間。

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)
	}
}

測(cè)試結(jié)果

可以看到使用channel+select的性能甚至更好一點(diǎn)，而且還能限制字節(jié)池大小，當(dāng)然相比于sync.Pool的實(shí)現(xiàn)，它在字節(jié)池channel里面的空間是沒(méi)辦法自動(dòng)回收的。

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