1. 簡介
本文將介紹 Go 語言中的 sync.Pool并發原語，包括sync.Pool的基本使用方法、使用注意事項等的內容，能夠更好得使用sync.Pool來減少物件的重復創建，最大限度實作物件的重復使用，減少程式GC的壓力，以及提升程式的性能，
2. 問題引入
2.1 問題描述
這里我們實作一個簡單的JSON序列化器，能夠實作將一個map[string]int序列化為一個JSON字串，實作如下:
func IntToStringMap(m map[string]int) (string, error) {
// 定義一個bytes.Buffer,用于快取資料
var buf bytes.Buffer
buf.Write([]byte("{"))
for k, v := range m {
buf.WriteString(fmt.Sprintf(`"%s":%d,`, k, v))
}
if len(m) > 0 {
buf.Truncate(buf.Len() - 1) // 去掉最后一個逗號
}
buf.Write([]byte("}"))
return buf.String(), nil
}
這里使用bytes.Buffer 來快取資料，然后按照key:value的形式，將資料生成一個字串，然后回傳，實作是比較簡單的，
每次呼叫IntToStringMap方法時，都會創建一個bytes.Buffer來快取中間結果，而bytes.Buffer其實是可以被重用的，因為序列化規則和其并沒有太大的關系，其只是作為一個快取區來使用而已，
但是當前的實作為每次呼叫IntToStringMap時，都會創建一個bytes.Buffer,如果在一個應用中，請求并發量非常高時，頻繁創建和銷毀bytes.Buffer將會帶來較大的性能開銷，會導致物件的頻繁分配和垃圾回收，增加了記憶體使用量和垃圾回收的壓力，
那有什么方法能夠讓bytes.Buffer能夠最大程度得被重復利用呢，避免重復的創建和回收呢？
2.2 解決方案
其實我們可以發現，為了讓bytes.Buffer能夠被重復利用，避免重復的創建和回收，我們此時只需要將bytes.Buffer快取起來，在需要時，將其從快取中取出；當用完后，便又將其放回到快取池當中，這樣子，便不需要每次呼叫IntToStringMap方法時，就創建一個bytes.Buffer，
這里我們可以自己實作一個快取池，當需要物件時，可以從快取池中獲取，當不需要物件時，可以將物件放回快取池中，IntToStringMap方法需要bytes.Buffer時，便從該快取池中取，當用完后，便重新放回快取池中，等待下一次的獲取，下面是一個使用切片實作的一個bytes.Buffer快取池，
type BytesBufferPool struct {
mu sync.Mutex
pool []*bytes.Buffer
}
func (p *BytesBufferPool) Get() *bytes.Buffer {
p.mu.Lock()
defer p.mu.Unlock()
n := len(p.pool)
if n == 0 {
// 當快取池中沒有物件時,創建一個bytes.Buffer
return &bytes.Buffer{}
}
// 有物件時,取出切片最后一個元素回傳
v := p.pool[n-1]
p.pool[n-1] = nil
p.pool = p.pool[:n-1]
return v
}
func (p *BytesBufferPool) Put(buffer *bytes.Buffer) {
if buffer == nil {
return
}
// 將bytes.Buffer放入到切片當中
p.mu.Lock()
defer p.mu.Unlock()
obj.Reset()
p.pool = append(p.pool, buffer)
}
上面BytesBufferPool實作了一個bytes.Buffer的快取池，其中Get方法用于從快取池中取物件，如果沒有物件，就創建一個新的物件回傳；Put方法用于將物件重新放入BytesBufferPool當中，下面使用BytesBufferPool來優化IntToStringMap，
// 首先定義一個BytesBufferPool
var buffers BytesBufferPool
func IntToStringMap(m map[string]int) (string, error) {
// bytes.Buffer不再自己創建,而是從BytesBufferPool中取出
buf := buffers.Get()
// 函式結束后,將bytes.Buffer重新放回快取池當中
defer buffers.Put(buf)
buf.Write([]byte("{"))
for k, v := range m {
buf.WriteString(fmt.Sprintf(`"%s":%d,`, k, v))
}
if len(m) > 0 {
buf.Truncate(buf.Len() - 1) // 去掉最后一個逗號
}
buf.Write([]byte("}"))
return buf.String(), nil
}
到這里我們通過自己實作了一個快取池，成功對InitToStringMap函式進行了優化，減少了bytes.Buffer物件頻繁的創建和回收，在一定程度上提高了物件的頻繁創建和回收，
但是，BytesBufferPool這個快取池的實作，其實存在幾點問題，其一，只能用于快取bytes.Buffer物件；其二，不能根據系統的實際情況，動態調整物件池中快取物件的數量，假如某段時間并發量較高，bytes.Buffer物件被大量創建，用完后，重新放回BytesBufferPool之后，將永遠不會被回收，這有可能導致記憶體浪費，嚴重一點，也會導致記憶體泄漏，
既然自定義快取池存在這些問題，那我們不禁要問，Go語言標準庫中有沒有提供了更方便的方式，來幫助我們快取物件呢？
別說，還真有，Go標準庫提供了sync.Pool，可以用來快取那些需要頻繁創建和銷毀的物件，而且它支持快取任何型別的物件，同時sync.Pool是可以根據系統的實際情況來調整快取池中物件的數量，如果一個物件長時間未被使用，此時將會被回收掉，
相對于自己實作的緩沖池，sync.Pool的性能更高，充分利用多核cpu的能力，同時也能夠根據系統當前使用物件的負載，來動態調整緩沖池中物件的數量，而且使用起來也比較簡單，可以說是實作無狀態物件快取池的不二之選，
下面我們來看看sync.Pool的基本使用方式，然后將其應用到IntToStringMap方法的實作當中，
3. 基本使用
3.1 使用方式
3.1.1 sync.Pool的基本定義
sync.Pool的定義如下: 提供了Get,Put兩個方法:
type Pool struct {
noCopy noCopy
local unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
localSize uintptr // size of the local array
victim unsafe.Pointer // local from previous cycle
victimSize uintptr // size of victims array
New func() any
}
func (p *Pool) Put(x any) {}
func (p *Pool) Get() any {}
Get方法: 從sync.Pool中取出快取物件Put方法: 將快取物件放入到sync.Pool當中New函式: 在創建sync.Pool時，需要傳入一個New函式，當Get方法獲取不到物件時，此時將會呼叫New函式創建新的物件回傳，
3.1.2 使用方式
當使用sync.Pool時，通常需要以下幾個步驟:
- 首先使用
sync.Pool定義一個物件緩沖池 - 在需要使用到物件時，從緩沖池中取出
- 當使用完之后，重新將物件放回緩沖池中
下面是一個簡單的代碼的示例，展示了使用sync.Pool大概的代碼結構:
type struct data{
// 定義一些屬性
}
//1. 創建一個data物件的快取池
var dataPool = sync.Pool{New: func() interface{} {
return &data{}
}}
func Operation_A(){
// 2. 需要用到data物件的地方，從快取池中取出
d := dataPool.Get().(*data)
// 執行后續操作
// 3. 將物件重新放入快取池中
dataPool.Put(d)
}
3.2 使用例子
下面我們使用sync.Pool來對IntToStringMap進行改造，實作對bytes.Buffer物件的重用，同時也能夠自動根據系統當前的狀況，自動調整緩沖池中物件的數量，
// 1. 定義一個bytes.Buffer的物件緩沖池
var buffers sync.Pool = sync.Pool{
New: func() interface{} {
return &bytes.Buffer{}
},
}
func IntToStringMap(m map[string]int) (string, error) {
// 2. 在需要的時候,從緩沖池中取出一個bytes.Buffer物件
buf := buffers.Get().(*bytes.Buffer)
buf.Reset()
// 3. 用完之后,將其重新放入緩沖池中
defer buffers.Put(buf)
buf.Write([]byte("{"))
for k, v := range m {
buf.WriteString(fmt.Sprintf(`"%s":%d,`, k, v))
}
if len(m) > 0 {
buf.Truncate(buf.Len() - 1) // 去掉最后一個逗號
}
buf.Write([]byte("}"))
return buf.String(), nil
}
上面我們使用sync.Pool實作了一個bytes.Buffer的緩沖池，在 IntToStringMap 函式中，我們從 buffers 中獲取一個 bytes.Buffer 物件，并在函式結束時將其放回池中，避免了頻繁創建和銷毀 bytes.Buffer 物件的開銷，
同時，由于sync.Pool在IntToStringMap呼叫不頻繁的情況下，能夠自動回收sync.Pool中的bytes.Buffer物件，無需用戶操心，也能減小記憶體的壓力，而且其底層實作也有考慮到多核cpu并發執行，每一個processor都會有其對應的本地快取，在一定程度也減少了多執行緒加鎖的開銷，
從上面可以看出，sync.Pool使用起來非常簡單，但是其還是存在一些注意事項，如果使用不當的話，還是有可能會導致記憶體泄漏等問題的，下面就來介紹sync.Pool使用時的注意事項，
4.使用注意事項
4.1 需要注意放入物件的大小
如果不注意放入sync.Pool緩沖池中物件的大小，可能出現sync.Pool中只存在幾個物件，卻占據了大量的記憶體，導致記憶體泄漏，
這里對于有固定大小的物件，并不需要太過注意放入sync.Pool中物件的大小，這種場景出現記憶體泄漏的可能性小之又小，但是，如果放入sync.Pool中的物件存在自動擴容的機制，如果不注意放入sync.Pool中物件的大小，此時將很有可能導致記憶體泄漏，下面來看一個例子:
func Sprintf(format string, a ...any) string {
p := newPrinter()
p.doPrintf(format, a)
s := string(p.buf)
p.free()
return s
}
Sprintf方法根據傳入的format和對應的引數，完成組裝，回傳對應的字串結果，按照普通的思路，此時只需要申請一個byte陣列，然后根據一定規則，將format和引數的內容放入byte陣列中，最終將byte陣列轉換為字串回傳即可，
按照上面這個思路我們發現，其實每次使用到的byte陣列是可復用的，并不需要重復構建，
實際上Sprintf方法的實作也是如此，byte陣列其實并非每次創建一個新的，而是會對其進行復用，其實作了一個pp結構體，format和引數按照一定規則組裝成字串的職責，交付給pp結構體，同時byte陣列作為pp結構體的成員變數，
然后將pp的實體放入sync.Pool當中，實作pp重復使用目的，從而簡介避免了重復創建byte陣列導致頻繁的GC，同時也提升了性能，下面是newPrinter方法的邏輯，獲取pp結構體，都是從sync.Pool中獲取:
var ppFree = sync.Pool{
New: func() any { return new(pp) },
}
// newPrinter allocates a new pp struct or grabs a cached one.
func newPrinter() *pp {
// 從ppFree中獲取pp
p := ppFree.Get().(*pp)
// 執行一些初始化邏輯
p.panicking = false
p.erroring = false
p.wrapErrs = false
p.fmt.init(&p.buf)
return p
}
下面回到上面的byte陣列，此時其作為pp結構體的一個成員變數，用于字串格式化的中間結果，定義如下:
// Use simple []byte instead of bytes.Buffer to avoid large dependency.
type buffer []byte
type pp struct {
buf buffer
// 省略掉其他不相關的欄位
}
這里看起來似乎沒啥問題，但是其實是有可能存在記憶體浪費甚至記憶體泄漏的問題，假如此時存在一個非常長的字串需要格式化，此時呼叫Sprintf來實作格式化，此時pp結構體中的buffer也同樣需要不斷擴容，直到能夠存盤整個字串的長度為止，此時pp結構體中的buffer將會占據比較大的記憶體，
當Sprintf方法完成之后，重新將pp結構體放入sync.Pool當中，此時pp結構體中的buffer占據的記憶體將不會被釋放，
但是，如果下次呼叫Sprintf方法來格式化的字串，長度并沒有那么長，但是此時從sync.Pool中取出的pp結構體中的byte陣列長度卻是上次擴容之后的byte陣列，此時將會導致記憶體浪費，嚴重點甚至可能導致記憶體泄漏，
因此，因為pp物件中buffer欄位占據的記憶體是會自動擴容的，物件的大小是不固定的，因此將pp物件重新放入sync.Pool中時，需要注意放入物件的大小，如果太大，可能會導致記憶體泄漏或者記憶體浪費的情況，此時可以直接拋棄，不重新放入sync.Pool當中，事實上，pp結構體重新放入sync.Pool也是基于該邏輯，其會先判斷pp結構體中buffer欄位占據的記憶體大小，如果太大，此時將不會重新放入sync.Pool當中，而是直接丟棄，具體如下:
func (p *pp) free() {
// 如果byte陣列的大小超過一定限度，此時將會直接回傳
if cap(p.buf) > 64<<10 {
return
}
p.buf = p.buf[:0]
p.arg = nil
p.value = https://www.cnblogs.com/chenjiazhan/archive/2023/04/07/reflect.Value{}
p.wrappedErr = nil
// 否則,則重新放回sync.Pool當中
ppFree.Put(p)
}
基于以上總結，如果sync.Pool中存盤的物件占據的記憶體大小是不固定的話，此時需要注意放入物件的大小，防止記憶體泄漏或者記憶體浪費，
4.2 不要往sync.Pool中放入資料庫連接/TCP連接
TCP連接和資料庫連接等資源的獲取和釋放通常需要遵循一定的規范，比如需要在連接完成后顯式地關閉連接等，這些規范是基于網路協議、資料庫協議等規范而制定的，如果這些規范沒有被正確遵守，就可能導致連接泄漏、連接池資源耗盡等問題，
當使用 sync.Pool 存盤連接物件時，如果這些連接物件并沒有顯式的關閉，那么它們就會在記憶體中一直存在，直到行程結束，如果連接物件數量過多，那么這些未關閉的連接物件就會占用過多的記憶體資源，導致記憶體泄漏等問題，
舉個例子，假設有一個物件Conn表示資料庫連接，它的Close方法用于關閉連接，如果將Conn物件放入sync.Pool中，并在從池中取出并使用后沒有手動呼叫Close方法歸還物件，那么這些連接就會一直保持打開狀態，直到程式退出或達到連接數限制等情況，這可能會導致資源耗盡或其他一些問題，
以下是一個簡單的示例代碼，使用 sync.Pool 存盤TCP連接物件，演示了連接物件泄漏的情況：
import (
"fmt"
"net"
"sync"
"time"
)
var pool = &sync.Pool{
New: func() interface{} {
conn, err := net.Dial("tcp", "localhost:8000")
if err != nil {
panic(err)
}
return conn
},
}
func main() {
// 模擬使用連接
for i := 0; i < 100; i++ {
conn := pool.Get().(net.Conn)
time.Sleep(100 * time.Millisecond)
fmt.Fprintf(conn, "GET / HTTP/1.0\r\n\r\n")
// 不關閉連接
// 不在使用連接時，釋放連接物件到池中即可
pool.Put(conn)
}
}
在上面的代碼中，我們使用 net.Dial 創建了一個 TCP 連接，并將其存盤到 sync.Pool 中，在模擬使用連接時，我們從池中獲取連接物件，向服務器發送一個簡單的 HTTP 請求，然后將連接物件釋放到池中，但是，我們沒有顯式地關閉連接物件，如果連接物件的數量很大，那么這些未關閉的連接物件就會占用大量的記憶體資源，導致記憶體泄漏等問題，
因此，對于資料庫連接或者TCP連接這種資源的釋放需要遵循一定的規范，此時不應該使用sync.Pool來復用，可以自己實作資料庫連接池等方式來實作連接的復用，
5. 總結
本文介紹了 Go 語言中的 sync.Pool原語，它是實作物件重復利用，降低程式GC頻次，提高程式性能的一個非常好的工具，
我們首先通過一個簡單的JSON序列化器的實作，引入了需要物件重復使用的場景，進而自己實作了一個緩沖池，由該緩沖池存在的問題，進而引出sync.Pool，接著，我們介紹了sync.Pool的基本使用以及將其應用到JSON序列化器的實作當中，
在接下來，介紹了sync.Pool常見的注意事項，如需要注意放入sync.Pool物件的大小，對其進行了分析,從而講述了sync.Pool可能存在的一些注意事項，幫忙大家更好得對其進行使用，
基于以上內容，本文完成了對 sync.Pool的介紹，希望能夠幫助大家更好地理解和使用Go語言中的sync.Pool，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/549401.html
標籤：其他