这是帖子的摘录；完整的帖子可以在这里找到：https://victoriametrics.com/blog/go-sync-pool/

这篇文章是关于 Go 中处理并发的系列文章的一部分：

• Gosync.Mutex：正常和饥饿模式
• Gosync.WaitGroup 和对齐问题
• Gosync.Pool 及其背后的机制（我们在这里）
• Gosync.Cond，最被忽视的同步机制

在VictoriaMetrics源代码中，我们经常使用sync.Pool，老实说它非常适合我们处理临时对象的方式，特别是字节缓冲区或切片。

标准库中常用。例如，在encoding/json包中：

package json

var encodeStatePool sync.Pool

// An encodeState encodes JSON into a bytes.Buffer.
type encodeState struct {
    bytes.Buffer // accumulated output

    ptrLevel uint
    ptrSeen  map[any]struct{}
}

在本例中，sync.Pool 用于重用 *encodeState 对象，该对象处理将 JSON 编码为 bytes.Buffer 的过程。

我们不会在每次使用后抛出这些对象，这只会给垃圾收集器带来更多工作，而是将它们存储在池中（sync.Pool）。下次当我们需要类似的东西时，我们只需从池中获取它，而不是从头开始制作一个新的。

您还会在net/http包中找到多个sync.Pool实例，它们用于优化I/O操作：

package http

var (
    bufioReaderPool   sync.Pool
    bufioWriter2kPool sync.Pool
    bufioWriter4kPool sync.Pool
)

当服务器读取请求主体或写入响应时，它可以快速从这些池中提取预先分配的读取器或写入器，从而跳过额外的分配。此外，还设置了*bufioWriter2kPool和*bufioWriter4kPool这2个写入池来处理不同的写入需求。

