Golang并发：不再愁选channel仍是选锁

周末又到了，为你们准备了一份实用干货：如何使用channel和Mutex解决并发问题，利用周末的好时光，配上音乐，思考一下吧🤔。

来，问本身个问题：面对并发问题，是用channel解决，仍是用Mutex解决？

若是本身内心尚未清晰的答案，那就读下这篇文章，你会了解到：

• 使用channel解决并发问题的核心思路和示例
• channel擅长解决什么样的并发问题，Mutex擅长解决什么样的并发问题
• 一个并发问题该怎么入手解解决
• 一个重要的plus思惟

前戏

前面不少篇的文章都在围绕channel介绍，而只有前一篇sync的文章介绍到了Mutex，不是我偏爱，而是channel在Golang是first class级别的，设计在语言特性中的，而Mutex只是一个包中的。这就注定了一个是主角，一个是配角。

而且Golang还有一个并发座右铭，在《Effective Go》的channel介绍中写到：

Share memory by communicating, don't communicate by sharing memory.
经过通讯共享内存，而不是经过共享内存而通讯。

Golang以如此明显的方式告诉咱们：面对并发问题，你首先想到的应该是channel，由于channel是线程安全的而且不会有数据冲突，比锁好用多了。

既生瑜，何生亮。既然有channel了，为啥还提供sync.Mutex呢？

主角不是万能的，他也须要配角。在Golang里，channel也不是万能的，这是由channel的特性和局限形成的。

下面就给你们介绍channel的特色、核心方法和缺点。

channel解决并发问题的思路和示例

channel的核心是数据流动，关注到并发问题中的数据流动，把流动的数据放到channel中，就能使用channel解决这个并发问题。这个思路是从Go语言的核心开发者的演讲中学来的，然而视频我已经找不到了，否则直接共享给你们，他提到了Golang并发的核心实践的4个点：

DataFlow -> Drawing -> Pipieline -> Exiting

DataFlow指数据流动，Drawing指把数据流动画出来，Pipeline指的是流水线，Exit指协程的退出。DataFlow + Drawing就是我提到到channel解决并发问题的思路，Pipeline和Exit是具体的实践模式，Pipeline和Exit我都写过文章，有须要自取：

• Golang并发模型：轻松入门流水线模型
• Golang并发模型：轻松入门流水线FAN模式
• Golang并发模型：并发协程的优雅退出

下面我使用例子具体解释DataFlow + Drawing。借用《Golang并发的次优选择：sync包》中银行的例子，介绍如何使用channel解决例子中银行的并发问题：银行支持多个用户的同时操做。顺便看下同一个并发问题，使用channel和Mutex解决是什么差异。

一块儿分析下多个用户同时操做银行的数据流动：

1. 每一个人均可以向银行发起请求，请求能够是存、取、查3种操做，而且包含操做时必要的数据，包含的数据只和自身相关。
2. 银行处理请求后给用户发送响应，包含的数据只和操做用户相关。

你必定发现了上面的数据流动：

1. 请求数据：我的请求数据流向银行。
2. 响应数据：银行处理结果数据流向用户。

channel是数据流动的通道/管道，为流动的数据创建通道，这里须要创建2类channel：

1. reqCh：传送请求的channel，把请求从我的发送给银行。
2. retCh：传送响应的channel，把响应从银行发给我的。

咱们把channel添加到上图中，获得下面的图：

以上就是从数据流动的角度，发现如何使用channel解决并发问题。思路有了，再思考下代码层面须要怎么作：

1. 银行：

   1. 定义银行，只保存1个map便可
   2. 银行操做：接收和解析请求，并把请求分发给存、取、查函数
   3. 实现存、取、查函数：处理请求，并把结果写入到用户提供的响应通道
2. 定义请求和响应
3. 用户：建立请求和接收响应的通道，发送请求后等待响应，提取响应结果
4. mian函数：建立银行和用户间的请求通道，建立银行、用户等协程，并等待操做完成

以上，咱们这个并发问题的逻辑实现和各块工做就清晰了，写起来也方便、简单。代码实现有200多行，公众号不方便查看，能够点阅读原文，一键直达。

代码不能贴了，运行结果仍是能够的，为了方便理解结果，介绍下示例代码作了什么。main函数建立了银行、小明、小刚3个并发协程：

