您好,登錄后才能下訂單哦!
本篇內容介紹了“Go語言中的sync.Pool怎么使用”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
本文將介紹 Go 語言中的 sync.Pool
并發原語,包括sync.Pool
的基本使用方法、使用注意事項等的內容。能夠更好得使用sync.Pool
來減少對象的重復創建,最大限度實現對象的重復使用,減少程序GC的壓力,以及提升程序的性能。
這里我們實現一個簡單的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
能夠最大程度得被重復利用呢,避免重復的創建和回收呢?
其實我們可以發現,為了讓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.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) }
下面我們使用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
使用時的注意事項。
如果不注意放入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 = reflect.Value{} p.wrappedErr = nil // 否則,則重新放回sync.Pool當中 ppFree.Put(p) }
基于以上總結,如果sync.Pool
中存儲的對象占據的內存大小是不固定的話,此時需要注意放入對象的大小,防止內存泄漏或者內存浪費。
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
來復用,可以自己實現數據庫連接池等方式來實現連接的復用。
“Go語言中的sync.Pool怎么使用”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。