sync.Pool 的 Put 和 Get 不是线程安全的配对操作，Get 后必须手动初始化、Put 前须确保对象可复用，New 仅兜底创建且不替代重置，无容量限制易致内存滞留，Go 1.21+ 与 pprof 存在采样冲突。
sync.Pool 的 Put 和 Get 不是线程安全的配对操作
很多人以为 Put 之后必须立刻 Get，或者认为池里对象能“自动复用”，其实 sync.Pool 完全不保证这个。它只在 GC 前清空所有缓存，且每次 Get 可能返回 nil、旧对象、甚至其他 goroutine 放进去的对象——只要没被 GC 回收掉。
典型错误现象：Get 返回的对象字段未重置，导致后续逻辑读到脏数据；或 Put 了已部分使用的对象，下次 Get 直接 panic。
- 每次
Get后必须手动初始化关键字段（比如清空 slice 底层数组、重置结构体状态） -
Put前确保对象处于可复用状态：不能持有外部引用、不能正在被其他 goroutine 使用 - 避免在 defer 中无条件
Put，比如defer pool.Put(x)在 x 是 nil 或已失效时会引发 panic
New 字段不是构造函数而是兜底工厂
New 字段只在 Get 返回 nil 时触发一次，它不控制对象生命周期，也不参与回收判断。它的作用只是“没现成对象时临时造一个”，而不是“每次 Get 都调用”。很多代码误把它当初始化钩子用，结果字段没清零、内存泄漏、甚至并发写冲突。
常见使用场景：配合结构体指针池复用 *bytes.Buffer 或自定义 request 结构体。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
New里做耗时操作（如打开文件、发起 HTTP 请求） -
New返回的对象仍需在Get后显式 reset，它不替代初始化逻辑 - 如果 New 返回的是大对象（>32KB），可能绕过 mcache 直接走 mheap，反而加重 GC 压力
Pool 大小不受控，滥用会导致内存滞留
sync.Pool 没有容量限制，每个 P（处理器）维护一个本地私有池，加上一个全局共享池。高并发下可能积累大量闲置对象，尤其在流量波峰过后，这些对象不会立即释放，而要等到下一次 GC 才统一清理。
性能影响明显：对象过多 → 堆增长 → GC 频率上升 → STW 时间变长，反而抵消复用收益。
- 监控
runtime.ReadMemStats中Mallocs和Frees差值，若长期不收敛，说明 Pool 在囤积对象 - 对生命周期明确的短时对象（如 JSON 解析中间结构体）效果最好；对长周期或不确定大小的对象（如缓存结果）慎用
- 避免嵌套池：比如用 Pool 存放含另一个 Pool 字段的结构体，容易引发不可预测的引用滞留
Go 1.21+ 的 Pool 与 pprof 采样冲突
在开启 runtime.SetMutexProfileFraction 或 runtime.SetBlockProfileRate 时，sync.Pool 的本地池迁移逻辑可能被 profiler 插桩干扰，导致 Get 返回异常对象，或 Put 失败静默丢弃。
这个问题在压测环境特别隐蔽：代码本地跑没问题，一上生产开 profiling 就偶发 panic 或数据错乱。
- 上线前务必在相同配置（含 pprof 开关）下做并发验证
- 若依赖 pprof 分析，建议把 Pool 复用逻辑和 profiling 路径隔离（比如不同 handler、不同 service 实例）
- Go 1.22 修复了部分竞态，但仍有边界 case，别假设新版就绝对安全
真正难的不是怎么写 Pool，是怎么证明它没让问题变得更糟——尤其是那些只在 GC 峰值或 profiler 开启时才冒头的毛刺。
