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

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

• golang中使用channel的使用率占30%，但错误率缺高于50%
  错误原因大多是使用channel不适当造成的。
  
  

• 读写锁RWMutex、Mutex不支持方法重入，想要实现重入可以使用黑科技gogid 或者用 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。