sync.Pool 的 Get() 优先从当前 P 的 local.private 获取对象，因其无锁、零竞争、性能最高；private 为“一写一读”设计，goroutine 迁移后原 private 会泄漏；跨 P 窃取仅在 private 和 shared 均空时触发，代价高；victim cache 仅兜底延时清理，不参与 Put；Put 前必须 Reset，否则复用脏对象引发严重错误。
sync.Pool 的 Get() 为什么总从当前 P 的 local.private 开始？
因为这是最快路径——不加锁、无原子操作、零竞争。go 运行时为每个 p（逻辑处理器）维护一个 poollocal，其中 private 字段是 goroutine 在该 p 上专属的单个对象槽位，shared 是带互斥锁的链表。只要 goroutine 不迁移，get() 就只读 private，put() 也优先填它。
常见错误现象：Get() 返回的对象行为异常，但没复位；或压测时复用率远低于预期。
-
private是“一写一读”设计：Put 一次就覆盖，Get 一次就清空，不能复用多次 - 若 goroutine 在系统调用后被调度到新 P，原
private永远不会再被访问，等同于泄漏（但 GC 会回收） - 不要在
New函数里返回全局变量地址，例如&buf，否则多个 goroutine 会并发写同一内存
跨 P 窃取（steal）发生在什么时机？代价有多大？
当 Get() 在当前 P 的 private 和 shared 都为空时，才进入 getSlow()，开始遍历其他 P 的 shared 链表，从尾部 pop 一个对象——这就是“窃取”。它不是随机挑，而是按 (pid + i + 1) % GOMAXPROCS 顺序轮询，避免热点 P 被反复争抢。
性能影响明显：一次窃取涉及锁竞争、cache line 无效、跨 NUMA 节点访问（若 P 分布在不同 socket）。实测延迟常比本地 fast path 高 3–10 倍。
- 窃取失败后才会查
victim缓存（上一轮 GC 保留的对象），再失败才调New - 高 IO 并发场景下，goroutine 频繁进出阻塞态，P 迁移变多，窃取比例上升，
runtime.mallocgc调用反而增加 - 可通过
go tool trace观察sync.Pool.getSlow的调用频次，比看 “用了 Pool 没” 更反映真实收益
为什么 victim cache 只保留上一轮 GC 的对象？
Victim cache 是 Go 1.13 引入的过渡机制，用于缓解 GC 清空池时的“复用断层”。每次 GC 前，运行时把所有 P 的 local 挂到 victim，等本轮 GC 完成后再清空 victim；下轮 GC 前再把 local 挪过去。这样，刚被 GC 清掉的活跃对象，还能在下一轮 GC 前被 Get 到一次。
立即学习“go语言免费学习笔记（深入）”；
但它不是缓存增强，而是“延时清理”：victim 中的对象已脱离正常复用路径，仅作兜底。
-
victim不参与 Put：所有Put()只进当前 P 的local，不进victim - GC 后首次
Get()若命中victim，对象可能已部分失效（比如内部切片底层数组未重置） - 别依赖
victim提升复用率；它存在意义是降低 GC 瞬间 New 爆发导致的分配毛刺
Put 前不 Reset 对象，复用时会出什么问题？
Put() 只是把指针挂进链表，不做任何字段清零、切片截断或 map 清空。下次 Get() 拿到的就是“脏对象”，行为完全不可控。
典型故障场景：
-
bytes.Buffer复用后未调Reset()→WriteString()在旧内容后追加，输出长度翻倍甚至越界 - 结构体含
map[string]int字段，未在Reset()中做clear()或重建 → key 冲突、计数错乱，严重时 panic - 切片字段只做
s = s[:0]，不置nil→ 底层数组持续持有，阻碍大块内存被 GC 回收
正确做法是为复用类型显式定义 Reset() 方法，并在 Put() 前统一调用。这不是可选项，是必须项。
