1. 簡介

本文將介紹 Go 語言中的 sync.Pool并發(fā)原語，包括sync.Pool的基本使用方法、使用注意事項等的內(nèi)容。能夠更好得使用sync.Pool來減少對象的重復創(chuàng)建，最大限度實現(xiàn)對象的重復使用，減少程序GC的壓力，以及提升程序的性能。

2. 問題引入

2.1 問題描述

這里我們實現(xiàn)一個簡單的JSON序列化器，能夠?qū)崿F(xiàn)將一個map[string]int序列化為一個JSON字符串，實現(xiàn)如下:

func IntToStringMap(m map[string]int) (string, error) {
   // 定義一個bytes.Buffer,用于緩存數(shù)據(jù)
   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 來緩存數(shù)據(jù)，然后按照key:value的形式，將數(shù)據(jù)生成一個字符串，然后返回，實現(xiàn)是比較簡單的。

每次調(diào)用IntToStringMap方法時，都會創(chuàng)建一個bytes.Buffer來緩存中間結果，而bytes.Buffer其實是可以被重用的，因為序列化規(guī)則和其并沒有太大的關系，其只是作為一個緩存區(qū)來使用而已。

但是當前的實現(xiàn)為每次調(diào)用IntToStringMap時，都會創(chuàng)建一個bytes.Buffer,如果在一個應用中，請求并發(fā)量非常高時，頻繁創(chuàng)建和銷毀bytes.Buffer將會帶來較大的性能開銷，會導致對象的頻繁分配和垃圾回收，增加了內(nèi)存使用量和垃圾回收的壓力。

那有什么方法能夠讓bytes.Buffer能夠最大程度得被重復利用呢，避免重復的創(chuàng)建和回收呢？

2.2 解決方案

其實我們可以發(fā)現(xiàn)，為了讓bytes.Buffer能夠被重復利用，避免重復的創(chuàng)建和回收，我們此時只需要將bytes.Buffer緩存起來，在需要時，將其從緩存中取出；當用完后，便又將其放回到緩存池當中。這樣子，便不需要每次調(diào)用IntToStringMap方法時，就創(chuàng)建一個bytes.Buffer。

這里我們可以自己實現(xiàn)一個緩存池，當需要對象時，可以從緩存池中獲取，當不需要對象時，可以將對象放回緩存池中。IntToStringMap方法需要bytes.Buffer時，便從該緩存池中取，當用完后，便重新放回緩存池中，等待下一次的獲取。下面是一個使用切片實現(xiàn)的一個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 {
      // 當緩存池中沒有對象時,創(chuàng)建一個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實現(xiàn)了一個bytes.Buffer的緩存池，其中Get方法用于從緩存池中取對象，如果沒有對象，就創(chuàng)建一個新的對象返回；Put方法用于將對象重新放入BytesBufferPool當中，下面使用BytesBufferPool來優(yōu)化IntToStringMap。

// 首先定義一個BytesBufferPool
var buffers BytesBufferPool

func IntToStringMap(m map[string]int) (string, error) {
   // bytes.Buffer不再自己創(chuàng)建,而是從BytesBufferPool中取出
   buf := buffers.Get()
   // 函數(shù)結束后,將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
}

到這里我們通過自己實現(xiàn)了一個緩存池，成功對InitToStringMap函數(shù)進行了優(yōu)化，減少了bytes.Buffer對象頻繁的創(chuàng)建和回收，在一定程度上提高了對象的頻繁創(chuàng)建和回收。

但是，BytesBufferPool這個緩存池的實現(xiàn)，其實存在幾點問題，其一，只能用于緩存bytes.Buffer對象；其二，不能根據(jù)系統(tǒng)的實際情況，動態(tài)調(diào)整對象池中緩存對象的數(shù)量。假如某段時間并發(fā)量較高，bytes.Buffer對象被大量創(chuàng)建，用完后，重新放回BytesBufferPool之后，將永遠不會被回收，這有可能導致內(nèi)存浪費，嚴重一點，也會導致內(nèi)存泄漏。

既然自定義緩存池存在這些問題，那我們不禁要問，Go語言標準庫中有沒有提供了更方便的方式，來幫助我們緩存對象呢？

別說，還真有，Go標準庫提供了sync.Pool，可以用來緩存那些需要頻繁創(chuàng)建和銷毀的對象，而且它支持緩存任何類型的對象，同時sync.Pool是可以根據(jù)系統(tǒng)的實際情況來調(diào)整緩存池中對象的數(shù)量，如果一個對象長時間未被使用，此時將會被回收掉。

相對于自己實現(xiàn)的緩沖池，sync.Pool的性能更高，充分利用多核cpu的能力，同時也能夠根據(jù)系統(tǒng)當前使用對象的負載，來動態(tài)調(diào)整緩沖池中對象的數(shù)量，而且使用起來也比較簡單，可以說是實現(xiàn)無狀態(tài)對象緩存池的不二之選。

下面我們來看看sync.Pool的基本使用方式，然后將其應用到IntToStringMap方法的實現(xiàn)當中。

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函數(shù): 在創(chuàng)建sync.Pool時，需要傳入一個New函數(shù)，當Get方法獲取不到對象時，此時將會調(diào)用New函數(shù)創(chuàng)建新的對象返回。

3.1.2 使用方式

當使用sync.Pool時，通常需要以下幾個步驟:

• 首先使用sync.Pool定義一個對象緩沖池
• 在需要使用到對象時，從緩沖池中取出
• 當使用完之后，重新將對象放回緩沖池中

下面是一個簡單的代碼的示例，展示了使用sync.Pool大概的代碼結構:

type struct data{
    // 定義一些屬性
}
//1. 創(chuàng)建一個data對象的緩存池
var dataPool = sync.Pool{New: func() interface{} {
   return &data{}
}}

func Operation_A(){
    // 2. 需要用到data對象的地方，從緩存池中取出
    d := dataPool.Get().(*data)
    // 執(zhí)行后續(xù)操作
    // 3. 將對象重新放入緩存池中
    dataPool.Put(d)
}

3.2 使用例子    

下面我們使用sync.Pool來對IntToStringMap進行改造，實現(xiàn)對bytes.Buffer對象的重用，同時也能夠自動根據(jù)系統(tǒng)當前的狀況，自動調(diào)整緩沖池中對象的數(shù)量。

// 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實現(xiàn)了一個bytes.Buffer的緩沖池，在 IntToStringMap 函數(shù)中，我們從 buffers 中獲取一個 bytes.Buffer 對象，并在函數(shù)結束時將其放回池中，避免了頻繁創(chuàng)建和銷毀 bytes.Buffer 對象的開銷。

同時，由于sync.Pool在IntToStringMap調(diào)用不頻繁的情況下，能夠自動回收sync.Pool中的bytes.Buffer對象，無需用戶操心，也能減小內(nèi)存的壓力。而且其底層實現(xiàn)也有考慮到多核cpu并發(fā)執(zhí)行，每一個processor都會有其對應的本地緩存，在一定程度也減少了多線程加鎖的開銷。

從上面可以看出，sync.Pool使用起來非常簡單，但是其還是存在一些注意事項，如果使用不當?shù)脑?，還是有可能會導致內(nèi)存泄漏等問題的，下面就來介紹sync.Pool使用時的注意事項。

4.使用注意事項

4.1 需要注意放入對象的大小

如果不注意放入sync.Pool緩沖池中對象的大小，可能出現(xiàn)sync.Pool中只存在幾個對象，卻占據(jù)了大量的內(nèi)存，導致內(nèi)存泄漏。

這里對于有固定大小的對象，并不需要太過注意放入sync.Pool中對象的大小，這種場景出現(xiàn)內(nèi)存泄漏的可能性小之又小。但是，如果放入sync.Pool中的對象存在自動擴容的機制，如果不注意放入sync.Pool中對象的大小，此時將很有可能導致內(nèi)存泄漏。下面來看一個例子:

func Sprintf(format string, a ...any) string {
   p := newPrinter()
   p.doPrintf(format, a)
   s := string(p.buf)
   p.free()
   return s
}

Sprintf方法根據(jù)傳入的format和對應的參數(shù)，完成組裝，返回對應的字符串結果。按照普通的思路，此時只需要申請一個byte數(shù)組，然后根據(jù)一定規(guī)則，將format和參數(shù)的內(nèi)容放入byte數(shù)組中，最終將byte數(shù)組轉換為字符串返回即可。

按照上面這個思路我們發(fā)現(xiàn)，其實每次使用到的byte數(shù)組是可復用的，并不需要重復構建。

實際上Sprintf方法的實現(xiàn)也是如此，byte數(shù)組其實并非每次創(chuàng)建一個新的，而是會對其進行復用。其實現(xiàn)了一個pp結構體，format和參數(shù)按照一定規(guī)則組裝成字符串的職責，交付給pp結構體，同時byte數(shù)組作為pp結構體的成員變量。

然后將pp的實例放入sync.Pool當中，實現(xiàn)pp重復使用目的，從而簡介避免了重復創(chuàng)建byte數(shù)組導致頻繁的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)
   // 執(zhí)行一些初始化邏輯
   p.panicking = false
   p.erroring = false
   p.wrapErrs = false
   p.fmt.init(&p.buf)
   return p
}

