前戲

前面很多篇的文章都在圍繞channel介紹，而只有前一篇sync的文章介紹到了Mutex，不是我偏心，而是channel在Golang是first class級別的，設(shè)計(jì)在語言特性中的，而Mutex只是一個(gè)包中的。這就注定了一個(gè)是主角，一個(gè)是配角。

并且Golang還有一個(gè)并發(fā)座右銘，在《Effective Go》的channel介紹中寫到：

Share memory by communicating, don’t communicate by sharing memory.通過通信共享內(nèi)存，而不是通過共享內(nèi)存而通信。

Golang以如此明顯的方式告訴我們：面對并發(fā)問題，你首先想到的應(yīng)該是channel，因?yàn)閏hannel是線程安全的并且不會(huì)有數(shù)據(jù)沖突，比鎖好用多了。

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

主角不是萬能的，他也需要配角。在Golang里，channel也不是萬能的，這是由channel的特性和局限造成的。

下面就給大家介紹channel的特點(diǎn)、核心方法和缺點(diǎn)。

channel解決并發(fā)問題的思路和示例

channel的核心是數(shù)據(jù)流動(dòng)，關(guān)注到并發(fā)問題中的數(shù)據(jù)流動(dòng)，把流動(dòng)的數(shù)據(jù)放到channel中，就能使用channel解決這個(gè)并發(fā)問題。這個(gè)思路是從Go語言的核心開發(fā)者的演講中學(xué)來的，然而視頻我已經(jīng)找不到了，不然直接共享給大家，他提到了Golang并發(fā)的核心實(shí)踐的4個(gè)點(diǎn)：

DataFlow -> Drawing -> Pipieline -> Exiting

DataFlow指數(shù)據(jù)流動(dòng)，Drawing指把數(shù)據(jù)流動(dòng)畫出來，Pipeline指的是流水線，Exit指協(xié)程的退出。DataFlow + Drawing就是我提到到channel解決并發(fā)問題的思路，Pipeline和Exit是具體的實(shí)踐模式，Pipeline和Exit我都寫過文章，有需要自取：

Golang 并發(fā)模型系列：1. 輕松入門流水線模型
Golang 并發(fā)模型系列：2. 輕松入門流水線FAN模式
Golang 并發(fā)模型系列：3. 并發(fā)協(xié)程的優(yōu)雅退出

下面我使用例子具體解釋DataFlow + Drawing。借用《Golang并發(fā)模型系列：7. sync 包》中銀行的例子，介紹如何使用channel解決例子中銀行的并發(fā)問題：銀行支持多個(gè)用戶的同時(shí)操作。順便看下同一個(gè)并發(fā)問題，使用channel和Mutex解決是什么差別。

一起分析下多個(gè)用戶同時(shí)操作銀行的數(shù)據(jù)流動(dòng)：

每個(gè)人都可以向銀行發(fā)起請求，請求可以是存、取、查3種操作，并且包含操作時(shí)必要的數(shù)據(jù)，包含的數(shù)據(jù)只和自身相關(guān)。
銀行處理請求后給用戶發(fā)送響應(yīng)，包含的數(shù)據(jù)只和操作用戶相關(guān)。

你一定發(fā)現(xiàn)了上面的數(shù)據(jù)流動(dòng)：

請求數(shù)據(jù)：個(gè)人請求數(shù)據(jù)流向銀行。
響應(yīng)數(shù)據(jù)：銀行處理結(jié)果數(shù)據(jù)流向用戶。

channel是數(shù)據(jù)流動(dòng)的通道/管道，為流動(dòng)的數(shù)據(jù)建立通道，這里需要建立2類channel：

reqCh：傳送請求的channel，把請求從個(gè)人發(fā)送給銀行。
retCh：傳送響應(yīng)的channel，把響應(yīng)從銀行發(fā)給個(gè)人。

我們把channel添加到上圖中，得到下面的圖：

以上就是從數(shù)據(jù)流動(dòng)的角度，發(fā)現(xiàn)如何使用channel解決并發(fā)問題。思路有了，再思考下代碼層面需要怎么做：

銀行：
定義銀行，只保存1個(gè)map即可
銀行操作：接收和解析請求，并把請求分發(fā)給存、取、查函數(shù)
實(shí)現(xiàn)存、取、查函數(shù)：處理請求，并把結(jié)果寫入到用戶提供的響應(yīng)通道
定義請求和響應(yīng)
用戶：創(chuàng)建請求和接收響應(yīng)的通道，發(fā)送請求后等待響應(yīng)，提取響應(yīng)結(jié)果
mian函數(shù)：創(chuàng)建銀行和用戶間的請求通道，創(chuàng)建銀行、用戶等協(xié)程，并等待操作完成

