手摸手Go 深入剖析sync.Pool

如果能够将所有内存都分配到栈上无疑性能是最佳的，但不幸的是我们不可避免需要使用堆上分配的内存。我们可以优化使用堆内存时的性能损耗吗？答案是肯定的。Go同步包中，提供了保存和访问一组临时对象并复用它们的能力。

对于一些创建成本昂贵、频繁使用的临时对象，使用可以减少内存分配，降低GC压力。因为的gc算法是根据标记清除改进的三色标记法,如果频繁创建大量临时对象，势必给GC标记带来负担，CPU也很容易出现毛刺现象。当然需要注意的是：存储在中的对象随时都可能在不被通知的情况下被移除。所以并不是所有频繁使用、创建昂贵的对象都适用，比如DB连接、线程池。

Talk is cheap,Show me your code

因为Go1.13版本后对sync.Pool做了优化，放弃了利用sync.Mutex加锁的方式该用CAS加带环形数组的双向链表的方式来实现，本文基于Go1.15.8最新稳定版本分析。

基本使用

使用起来比较简单大概分三步：

初始化，提供一个New函数，当Pool中未缓存该对象时调用

使用从缓存池中获取对象，接着进行业务逻辑处理即可

使用完毕 利用将对象交还给缓存池

需要注意的是：跟一样第一次使用之后是不允许被拷贝的。那对性能优化真的有这么大魔力吗？Benchmark之

基准测试结果：

工作原理

allPools

如果不行 那就再来一张

pool architecture

sync.Pool数据结构

相较于之前版本，的结构体中新增了、字段主要维护了一个的数组，数组大小由决定。内部又由P私有空间和共享空间。共享空间是一个双端队列，双端队列每个节点又对应着一个环形数组，听着貌似有点儿绕，老规矩上图：

pool chain

算是个逻辑上的环形数组，字段存储着实际的值，出于操作原子性的考虑，字段将首尾索引融合在一起，高32位为head的索引下标，低32位为tail的索引下标，head和tail指向同一位置则表示环形数组为空。

headTail

代码佐证：

实际使用过程中又将进行了包装，因为数组大小是固定，所以为了让他大小可变，将其包装成了双向链表。

操作方法

接下来我们来剖析一下几个核心流程

获取对象 p.Get

获取对象，大体流程：

将当前与绑定并防止被抢占 具体是调用了，返回和P的

优先从私有空间获取对象

若私有空间没有，则尝试从共享区域获取

若共享区域也没拿到，则尝试从别人那边“偷”来一个

若偷都偷不到，那么自己手动New一个

那么我们来看看goroutine 是怎么跟P绑定的

，为啥它这么牛逼，不仅让P不会被抢占，还让GC为之折腰？

番外：禁止抢占

正如所见，兜兜转转实际绑定goroutine和P、禁用抢占交给了。首先从TLS或专用寄存器拿到当前的，然后获取当前绑定的物理线程，并对物理线程的属性自增操作。这意味什么呢？这里可能涉及到一些调度的内容，Go runtime调度是一个GPM模型。G为调度的基本单元，P可以理解为运行G的逻辑CPU M为系统线程。何为抢占？即，将绑定的P给占用，因为中99.9%的任务都需要才能执行任务。Go运行时调度主要存在两种抢占的情况：

第一种情况，进行系统调用的G，因为存在阻塞，傻傻等在那里会比较浪费计算资源，为了让其他goroutine不被饿死

第二种情况，如果一个G运行时间太长，P中其他G得不到执行也会饿死

抢占实现

中的抢占是实现的。对 没错就是里的那个也是唯一一个脱离模型只需即可运行的特例。中包含了、、、，这里抢占我们需要关注下。P处于运行中或系统调用，检查运行时间是否超过,超过则调用抢占这个主要是设置两个标志位和主要起作用的是后者。通过将的设置为,导致在执行下一次的函数调用时，栈空间检查失败（与寄存器比较），进而触发编译器安插的指令。会调用尝试栈扩容在栈扩容前会检查抢占标志位则不抢占。如果抢占成功，则会继续调用进而调用将P与当前m接触关联，设置状态,然后将插入Global runnable queue 等待下次调度。至此，应该能彻底明白为啥绑定的的属性就能禁用抢占了。

但是还有个问题，为啥GC也拿它没办法？

关于的，进而我们在GC的STW阶段执行中可以看到大致逻辑先调用尝试抢占所有的，然后停掉当前,遍历所有的，如果处于系统调用则直接掉；然后处理空闲的；最后检查是否存在需要等待处理的，如果有则循环等待，并尝试调用到这里就很清晰了，我们又看到老朋友,显然会在阶段等下去，自然也无法执行下去。好了 刚刚两个问题我们已经搞清楚了。书归正传能禁用P被抢占，那么自然能解除禁用。完成与的绑定，返回了当前的，如果则说明当前poolLocal已经存在 直接利用地址偏移拿到如果运行时被调整了呢？那么尝试下,正如其名这个过程会有点儿慢上来第一件事儿 将我们之前设置的禁用抢占给释放了。然后尝试获取全局排他锁。这也能解释它为啥上来就释放掉之前的禁止占用，因为获取当前全局排他锁不一定能立马拿到啊。拿到锁之后又开启了禁止抢占P，接着又判断了下因为拿到锁之前P可能已经变化了。如果当前p.local=nil则将p放到全局的池子里，也是为啥刚才需要等待全局排他锁的原因。因为时会将原有的pool清理掉所以这里进行重建，原有pool真的没了吗？这个就跟之前提到的有点儿关系了 等会儿一起看。

