内容简介:fmt包
今天参加《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。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。