sync.Pool 适合缓存临时、可复用、无状态的对象（如 []byte、bytes.Buffer、无外部指针的结构体），不适合数据库连接等需长期持有或有状态资源；Get 后须立即 Put，New 仅作兜底且不可耗时。

sync.Pool 适合什么场景

它只适合缓存**临时、可复用、无状态**的对象，比如 []byte、bytes.Buffer、自定义结构体（不含指针到外部数据）。不适合缓存数据库连接、文件句柄、带锁的实例或跨 goroutine 长期持有的对象——Pool 不保证对象存活，GC 会随时清理，且 Get 可能返回 nil。

Get 和 Put 的正确调用顺序

必须先 Get，用完立刻 Put；不能 Put 后再 Get，也不能 Put 多次同一对象。常见错误是：在 defer 中 Put，但对象已被修改或已逃逸到其他 goroutine。

• ✅ 正确：获取 → 使用 → pool.Put(obj)
• ❌ 错误：defer pool.Put(obj) 时 obj 已被写入共享 map 或返回给调用方
• ⚠️ 注意：Get() 返回的可能是旧对象，务必重置字段（如 buf.Reset()），不能直接 append

New 字段不是构造器，而是兜底工厂

sync.Pool{New: func() interface{}{...}} 仅在 Get() 池空时调用，不控制生命周期。它不叫 “constructor”，更像 fallback allocator。不要在里面做耗时操作（如开 goroutine、IO），否则会拖慢 Get 性能。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

• ✅ 推荐：返回零值对象，例如 &MyStruct{} 或 bytes.Buffer{}
• ❌ 避免：在 New 里调用 http.Get 或初始化全局 logger
• ⚠️ 注意：New 返回 nil 是允许的，但后续 Get 可能 panic，应确保返回非 nil

为什么有时性能反而更差

滥用 Pool 会导致内存分配更频繁、GC 压力上升，尤其在对象小、生命周期短、并发低的场景。Go 1.19+ 对小对象（

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

• ? 判断依据：用 go tool pprof -alloc_space 对比启用前后堆分配量
• ? 典型受益场景：高频创建 []byte（如 JSON 解析缓冲区）、大量短命 sync.Mutex 子结构
• ? 高危信号：Put 前未清空字段、New 函数有副作用、对象含指针指向长生命周期数据

Pool 的核心约束其实就两条：对象必须可丢弃，重置必须廉价。很多人卡在“以为 Put 就是回收”，实际它只是建议 runtime “这个对象我暂时不用了”，runtime 可能立刻丢掉，也可能留着下次给你——你永远不该依赖它的存在性。