[譯]Go: 理解Sync.Pool的設計思想

原文：medium.com/a-journey-w…

這篇文章基於Go1.12和1.13，咱們來看看這兩個版本間sync/pool.go的革命性變化。

Sync包提供了強大的可被重複利用實例池，爲了下降垃圾回收的壓力。在使用這個包以前，須要將你的應用跑出使用pool以前與以後的benchmark數據，由於在一些狀況下使用若是你不清楚pool內部原理的話，反而會讓應用的性能降低。

pool的侷限性

咱們先來看看一些基礎的例子，來看看他在一個至關簡單狀況下（分配1K內存）是如何工做的：

type Small struct {
   a int
}

var pool = sync.Pool{
   New: func() interface{} { return new(Small) },
}

//go:noinline
func inc(s *Small) { s.a++ }

func BenchmarkWithoutPool(b *testing.B) {
   var s *Small
   for i := 0; i < b.N; i++ {
      for j := 0; j < 10000; j++ {
         s = &Small{ a: 1, }
         b.StopTimer(); inc(s); b.StartTimer()
      }
   }
}

func BenchmarkWithPool(b *testing.B) {
   var s *Small
   for i := 0; i < b.N; i++ {
      for j := 0; j < 10000; j++ {
         s = pool.Get().(*Small)
         s.a = 1
         b.StopTimer(); inc(s); b.StartTimer()
         pool.Put(s)
      }
   }
}
複製代碼

下面是兩個benchmarks，一個是使用了sync.pool一個沒有使用

name           time/op        alloc/op        allocs/op
WithoutPool-8  3.02ms ± 1%    160kB ± 0%      1.05kB ± 1%
WithPool-8     1.36ms ± 6%   1.05kB ± 0%        3.00 ± 0%
複製代碼

因爲這個遍歷有10k的迭代，那個沒有使用pool的benchmark顯示在堆上建立了10k的內存分配，而使用了pool的只使用了3. 3個分配由pool進行的，但只有一個結構體的實例被分配到內存。到目前爲止能夠看到使用pool對於內存的處理以及內存消耗上面更加友善。

可是，在實際例子裏面，當你使用pool，你的應用將會有不少新在堆上的內存分配。這種狀況下，當內存升高了，就會觸發垃圾回收。

咱們能夠強制垃圾回收的發生經過使用runtime.GC()來模擬這種情形

name           time/op        alloc/op        allocs/op
WithoutPool-8  993ms ± 1%    249kB ± 2%      10.9k ± 0%
WithPool-8     1.03s ± 4%    10.6MB ± 0%     31.0k ± 0%
複製代碼

咱們如今能夠看到使用了pool的狀況反而內存分配比不使用pool的時候高了。咱們來深刻地看一下這個包的源碼來理解爲何會這樣。

內部工做流

看一下sync/pool.go文件會給咱們展現一個初始化函數，這個函數裏面的內容能解釋咱們剛剛的情景：

func init() {
   runtime_registerPoolCleanup(poolCleanup)
}
複製代碼

這裏在運行時註冊成了一個方法去清理pools。而且一樣的方法在垃圾回收裏面也會觸發，在文件runtime/mgc.go裏面

func gcStart(trigger gcTrigger) {
   [...]
   // clearpools before we start the GC
   clearpools()
複製代碼

這就解釋了爲何當調用垃圾回收時，性能會降低。pools在每次垃圾回收啓動時都會被清理。這個文檔其實已經有警告咱們

Any item stored in the Pool may be removed automatically at any time without notification
複製代碼

接下來讓咱們建立一個工做流來理解一下這裏面是如何管理的

sync.Pool workflow in Go 1.12

咱們建立的每個sync.Pool，go都會生成一個內部池poolLocal鏈接着各個processer（GMP中的P）。這些內部的池由兩個屬性組成private和shared。前者只是他的全部者能夠訪問(push以及pop操做，也所以不須要鎖)，而`shared能夠被任何processer讀取而且是須要本身維持併發安全。而實際上，pool不是一個簡單的本地緩存，他有可能在咱們的程序中被用於任何的協程或者goroutines

Go的1.13版將改善對shared的訪問，還將帶來一個新的緩存，該緩存解決與垃圾回收器和清除池有關的問題。

新的無需鎖pool和victim cache

Go 1.13版本使用了一個新的雙向鏈表做爲shared pool，去除了鎖，提升了shared的訪問效率。這個改造主要是爲了提升緩存性能。這裏是一個訪問shared的流程

new shared pools in Go 1.13

在這個新的鏈式pool裏面，每個processpr均可以在鏈表的頭進行push與pop，而後訪問shared能夠從鏈表的尾pop出子塊。結構體的大小在擴容的時候會變成原來的兩倍，而後結構體之間使用next/prev指針進行鏈接。結構體默認大小是能夠放下8個子項。這意味着第二個結構體能夠容納16個子項，第三個是32個子項以此類推。一樣地，咱們如今再也不須要鎖，代碼執行具備原子性。

關於新緩存，新策略很是簡單。 如今有2組池：活動池和已歸檔池。 當垃圾收集器運行時，它將保留每一個池對該池內新屬性的引用，而後在清理當前池以前將池的集合複製到歸檔池中：

// Drop victim caches from all pools.
for _, p := range oldPools {
   p.victim = nil
   p.victimSize = 0
}

// Move primary cache to victim cache.
for _, p := range allPools {
   p.victim = p.local
   p.victimSize = p.localSize
   p.local = nil
   p.localSize = 0
}

// The pools with non-empty primary caches now have non-empty
// victim caches and no pools have primary caches.
oldPools, allPools = allPools, nil
複製代碼

經過這種策略，因爲受害者緩存，該應用程序如今將有一個更多的垃圾收集器週期來建立/收集帶有備份的新項目。 在工做流中，將在共享池以後在過程結束時請求犧牲者緩存。