今天参加《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。
有疑问加站长微信联系（非本文作者）
