週末又到了，爲大家準備了一份實用乾貨：如何使用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我都寫過文章，有需要自取：
下面我使用例子具體解釋DataFlow + Drawing。借用《Golang併發的次優選擇：sync包》中銀行的例子，介紹如何使用channel解決例子中銀行的併發問題：銀行支持多個用戶的同時操作。順便看下同一個併發問題，使用channel和Mutex解決是什麼差別。
一起分析下多個用戶同時操作銀行的數據流動：
- 每個人都可以向銀行發起請求，請求可以是存、取、查3種操作，並且包含操作時必要的數據，包含的數據只和自身相關。
- 銀行處理請求後給用戶發送響應，包含的數據只和操作用戶相關。
你一定發現了上面的數據流動：
- 請求數據：個人請求數據流向銀行。
- 響應數據：銀行處理結果數據流向用戶。
channel是數據流動的通道/管道，爲流動的數據建立通道，這裏需要建立2類channel：
- reqCh：傳送請求的channel，把請求從個人發送給銀行。
- retCh：傳送響應的channel，把響應從銀行發給個人。
我們把channel添加到上圖中，得到下面的圖：
以上就是從數據流動的角度，發現如何使用channel解決併發問題。思路有了，再思考下代碼層面需要怎麼做：
- 銀行：
- 定義銀行，只保存1個map即可
- 銀行操作：接收和解析請求，並把請求分發給存、取、查函數
- 實現存、取、查函數：處理請求，並把結果寫入到用戶提供的響應通道
- 定義請求和響應
- 用戶：創建請求和接收響應的通道，發送請求後等待響應，提取響應結果
- mian函數：創建銀行和用戶間的請求通道，創建銀行、用戶等協程，並等待操作完成
以上，我們這個併發問題的邏輯實現和各塊工作就清晰了，寫起來也方便、簡單。代碼實現有200多行，公衆號不方便查看，可以點閱讀原文，一鍵直達。
代碼不能貼了，運行結果還是可以的，爲了方便理解結果，介紹下示例代碼做了什麼。main函數創建了銀行、小明、小剛3個併發協程：
- 銀行：從
reqCh接收請求，依次處理每個請求，直到通道關閉，把請求交給處理函數，處理函數把結果寫入到請求中的retCh。 - 用戶小明：創建了存100、取20、查餘額的3個請求，每個請求得到響應後，再把下一個請求寫入到
reqCh。 - 用戶小剛：流程和小明相同，但存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點：
- 使用channel解決併發問題的核心在於關注數據的流動
- channel不一定是某個併發問題最好的解決方案
- map在併發中，可以不用鎖進行保護，而是使用channel
現在，回到了開篇的問題：同一個併發問題，你是用channel解決，還是用mutex解決？下面，一起看看怎麼選擇。
channel和mutex的選擇
面對一個併發問題的時候，應當選擇合適的併發方式：channel還是mutex。選擇的依據是他們的能力/特性：channel的能力是讓數據流動起來，擅長的是數據流動的場景，《Channel or Mutex》中給了3個數據流動的場景：
- 傳遞數據的所有權，即把某個數據發送給其他協程
- 分發任務，每個任務都是一個數據
- 交流異步結果，結果是一個數據
mutex的能力是數據不動，某段時間只給一個協程訪問數據的權限擅長數據位置固定的場景，《Channel or Mutex》中給了2個數據不動場景：
- 緩存
- 狀態，我們銀行例子中的
map就是一種狀態
提供解決併發問題的一個思路：
- 先找到數據的流動，並且還要畫出來，數據流動的路徑換成channel，channel的兩端設計成協程
- 基於畫出來的圖設計簡要的channel方案，代碼需要做什麼
- 這個方案是不是有點複雜，是不是用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的簡單方案，然後選擇最適合當前業務、問題的那個。
思考比結論更重要，希望你有所收穫：
- 關注數據的流動，就可以使用channel解決併發問題。
- 不流動的數據，如果存在併發訪問，嘗試使用sync.Mutex保護數據。
- channel不一定某個併發問題的最優解。
- 不要害怕、拒絕使用mutex，如果mutex是問題的最優解，那就大膽使用。
- 對於大問題，channel plus mutex也許纔是更好的方案。
參考資料
- 《Effective Go》，https://golang.org/doc/effective_go.html#sharing
- 《Mutex Or Channel》，https://github.com/golang/go/wiki/MutexOrChannel
文章推薦
- 如果這篇文章對你有幫助，請點個贊/喜歡，感謝。
- 本文作者：大彬
- 如果喜歡本文，隨意轉載，但請保留此原文鏈接：http://lessisbetter.site/2019/01/14/golang-channel-and-mutex/