下面回到上面的byte數(shù)組，此時其作為pp結構體的一個成員變量，用于字符串格式化的中間結果，定義如下:

// Use simple []byte instead of bytes.Buffer to avoid large dependency.
type buffer []byte

type pp struct {
   buf buffer
   // 省略掉其他不相關的字段
}

這里看起來似乎沒啥問題，但是其實是有可能存在內(nèi)存浪費甚至內(nèi)存泄漏的問題。假如此時存在一個非常長的字符串需要格式化，此時調(diào)用Sprintf來實現(xiàn)格式化，此時pp結構體中的buffer也同樣需要不斷擴容，直到能夠存儲整個字符串的長度為止，此時pp結構體中的buffer將會占據(jù)比較大的內(nèi)存。

當Sprintf方法完成之后，重新將pp結構體放入sync.Pool當中，此時pp結構體中的buffer占據(jù)的內(nèi)存將不會被釋放。

但是，如果下次調(diào)用Sprintf方法來格式化的字符串，長度并沒有那么長，但是此時從sync.Pool中取出的pp結構體中的byte數(shù)組長度卻是上次擴容之后的byte數(shù)組，此時將會導致內(nèi)存浪費，嚴重點甚至可能導致內(nèi)存泄漏。

因此，因為pp對象中buffer字段占據(jù)的內(nèi)存是會自動擴容的，對象的大小是不固定的，因此將pp對象重新放入sync.Pool中時，需要注意放入對象的大小，如果太大，可能會導致內(nèi)存泄漏或者內(nèi)存浪費的情況，此時可以直接拋棄，不重新放入sync.Pool當中。事實上，pp結構體重新放入sync.Pool也是基于該邏輯，其會先判斷pp結構體中buffer字段占據(jù)的內(nèi)存大小，如果太大，此時將不會重新放入sync.Pool當中，而是直接丟棄，具體如下:

