字節切片[]byte是我們在編碼中經常使用到的，比如要讀取文件的內容，或者從io.Reader獲取數據等，都需要[]byte做緩衝。
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的方式實現字節池。
type BytePoolCap struct {
c chan []byte
w int
wcap int
}
BytePoolCap結構體的定義比較簡單，共有三個欄位：
c是一個chan，用於充當字節緩存池
w是指使用make函數創建[]byte時候的len參數
wcap指使用make函數創建[]byte時候的cap參數
有了BytePoolCap結構體，就可以為其定義Get方法，用於獲取一個緩存的[]byte了。
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。
從這裡也可以看到，結構體中定義的w和wcap欄位，用於make函數的len和cap參數。
有了Get方法，還要有Put方法，這樣就可以把使用過的[]byte放回字節池，便於重用。
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已經定義好了Get和Put就可以使用了，在使用前，BytePoolCap還定義了一個工廠函數，用於生成*BytePoolCap，比較方便。
func NewBytePoolCap(maxSize int, width int, capwidth int) (bp *BytePoolCap) {
return &BytePoolCap{
c: make(chan []byte, maxSize),
w: width,
wcap: capwidth,
}
}
把相關的參數暴露出去，可以讓調用者自己定製。這裡的maxSize表示要創建的chan有多大，也就是字節池的大小，最大存放數量。
bp := bpool.NewBytePoolCap(500, 1024, 1024)
buf:=bp.Get()
defer bp.Put(buf)
//使用buf,不再舉例
以上就是使用字節池的一般套路，使用後記得放回以便復用。
和sync.Pool對比兩者原理基本上差不多，都多協程安全。sync.Pool可以存放任何對象，BytePoolCap只能存放[]byte，不過也正因為其自定義，存放的對象類型明確，不用經過一層類型斷言轉換，同時也可以自己定製對象池的大小等。
關於二者的性能，我做了下Benchmark測試，整體看MinIO的BytePoolCap更好一些。
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不公平。
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):
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 查看測試結果：
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更有優勢。
小結很多優秀的開源項目，可以看到很多優秀的原始碼實現，並且會根據自己的業務場景，做出更好的優化。
本文為原創文章，轉載註明出處,歡迎掃碼關注公眾號flysnow_org或者網站asf https://www.flysnow.org/ ，第一時間看後續精彩文章。覺得好的話，請猛擊文章右下角「在看」，感謝支持。