1. 银行：从reqCh接收请求，依次处理每一个请求，直到通道关闭，把请求交给处理函数，处理函数把结果写入到请求中的retCh。
2. 用户小明：建立了存100、取20、查余额的3个请求，每一个请求获得响应后，再把下一个请求写入到reqCh。
3. 用户小刚：流程和小明相同，但存100取200，形成取钱操做失败，他查询下本身又多少钱，获得100。

main函数最后使用WaitGroup等待小明、小刚结束后退出。

下面是运行结果:

$ go run channel_map.go
xiaogang deposite 100 success
xiaoming deposite 100 success
xiaogang withdraw 200 failed
xiaoming withdraw 20 success
xiaogang has 100
xiaoming has 80
Bank exit

这一遭搞完，发现啥没有？用Mutex直接加锁、解锁完事了，但channel搞出来一坨，是否是用channel解决这个问题不太适合？是的。对于当前这个问题，和Mutex的方案相比，channel的方案显的有点“重”，不够简洁、高效、易用。

但这个例子展现了3点：

1. 使用channel解决并发问题的核心在于关注数据的流动
2. channel不必定是某个并发问题最好的解决方案
3. map在并发中，能够不用锁进行保护，而是使用channel

如今，回到了开篇的问题：同一个并发问题，你是用channel解决，仍是用mutex解决？下面，一块儿看看怎么选择。

channel和mutex的选择

面对一个并发问题的时候，应当选择合适的并发方式：channel仍是mutex。选择的依据是他们的能力/特性：channel的能力是让数据流动起来，擅长的是数据流动的场景，《Channel or Mutex》中给了3个数据流动的场景：

1. 传递数据的全部权，即把某个数据发送给其余协程
2. 分发任务，每一个任务都是一个数据
3. 交流异步结果，结果是一个数据

mutex的能力是数据不动，某段时间只给一个协程访问数据的权限擅长数据位置固定的场景，《Channel or Mutex》中给了2个数据不动场景：

1. 缓存
2. 状态，咱们银行例子中的map就是一种状态

提供解决并发问题的一个思路：

1. 先找到数据的流动，而且还要画出来，数据流动的路径换成channel，channel的两端设计成协程
2. 基于画出来的图设计简要的channel方案，代码须要作什么
3. 这个方案是否是有点复杂，是否是用Mutex更好一点？设计一个简要的Mutex方案，对比&选择易作的、高效的

channel + mutex思惟

面对并发问题，除了channel or mutex，你还有另一个选择：channel plus mutex。

一个大并发问题，能够分解成不少小的并发问题，每一个小的并发均可以单独选型：channel or mutex。但对于整个大的问题，一般不是channel or mutex，而是channel plus mutex。

若是你是认为是channel and mutex也行，但我更喜欢plus，体现相互配合。

总结

读到这里，感受这篇文章头重脚轻，channel的讲了不少，而channel和mutex的选择却讲的不多。在channel和mutex的选择，实际并无一个固定答案，也没有固定的方法，但提供了一个简单的思路：设计出channel和Mutex的简单方案，而后选择最适合当前业务、问题的那个。

思考比结论更重要，但愿你有所收获：

1. 关注数据的流动，就可使用channel解决并发问题。
2. 不流动的数据，若是存在并发访问，尝试使用sync.Mutex保护数据。
3. channel不必定某个并发问题的最优解。
4. 不要惧怕、拒绝使用mutex，若是mutex是问题的最优解，那就大胆使用。
5. 对于大问题，channel plus mutex也许才是更好的方案。

参考资料

1. 《Effective Go》，https://golang.org/doc/effect...
2. 《Mutex Or Channel》，https://github.com/golang/go/...

文章推荐

1. Golang并发模型：轻松入门流水线模型
2. Golang并发模型：轻松入门流水线FAN模式
3. Golang并发模型：并发协程的优雅退出
4. Golang并发的次优选择：sync包

1. 若是这篇文章对你有帮助，请点个赞/喜欢，感谢。
2. 本文做者：大彬
3. 若是喜欢本文，随意转载，但请保留此原文连接：http://lessisbetter.site/2019/01/14/golang-channel-and-mutex/