sync.Pool:提高Go語言程式性能的關鍵一步

来源:https://www.cnblogs.com/chenjiazhan/archive/2023/04/07/17297430.html
-Advertisement-
Play Games

約束(Constraints) 上一章介紹了向模型中添加一些業務邏輯的能力。我們現在可以將按鈕鏈接到業務代碼,但如何防止用戶輸入錯誤的數據?例如,在我們的房地產模塊中,沒有什麼可以阻止用戶設置負預期價格。 odoo提供了兩種設置自動驗證恆定式的方法:Python約束 and SQL約束。 SQL 參 ...


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.PoolIntToStringMap調用不頻繁的情況下,能夠自動回收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 = 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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • JavaScript字元串轉數字的5種方法及其陷阱 摘要 :JavaScript 是一個神奇的語言,字元串轉數字有 5 種方法,各有各的坑法! 原文: Converting Strings to Number in Javascript: Pitfalls 譯者: Fundebug 轉載地址: 本文 ...
  • #1、方法 const formatStr = (str) => { const value = str.replace( /[`:_~!@#$%^&*() \+ =<>?"{}|, \/ ;' \\ [ \] ·~!@#¥%……&*()—— \+ ={}|《》?:“”【】、;‘’,。、-]/g, ...
  • MVVM模式(Model-View-ViewModel):它的目標是將用戶界面(UI)的邏輯與業務邏輯分離。該模式的核心思想是將UI分為視圖(View)和視圖模型(ViewModel),並通過數據綁定實現二者之間的通信。 在MVVM模式中,視圖(View)表示用戶界面的呈現部分,視圖模型(ViewM ...
  • 本博文記錄CSS中比較常用的背景屬性,包括背景顏色:background-color、背景圖片:background-image、背景平鋪:background-repeat、背景位置:background-position和背景附著:background-attachment。同時記錄了背景色半透... ...
  • 本文分享自天翼雲開發者社區@《基於SpringBoot實現單元測試的多種情境/方法(二)》, 作者:才開始學技術的小白 1 Mock基礎回顧 在上一篇分享中我們詳細介紹了簡單的、用mock來模擬介面測試環境的方法,具體的使用樣例我們再回顧一下: 1.首先是最簡單的不需要傳參的示例,需要註意的是,可能 ...
  • 簡介 外觀模式(Facade Pattern),也叫門面模式,是一種結構型設計模式。它向現有的系統添加一個高層介面,隱藏子系統的複雜性,這個介面使得子系統更加容易使用。 如果你需要一個指向複雜子系統的直接介面,且該介面的功能有限,則可以使用外觀模式。或者需要將子系統組織為多層結構,可以使用外觀。 作 ...
  • 一個非常簡單的小項目。 看到了楊旭大佬的教學視頻,自己跟著實現了一下,完善了一下游戲邏輯。 通過空格鍵進行控制。 游戲中可按 P 鍵 暫停/恢復 游戲 項目結構 · ├── Cargo.lock ├── Cargo.toml ├── src/ │ ├── main.rs │ ├──bird/ │ │ ...
  • 本文介紹了學習Spring源碼前需要掌握的核心知識點,包括IOC、AOP、Bean生命周期、初始化和Transaction事務。通過Hello World示例,講解瞭如何使用Spring,並指出了深入瞭解Spring內部機制的方向。 ...
一周排行
    -Advertisement-
    Play Games
  • 前言 本文介紹一款使用 C# 與 WPF 開發的音頻播放器,其界面簡潔大方,操作體驗流暢。該播放器支持多種音頻格式(如 MP4、WMA、OGG、FLAC 等),並具備標記、實時歌詞顯示等功能。 另外,還支持換膚及多語言(中英文)切換。核心音頻處理採用 FFmpeg 組件,獲得了廣泛認可,目前 Git ...
  • OAuth2.0授權驗證-gitee授權碼模式 本文主要介紹如何筆者自己是如何使用gitee提供的OAuth2.0協議完成授權驗證並登錄到自己的系統,完整模式如圖 1、創建應用 打開gitee個人中心->第三方應用->創建應用 創建應用後在我的應用界面,查看已創建應用的Client ID和Clien ...
  • 解決了這個問題:《winForm下,fastReport.net 從.net framework 升級到.net5遇到的錯誤“Operation is not supported on this platform.”》 本文內容轉載自:https://www.fcnsoft.com/Home/Sho ...
  • 國內文章 WPF 從裸 Win 32 的 WM_Pointer 消息獲取觸摸點繪製筆跡 https://www.cnblogs.com/lindexi/p/18390983 本文將告訴大家如何在 WPF 裡面,接收裸 Win 32 的 WM_Pointer 消息,從消息裡面獲取觸摸點信息,使用觸摸點 ...
  • 前言 給大家推薦一個專為新零售快消行業打造了一套高效的進銷存管理系統。 系統不僅具備強大的庫存管理功能,還集成了高性能的輕量級 POS 解決方案,確保頁面載入速度極快,提供良好的用戶體驗。 項目介紹 Dorisoy.POS 是一款基於 .NET 7 和 Angular 4 開發的新零售快消進銷存管理 ...
  • ABP CLI常用的代碼分享 一、確保環境配置正確 安裝.NET CLI: ABP CLI是基於.NET Core或.NET 5/6/7等更高版本構建的,因此首先需要在你的開發環境中安裝.NET CLI。這可以通過訪問Microsoft官網下載並安裝相應版本的.NET SDK來實現。 安裝ABP ...
  • 問題 問題是這樣的:第三方的webapi,需要先調用登陸介面獲取Cookie,訪問其它介面時攜帶Cookie信息。 但使用HttpClient類調用登陸介面,返回的Headers中沒有找到Cookie信息。 分析 首先,使用Postman測試該登陸介面,正常返回Cookie信息,說明是HttpCli ...
  • 國內文章 關於.NET在中國為什麼工資低的分析 https://www.cnblogs.com/thinkingmore/p/18406244 .NET在中國開發者的薪資偏低,主要因市場需求、技術棧選擇和企業文化等因素所致。歷史上,.NET曾因微軟的閉源策略發展受限,儘管後來推出了跨平臺的.NET ...
  • 在WPF開發應用中,動畫不僅可以引起用戶的註意與興趣,而且還使軟體更加便於使用。前面幾篇文章講解了畫筆(Brush),形狀(Shape),幾何圖形(Geometry),變換(Transform)等相關內容,今天繼續講解動畫相關內容和知識點,僅供學習分享使用,如有不足之處,還請指正。 ...
  • 什麼是委托? 委托可以說是把一個方法代入另一個方法執行,相當於指向函數的指針;事件就相當於保存委托的數組; 1.實例化委托的方式: 方式1:通過new創建實例: public delegate void ShowDelegate(); 或者 public delegate string ShowDe ...