《Go 同步和并发设计模式》培训会后整理 - Go语言中文社区

《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。

版权声明：本文来源CSDN，感谢博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/e421083458/article/details/90579036
站方申明：本站部分内容来自社区用户分享，若涉及侵权，请联系站方删除。
  • 发表于 2019-09-04 14:55:20
  • 阅读 ( 1801 )
  • 分类：设计模式

你可能感兴趣的文章

精选的优质文章

0 条评论

请先 登录 后评论

官方社群

GO教程

推荐文章

猜你喜欢

随便看看

来源51CTO

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！