sync.Pool用于复用临时对象以减少GC压力，每个P维护本地池，GC时清空；需手动Put并重置状态，适用于无状态或可重置对象，不适用于含指针或长生命周期对象。

在 Go 中，sync.Pool 是一个用于**复用临时对象**的轻量级工具，它能显著减少 GC 压力和内存分配开销，特别适合生命周期短、创建成本高（如结构体切片、缓冲区、解析器实例等）的对象。

sync.Pool 的核心机制

sync.Pool 不保证对象一定被复用，也不保证对象不被回收——它本质是“尽力而为”的缓存：每个 P（逻辑处理器）维护本地池，GC 时会清空所有池。因此它只适用于可丢弃、无状态或可重置的对象。

• 对象放入池中后，可能被任意 goroutine 获取，也可能在下次 GC 前被自动清理
• 首次获取（Get()）若池为空，会调用 New 函数构造新对象
• 必须手动调用 Put() 归还对象，且归还前应重置其内部状态（如清空 slice、重置字段）

典型使用模式：定义带 Reset 方法的类型

推荐将复用对象封装为结构体，并提供 Reset() 方法统一清理状态，避免残留数据引发 bug。

type Buffer struct {
    data []byte
}

func (b *Buffer) Reset() {
    b.data = b.data[:0] // 截断但不释放底层数组
}

var bufferPool = sync.Pool{
    New: func() interface{} {
        return &Buffer{data: make([]byte, 0, 1024)}
    },
}

使用时：

立即学习“go语言免费学习笔记（深入）”；

• 从池中取：b := bufferPool.Get().(*Buffer)
• 使用前调用 b.Reset()
• 用完后归还：bufferPool.Put(b)

注意事项与常见陷阱

不当使用反而会增加开销或引发错误：

• 不要复用含指针/闭包/不可控状态的对象：比如持有 HTTP 请求上下文、数据库连接、未重置的 map/slice 指针，容易导致数据污染或内存泄漏
• 避免在 long-running goroutine 中长期持有 Pool 对象：本地池可能滞留对象，阻碍 GC 回收，建议即取即用、用完即还
• 注意类型断言安全：Get() 返回 interface{}，务必做类型检查或确保池中只存一种类型
• 不是万能替代方案：若对象分配极少、或生命周期长、或需精确控制生命周期，直接 new 更清晰可靠

性能对比示例（简要示意）

假设高频拼接字符串：

• 不用 Pool：每次 make([]byte, 0, N) → 多次小对象分配 + GC 扫描压力
• 用 Pool：复用底层数组，仅重置长度 → 分配次数下降 80%+，GC pause 明显缩短（压测可见）

实际效果取决于对象大小、复用率、goroutine 调度分布，建议结合 go tool pprof 观察 heap profile 和 allocs profile 验证收益。