首先尝试从本地的中获取

如果本地没拿到，则尝试从共享空间拿

为节点的双向链表，首先我们尝试沿着双向链表的方向依次调用尝试从头部拿数据

逻辑也比较简单

2.1 将拆封 如果head==tail表明当前环形数组为空，直接返回

2.2 接着将head索引减1，然后将head、tail再打包回去，通过CAS判断当前没有并发修改就拿到数据 跳出循环 否则循环等待

2.3 将slot转为interface{}类型

2.4 将slot赋值为eface{}

如果共享空间依然没拿到，那么想办法从其他那偷个吧

3.1 拿到poolLocal数组，遍历每个poolLocal，并调用从其共享空间的尾部拿数据首先拿到尾节点，然后在死循环中沿着双向链表的方向不断获取节点，尝试调用获取数据与比较像，不同在于一个从头部拿数据一个从尾部拿。首先依然是在死循环中先将拆封，如果tai l==head表示环形数组为空，直接返回。否则将tail+1再封装好，同CAS规避并发问题 拿到数据则跳出循环，否则循环等待。这里有一个跟不同的是 先将value置为nil然后利用CAS来将typ置空操作,原因很简单，和一个从头放一个从尾拿数据，一旦碰头就会出现竞争。

3.2 那如果偷都偷不到，会进行以下操作

翻译过来叫“受害者缓存”

受害者缓存是由Norman Jouppi提出的一种提高缓存性能的硬件技术。如他的论文所述

Miss caching places a fully-associative cache between cache and its re-fill path. Misses in the cache that hit in the miss cache have a one cycle penalty, as opposed to a many cycle miss penalty without the miss cache. Victim Caching is an improvement to miss caching that loads the small fully-associative cache with victim of a miss and not the requested cache line.

大概意思就是在旧缓存和缓解重建的过程中，添加一个全关联的缓存（保存旧缓存数据）。也就是说当一级缓存踢出的数据，放到受害者缓存中。当我们在一级缓存未命中，则可以继续尝试从受害者缓存中查询。

如代码：

如果能理解，其实还是挺简单的，也就是

local1 ->GC ->local2 victim->local1

Local2 ->GC ->local3 victim->local2

很遗憾getSlow也没拿到 那只好自己手动new一个了

用完返回Pool p.Put

看完，接着看下

如果放入对象为空 直接返回

调用获取之前分析过大体类似

优先放入私有空间

若私有空间已满 则尝试放入共享空间

释放P禁止占用

逻辑主要是将对象放到双向链表的对应节点的环形数组中。

先获取双向链表的head节点

若head节点为空 则初始化head节点 节点对应环形数组初始大小为8

将对象放到环形数组中

跟是相反的操作，大体也比较简单。先判断环形数组是否满了，满了则直接返回。因为跟存在竞争关系，不为空可能是还没处理完。

关于GC清除数据问题

中的init函数组册了GC发生时如何清理Pool的函数,调用链如下->->逻辑很简单 正如上面讲说的那样。

最后的最后，细心的你可能发现 还遗漏了两个细节

结构体中其实是为了防止使用过程中被拷贝。至于原因应该不用多说，因为并没有提供原生的强制不能拷贝的方法。所以采用这种方式，让检测报错来实现。

举个例子

输出：

当然直接执行不会报任何错

pad

字段在这里没有啥业务意思，目的就是为了避免问题。因为我们为了缓解计算机CPU计算速度和内存的读取速度不匹配的矛盾，在他们之间增加了L1 L2 L3 高速缓存，他们比内存小很多但是速度却是内存无法比拟的。

图片来自网络

缓存系统中我们是以缓存行(cache line)为单位，通常大小为64字节。上面这张图，我们可以看到L1、L2、L3三级缓存他们和内存的读取速度当然取决于他们与CPU紧密程度。L1>L2>L3>内存

但是！我们现在使用的都是多核CPU的计算机，如何保证多核看到的数据的一致性呢？这里我们需要谈到一个协议-MESI协议，M、E、S、I分别表示缓存行的4个状态

M（修改，Modified）：本地处理器已经修改缓存行，即是脏行，它的内容与内存中的内容不一样，并且此 cache 只有本地一个拷贝(专有)；

E（专有，Exclusive）：缓存行内容和内存中的一样，而且其它处理器都没有这行数据；

S（共享，Shared）：缓存行内容和内存中的一样, 有可能其它处理器也存在此缓存行的拷贝；

I（无效，Invalid）：缓存行失效, 不能使用。

他们转换关系如下：

图片来自网络

现在假设我们有以下场景

图片来自网络

有两个变量X、Y共享在了一个中。如果core1想要更新X，core2想要更新Y，更新完他们的缓存行都变成了I状态，即L1 L2上的缓存均不可用，这时如果其他线程再要访问X Y就只能从L3甚至从内存拿数据，其性能可想而知。

怎么解决呢？

解决伪共享的问题 业界大多采用pad填充的方式来解决，让数据独占一个cacheline 降低数据关联共享的影响。比如Java8还提供了语法糖，通过添加注解自动进行缓存行填充。

总结

实现总体比较小巧，具体思想其实其他语言也都有影子，比如Java中的。但是往往简单设计的细节往往很值得我们去考究学习一下的。总结下知识点还真不少：

work stealing算法

CAS如何做到lock-free

设置抢占标志 禁止P被占用 并制止GC

Victim cache 受害者缓存是怎么回事儿

noCopy是干啥的 怎么实现禁止拷贝

伪共享(false share)

Pool GC的机制

不过这也符合Go“少即是多”的设计理念。