您好,登錄后才能下訂單哦!
今天小編給大家分享一下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進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。