《Go 同步和并发设计模式》培训会后整理

今天参加《Go 同步和并发设计模式》主题培训，虽然早上下雨，但是大家一般还是都在9点左右赶到现场。本次分享时间很充沛，晁老师讲的也很细致，4点就结束了高于预期啊呵呵，全程听下讲座来收获还是很多的，下面整理一下今天感觉重点的内容。

• golang中使用channel的使用率占30%，但错误率缺高于50%

  错误原因大多是使用channel不适当造成的。

  

• 读写锁RWMutex、Mutex不支持方法重入，想要实现重入可以使用黑科技goid 或者用 token

  

• 使用Cond方法进行同步操作容易出错，推荐使用简单易用的sync.WaitGroup

  

• 推荐使用go build race 进行锁竞争性检测，go vet 静态代码检测是否存锁值拷贝（因为拷贝锁值也会拷贝锁的状态信息，所以锁尽量使用指针来创建）。

  

• sync.Pool 单个回收的 bytes.Buffer  对象不应该超过64k，因为bytes.Buffer可能会增长，如果放的比较多的话，可能会导致内存占用比较多，内存不容易被释放。许多官方类库都加上了此判断。

fmt包 json包

• sync.Pool 不适合构建链接池，因为它会被系统回收掉。推荐一个构建 Socket 链接池的类库：github.com/fatih/pool

  

• 写少读多的场景下推荐使用 sync.Map，读的时候会优先读取 readOnly.m 有脏数据时才会读取 Map.dirty 数据。提高查询效率

  

• 拓展同步原语

  Semaphore 使用信号量方式实现锁

  SingleFlight 同时一堆协程请求一个资源时只允许一个协程操作，防止雪崩。

  ErrGroup Wait会等待所有协程执行完后才释放

  SpinLock 自旋锁，有些场景效率高，但是非公平

  FileLock 跨进程的Mutex

  concurrent-map 按照槽的方式存放Map数据，减少锁的竞争

• etcd 跟 zookeeper/consul/redis相比一个优点在于，它支持同步原语，如：Mutex、RWMutex

  

  而且还有最重要的选主算法

  

• 大赞 ，Channe各种场景下执行 receive/send/closed 的状态整理。

  

• Channel的高阶玩法

  Fan In 所有子Channel汇入到一个Channel中

  Fan Out 一个Channel分散成多个子Channel

  Pipeline 比如：消费者与生产者场景

  Stream Skip、Take 通过函数来控制某个数据是否写入下游Stream。