golang sync.pool对象复用 并发原理 缓存池

在go http每一次go serve(l)都会构建Request数据结构。在大量数据请求或高并发的场景中，频繁创建销毁对象，会导致GC压力。解决办法之一就是使用对象复用技术。在http协议层之下，使用对象复用技术创建Request数据结构。在http协议层之上，可以使用对象复用技术创建(w,*r,ctx)数据结构。这样即可以回快TCP层读包之后的解析速度，也可也加快请求处理的速度。

创新互联公司自2013年起，先为祁门等服务建站，祁门等地企业，进行企业商务咨询服务。为祁门企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

先上一个测试：

结论是这样的：

貌似使用池化，性能弱爆了？？？这似乎与net/http使用sync.pool池化Request来优化性能的选择相违背。这同时也说明了一个问题，好的东西，如果滥用反而造成了性能成倍的下降。在看过pool原理之后，结合实例，将给出正确的使用方法，并给出预期的效果。

sync.Pool是一个 协程安全 的 临时对象池 。数据结构如下：

local 成员的真实类型是一个 poolLocal 数组，localSize 是数组长度。这涉及到Pool实现，pool为每个P分配了一个对象，P数量设置为runtime.GOMAXPROCS(0)。在并发读写时，goroutine绑定的P有对象，先用自己的，没有去偷其它P的。go语言将数据分散在了各个真正运行的P中，降低了锁竞争，提高了并发能力。

不要习惯性地误认为New是一个关键字，这里的New是Pool的一个字段，也是一个闭包名称。其API：

如果不指定New字段，对象池为空时会返回nil，而不是一个新构建的对象。Get()到的对象是随机的。

原生sync.Pool的问题是，Pool中的对象会被GC清理掉，这使得sync.Pool只适合做简单地对象池，不适合作连接池。

pool创建时不能指定大小，没有数量限制。pool中对象会被GC清掉，只存在于两次GC之间。实现是pool的init方法注册了一个poolCleanup()函数，这个方法在GC之前执行，清空pool中的所有缓存对象。

为使多协程使用同一个POOL。最基本的想法就是每个协程，加锁去操作共享的POOL，这显然是低效的。而进一步改进，类似于ConcurrentHashMap（JDK7）的分Segment，提高其并发性可以一定程度性缓解。

注意到pool中的对象是无差异性的，加锁或者分段加锁都不是较好的做法。go的做法是为每一个绑定协程的P都分配一个子池。每个子池又分为私有池和共享列表。共享列表是分别存放在各个P之上的共享区域，而不是各个P共享的一块内存。协程拿自己P里的子池对象不需要加锁，拿共享列表中的就需要加锁了。

Get对象过程：

Put过程：

如何解决Get最坏情况遍历所有P才获取得对象呢：

方法1止前sync.pool并没有这样的设置。方法2由于goroutine被分配到哪个P由调度器调度不可控，无法确保其平衡。

由于不可控的GC导致生命周期过短，且池大小不可控，因而不适合作连接池。仅适用于增加对象重用机率，减少GC负担。2

执行结果:

单线程情况下，遍历其它无元素的P，长时间加锁性能低下。启用协程改善。

结果：

测试场景在goroutines远大于GOMAXPROCS情况下，与非池化性能差异巨大。

测试结果

可以看到同样使用*sync.pool，较大池大小的命中率较高，性能远高于空池。

结论：pool在一定的使用条件下提高并发性能，条件1是协程数远大于GOMAXPROCS，条件2是池中对象远大于GOMAXPROCS。归结成一个原因就是使对象在各个P中均匀分布。

池pool和缓存cache的区别。池的意思是，池内对象是可以互换的，不关心具体值，甚至不需要区分是新建的还是从池中拿出的。缓存指的是KV映射，缓存里的值互不相同，清除机制更为复杂。缓存清除算法如LRU、LIRS缓存算法。

池空间回收的几种方式。一些是GC前回收，一些是基于时钟或弱引用回收。最终确定在GC时回收Pool内对象，即不回避GC。用java的GC解释弱引用。GC的四种引用：强引用、弱引用、软引用、虚引用。虚引用即没有引用，弱引用GC但有空间则保留，软引用GC即清除。ThreadLocal的值为弱引用的例子。

regexp 包为了保证并发时使用同一个正则，而维护了一组状态机。

fmt包做字串拼接，从sync.pool拿[]byte对象。避免频繁构建再GC效率高很多。

Go语言——sync.Map详解

sync.Map是1.9才推荐的并发安全的map，除了互斥量以外，还运用了原子操作，所以在这之前，有必要了解下 Go语言——原子操作

go1.10\src\sync\map.go

entry分为三种情况：

从read中读取key，如果key存在就tryStore。

注意这里开始需要加锁，因为需要操作dirty。

条目在read中，首先取消标记，然后将条目保存到dirty里。（因为标记的数据不在dirty里）

最后原子保存value到条目里面，这里注意read和dirty都有条目。

总结一下Store：

这里可以看到dirty保存了数据的修改，除非可以直接原子更新read，继续保持read clean。

有了之前的经验，可以猜测下load流程：

与猜测的 区别 ：

由于数据保存两份，所以删除考虑：

先看第二种情况。加锁直接删除dirty数据。思考下貌似没什么问题，本身就是脏数据。

第一种和第三种情况唯一的区别就是条目是否被标记。标记代表删除，所以直接返回。否则CAS操作置为nil。这里总感觉少点什么，因为条目其实还是存在的，虽然指针nil。

看了一圈貌似没找到标记的逻辑，因为删除只是将他变成nil。

之前以为这个逻辑就是简单的将为标记的条目拷贝给dirty，现在看来大有文章。

p == nil，说明条目已经被delete了，CAS将他置为标记删除。然后这个条目就不会保存在dirty里面。

这里其实就跟miss逻辑串起来了，因为miss达到阈值之后，dirty会全量变成read，也就是说标记删除在这一步最终删除。这个还是很巧妙的。

真正的删除逻辑：

很绕。。。。

Go语言:sync.Once.Do

Once 结构体 和 Go()方法都是位于 sync 包下，主要为了保证 Do(func) 中的 func 只执行一次，用于单例模式是比较好的方案。

原理：

Golang中sync.Map的实现原理

前面，我们讲了map的用法以及原理 Golang中map的实现原理 ，但我们知道，map在并发读写的情况下是不安全。需要并发读写时，一般的做法是加锁，但这样性能并不高，Go语言在 1.9 版本中提供了一种效率较高的并发安全的 sync.Map，今天，我们就来讲讲 sync.Map的用法以及原理

sync.Map与map不同，不是以语言原生形态提供，而是在 sync 包下的特殊结构：

我们下来看下sync.Map结构体

结构体之间的关系如下图所示：

总结一下：

Load方法比较简单，总结一下：

总结如下：

当前名称：sync和go语言 go语言syncmap
标题路径：http://myzitong.com/article/dohcjeh.html