前言:
sync.pool是golang的标准库，通过堆对象复用达到减少gc延迟的库。相比不断的创建堆对象，sync.pool通过对象复用确实可以减少gc的延迟。但sync.pool也是有损耗的，损耗主要体现在锁竞争上。go1.13版在sync.pool下了不少功夫来优化锁。
go sync.pool 优化提案，
https://github.com/golang/go/commit/d5fd2dd6a17a816b7dfd99d4df70a85f1bf0de31#diff-491b0013c82345bf6cfa937bd78b690d
代码分析:
这里简单说下sync.pool的逻辑，每个p都有独享的缓存队列，当g进行sync.pool操作时，先找到所属p的private，如果没有对象可用，加锁从 shared切片里获取数据。如果还没有拿到缓存对象，那么到其他P的poolLocal进行偷数据，如果偷不到，那么就创建新对象。
我们通过分析go 1.12 sync.pool的源码，可以发现sync.pool里会有各种的锁逻辑，从自己的shared拿数据加锁。getSlow()偷其他P缓存，也是需要给每个p加锁。put归还缓存的时候，还是会mutex加一次锁。
go mutex锁的实现原理，我在以前的文章中说过好几次了。简单说，他开始也是atomic cas自旋，默认是4次尝试，当还没有拿到锁的时候进行waitqueue gopack休眠调度处理，等待其他协程释放锁时进行goready调度唤醒。
race中的goroutine可以顺利的陷入wait queue里？不，lock_futex.go的futexsleep逻辑会加大你的锁竞争消耗。可以通过strace来追一下系统调用。
go在1.13的版本中优化了sync.pool的锁竞争问题，这里还改变了shared的数据结构，以前的版本用切片做缓存，现在换成了poolChain双端链表。这个双端链表的设计很有意思，你看sync.pool源代码会发现跟redis quicklist相似，都是链表加数组的设计。
下面是go sync.pool get和put的锁优化实现，以前不管是获取本地的shared，还是偷其他p的shared，过程都需要加锁的。1.13 sync.pool是通过atomic优化了锁竞争。
sync.pool怎么规避的死锁?
golang1.12版在private读取使用了runtime pin锁，本地shared队列使用了poolLocal的mutex锁，向其他p偷缓存时迭代每个p的shared队列，每次的迭代为了安全当然也会加锁。
那么可以想一下这样是否有死锁的风险？ 没有，我们可以从get方法跟下去，每个过程都会放锁，锁的粒度虽然很细，但释放及时。另外偷任务是顺序加锁的过程。不会出现互锁的死锁问题。
atomic cas vs mutex
上面有说 golang的mutex的实现依赖atomic cas和runtime调度。经过测试在无竞争或者少竞争的情况下，mutex的调用耗时比atomic cas仅仅多几个ns。通常来说mutex适合大锁的场景，atomic cas适合小锁的场景。sync.pool的缓存的操作本就是很快，属于小锁的范围。
如果用atomic应用到放锁 “慢” 的场景，必然会造成忙轮询。atomic不是廉价的系统调用，单次调用约7ns左右，在密集竞争下忙轮询的最高时延干到几百+ns，当然你可以使用runtime.Gosched()来切调度，但又增加了runtime的调度成本。
这是我以前写过的mutex vs atomic的性能报告，有兴趣的可以看看。
https://github.com/rfyiamcool/benchmark_lock_performance
https://github.com/rfyiamcool/benchmark_atomic_performance
go sync.pool 为啥用atomic替换mutex？
上面说了atomic cas vs mutex的区别。结合sync.pool的场景来说，从shared获取缓存对象，这个操作本应是很快的。但如果用mutex，协程竞争下会被陷入到wait queue里，等待他人放锁后被runtime goready唤醒，推到runq，然后再被调度。而使用atomic cas就简单多了，大概率多轮几次就差不多能拿锁了。
总结:
sync.pool是优化gc的利器，但也不是多多益善，还是需要用测试的数据来说话。
我的一个小经验，只要看到pprof off-cpu火焰图和strace pselect6异常，那么可以考虑优化锁竞争了。
另外文章里我省略了 victim gc的优化，毕竟在1.12版本里已经有了 victim的gc优化。