以上，我們這個(gè)并發(fā)問題的邏輯實(shí)現(xiàn)和各塊工作就清晰了，寫起來也方便、簡單。代碼實(shí)現(xiàn)有200多行。

代碼不能貼了，運(yùn)行結(jié)果還是可以的，為了方便理解結(jié)果，介紹下示例代碼做了什么。main函數(shù)創(chuàng)建了銀行、小明、小剛3個(gè)并發(fā)協(xié)程：

銀行：從reqCh接收請求，依次處理每個(gè)請求，直到通道關(guān)閉，把請求交給處理函數(shù)，處理函數(shù)把結(jié)果寫入到請求中的retCh。
用戶小明：創(chuàng)建了存100、取20、查余額的3個(gè)請求，每個(gè)請求得到響應(yīng)后，再把下一個(gè)請求寫入到reqCh。
用戶小剛：流程和小明相同，但存100取200，造成取錢操作失敗，他查詢下自己又多少錢，得到100。

main函數(shù)最后使用WaitGroup等待小明、小剛結(jié)束后退出。

下面是運(yùn)行結(jié)果:

$ 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

這一遭搞完，發(fā)現(xiàn)啥沒有？用Mutex直接加鎖、解鎖完事了，但channel搞出來一坨，是不是用channel解決這個(gè)問題不太適合？是的。對于當(dāng)前這個(gè)問題，和Mutex的方案相比，channel的方案顯的有點(diǎn)“重”，不夠簡潔、高效、易用。

但這個(gè)例子展示了3點(diǎn)：

使用channel解決并發(fā)問題的核心在于關(guān)注數(shù)據(jù)的流動(dòng)
channel不一定是某個(gè)并發(fā)問題最好的解決方案
map在并發(fā)中，可以不用鎖進(jìn)行保護(hù)，而是使用channel

現(xiàn)在，回到了開篇的問題：同一個(gè)并發(fā)問題，你是用channel解決，還是用mutex解決？下面，一起看看怎么選擇。

channel和mutex的選擇

面對一個(gè)并發(fā)問題的時(shí)候，應(yīng)當(dāng)選擇合適的并發(fā)方式：channel還是mutex。選擇的依據(jù)是他們的能力/特性：channel的能力是讓數(shù)據(jù)流動(dòng)起來，擅長的是數(shù)據(jù)流動(dòng)的場景，《Channel or Mutex》中給了3個(gè)數(shù)據(jù)流動(dòng)的場景：

傳遞數(shù)據(jù)的所有權(quán)，即把某個(gè)數(shù)據(jù)發(fā)送給其他協(xié)程
分發(fā)任務(wù)，每個(gè)任務(wù)都是一個(gè)數(shù)據(jù)
交流異步結(jié)果，結(jié)果是一個(gè)數(shù)據(jù)

mutex的能力是數(shù)據(jù)不動(dòng)，某段時(shí)間只給一個(gè)協(xié)程訪問數(shù)據(jù)的權(quán)限擅長數(shù)據(jù)位置固定的場景，《Channel or Mutex》中給了2個(gè)數(shù)據(jù)不動(dòng)場景：

緩存
狀態(tài)，我們銀行例子中的map就是一種狀態(tài)

提供解決并發(fā)問題的一個(gè)思路：

先找到數(shù)據(jù)的流動(dòng)，并且還要畫出來，數(shù)據(jù)流動(dòng)的路徑換成channel，channel的兩端設(shè)計(jì)成協(xié)程
基于畫出來的圖設(shè)計(jì)簡要的channel方案，代碼需要做什么
這個(gè)方案是不是有點(diǎn)復(fù)雜，是不是用Mutex更好一點(diǎn)？設(shè)計(jì)一個(gè)簡要的Mutex方案，對比&選擇易做的、高效的

channel + mutex思維

面對并發(fā)問題，除了channel or mutex，你還有另外一個(gè)選擇：channel plus mutex。

一個(gè)大并發(fā)問題，可以分解成很多小的并發(fā)問題，每個(gè)小的并發(fā)都可以單獨(dú)選型：channel or mutex。但對于整個(gè)大的問題，通常不是channel or mutex，而是channel plus mutex。

如果你是認(rèn)為是channel and mutex也行，但我更喜歡plus，體現(xiàn)相互配合。

總結(jié)

讀到這里，感覺這篇文章頭重腳輕，channel的講了很多，而channel和mutex的選擇卻講的很少。在channel和mutex的選擇，實(shí)際并沒有一個(gè)固定答案，也沒有固定的方法，但提供了一個(gè)簡單的思路：設(shè)計(jì)出channel和Mutex的簡單方案，然后選擇最適合當(dāng)前業(yè)務(wù)、問題的那個(gè)。

思考比結(jié)論更重要，希望你有所收獲：