func bufioWriterPool(size int) *sync.Pool {
    switch size {
    case 2 



好了，介绍就这么多了。 

今天，我们将深入探讨sync.Pool的全部内容、定义、它的使用方式、幕后情况以及您可能想知道的所有其他内容。


顺便说一句，如果你想要更实用的东西，我们的 Go 专家有一篇很好的文章，展示了我们如何在 VictoriaMetrics 中使用sync.Pool：时间序列数据库中的性能优化技术：sync.Pool 用于 CPU 绑定操作



  
  
  什么是sync.Pool？


简单来说，Go 中的sync.Pool 是一个可以保存临时对象以供以后重用的地方。 

但是事情是这样的，你无法控制池中保留多少对象，并且你放入其中的任何东西都可以随时删除，没有任何警告，阅读上一节时你就会知道为什么。

好处是，池被构建为线程安全的，因此多个 goroutine 可以同时利用它。考虑到它是同步包的一部分，这并不奇怪。


“但是我们为什么要费心重用对象呢？”


当你同时运行很多 goroutine 时，它​​们通常需要类似的对象。想象一下同时运行 go f() 多次。

如果每个 goroutine 创建自己的对象，内存使用量会快速增加，这会给垃圾收集器带来压力，因为一旦不再需要这些对象，它就必须清理它们。

这种情况会造成一个循环，高并发导致高内存使用率，从而减慢垃圾收集器的速度。 sync.Pool 旨在帮助打破这个循环。



type Object struct {
    Data []byte
}

var pool sync.Pool = sync.Pool{
    New: func() any {
        return &Object{
            Data: make([]byte, 0, 1024),
        }
    },
}




要创建一个池，您可以提供一个 New() 函数，该函数在池为空时返回一个新对象。这个函数是可选的，如果你不提供它，如果池为空，则返回 nil。

在上面的代码片段中，目标是重用 Object 结构实例，特别是其中的切片。 

重复使用切片有助于减少不必要的生长。 

例如，如果切片在使用过程中增长到 8192 字节，您可以将其长度重置为零，然后再将其放回池中。底层数组的容量仍然是 8192，因此下次需要时，这 8192 字节就可以重用了。



func (o *Object) Reset() {
    o.Data = o.Data[:0]
}

func main() {
    testObject := pool.Get().(*Object)

    // do something with testObject

    testObject.Reset()
    pool.Put(testObject)
}




流程非常清晰：您从池中获取一个对象，使用它，重置它，然后将其放回池中。重置对象可以在将其放回之前或从池中获取它之后立即完成，但这不是强制性的，这是常见的做法。

如果您不喜欢使用类型断言 pool.Get().(*Object)，有几种方法可以避免它：

• 使用专用函数从池中获取对象：

func getObjectFromPool() *Object {
    obj := pool.Get().(*Object)
    return obj
}

• 创建您自己的sync.Pool通用版本：

type Pool[T any] struct {
    sync.Pool
}

func (p *Pool[T]) Get() T {
    return p.Pool.Get().(T)
}

func (p *Pool[T]) Put(x T) {
    p.Pool.Put(x)
}

func NewPool[T any](newF func() T) *Pool[T] {
    return &Pool[T]{
        Pool: sync.Pool{
            New: func() interface{} {
                return newF()
            },
        },
    }
}

通用包装器为您提供了一种更类型安全的方式来使用池，避免类型断言。

请注意，由于额外的间接层，它增加了一点点开销。在大多数情况下，这种开销很小，但如果您处于对 CPU 高度敏感的环境中，最好运行基准测试来看看是否值得。

但是等等，还有更多。

同步池和分配陷阱

如果您从之前的许多示例（包括标准库中的示例）中注意到，我们在池中存储的通常不是对象本身，而是指向该对象的指针。

让我用一个例子来解释为什么：

var pool = sync.Pool{
    New: func() any {
        return []byte{}
    },
}

func main() {
    bytes := pool.Get().([]byte)

    // do something with bytes
    _ = bytes

    pool.Put(bytes)
}

我们正在使用[]字节池。通常（尽管并非总是），当您将值传递给接口时，可能会导致该值被放置在堆上。这种情况也发生在这里，不仅适用于切片，还适用于传递给 pool.Put() 的任何不是指针的内容。

如果使用逃逸分析进行检查：

// escape analysis
$ go build -gcflags=-m

bytes escapes to heap

现在，我不是说我们的变量字节移动到堆，我会说“字节的值通过接口转义到堆”。

为了真正理解为什么会发生这种情况，我们需要深入研究逃逸分析的工作原理（我们可能会在另一篇文章中这样做）。但是，如果我们将指针传递给 pool.Put()，则没有额外的分配：

var pool = sync.Pool{
    New: func() any {
        return new([]byte)
    },
}

func main() {
    bytes := pool.Get().(*[]byte)

    // do something with bytes
    _ = bytes

    pool.Put(bytes)
}

再次运行逃逸分析，你会发现它不再逃逸到堆中。如果你想了解更多，Go源码中有一个例子。

同步池内部结构

在我们了解sync.Pool的实际工作原理之前，有必要先了解一下Go的PMG调度模型的基础知识，这确实是sync.Pool如此高效的支柱。

有一篇很好的文章用一些视觉效果分解了 PMG 模型：Go 中的 PMG 模型

如果您今天感到懒惰并正在寻找简化的摘要，我会支持您：

PMG 代表 P（逻辑 p处理器）、M（m机器线程）和 G（g或例程）。关键是每个逻辑处理器（P）在任何时候只能有一个机器线程（M）在其上运行。为了让 goroutine (G) 运行，它需要附加到线程 (M)。

这可以归结为两个关键点：

1. 如果你有 n 个逻辑处理器 (P)，只要你至少有 n 个机器线程 (M) 可用，你就可以并行运行最多 n 个 goroutine。
2. 在任一时刻，单个处理器（P）上只能运行一个 goroutine（G）。因此，当 P1 忙于 G 时，没有其他 G 可以在该 P1 上运行，直到当前 G 被阻塞、完成或发生其他事情将其释放。

但问题是，Go 中的sync.Pool 不仅仅是一个大池，它实际上由几个“本地”池组成，每个池都与一个特定的处理器上下文（或 P）相关联，Go 的运行时是在任何给定时间进行管理。

当运行在处理器（P）上的 goroutine 需要池中的对象时，它会首先检查自己的 P 本地池，然后再查找其他地方。

完整的帖子可以在这里找到：https://victoriametrics.com/blog/go-sync-pool/