func (p *pp) free() {
   // 如果byte數(shù)組的大小超過一定限度，此時將會直接返回
   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中存儲的對象占據(jù)的內(nèi)存大小是不固定的話，此時需要注意放入對象的大小，防止內(nèi)存泄漏或者內(nèi)存浪費。

4.2 不要往sync.Pool中放入數(shù)據(jù)庫連接/TCP連接

TCP連接和數(shù)據(jù)庫連接等資源的獲取和釋放通常需要遵循一定的規(guī)范，比如需要在連接完成后顯式地關閉連接等，這些規(guī)范是基于網(wǎng)絡協(xié)議、數(shù)據(jù)庫協(xié)議等規(guī)范而制定的，如果這些規(guī)范沒有被正確遵守，就可能導致連接泄漏、連接池資源耗盡等問題。

當使用 sync.Pool 存儲連接對象時，如果這些連接對象并沒有顯式的關閉，那么它們就會在內(nèi)存中一直存在，直到進程結束。如果連接對象數(shù)量過多，那么這些未關閉的連接對象就會占用過多的內(nèi)存資源，導致內(nèi)存泄漏等問題。

舉個例子，假設有一個對象Conn表示數(shù)據(jù)庫連接，它的Close方法用于關閉連接。如果將Conn對象放入sync.Pool中，并在從池中取出并使用后沒有手動調(diào)用Close方法歸還對象，那么這些連接就會一直保持打開狀態(tài)，直到程序退出或達到連接數(shù)限制等情況。這可能會導致資源耗盡或其他一些問題。

以下是一個簡單的示例代碼，使用 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 創(chuàng)建了一個 TCP 連接，并將其存儲到 sync.Pool 中。在模擬使用連接時，我們從池中獲取連接對象，向服務器發(fā)送一個簡單的 HTTP 請求，然后將連接對象釋放到池中。但是，我們沒有顯式地關閉連接對象。如果連接對象的數(shù)量很大，那么這些未關閉的連接對象就會占用大量的內(nèi)存資源，導致內(nèi)存泄漏等問題。

因此，對于數(shù)據(jù)庫連接或者TCP連接這種資源的釋放需要遵循一定的規(guī)范，此時不應該使用sync.Pool來復用，可以自己實現(xiàn)數(shù)據(jù)庫連接池等方式來實現(xiàn)連接的復用。

5. 總結

本文介紹了 Go 語言中的 sync.Pool原語，它是實現(xiàn)對象重復利用，降低程序GC頻次，提高程序性能的一個非常好的工具。

我們首先通過一個簡單的JSON序列化器的實現(xiàn)，引入了需要對象重復使用的場景，進而自己實現(xiàn)了一個緩沖池，由該緩沖池存在的問題，進而引出sync.Pool。接著，我們介紹了sync.Pool的基本使用以及將其應用到JSON序列化器的實現(xiàn)當中。

在接下來，介紹了sync.Pool常見的注意事項，如需要注意放入sync.Pool對象的大小，對其進行了分析,從而講述了sync.Pool可能存在的一些注意事項，幫忙大家更好得對其進行使用。

以上就是深入了解Go語言中sync.Pool的使用的詳細內(nèi)容，更多關于Go語言 sync.Pool的資料請關注腳本之家其它相關文章！

最新評論