Go 語(yǔ)言讓使用 Goroutine 和通道變得非常有吸引力，作為在 Go 中進(jìn)行并發(fā)的主要方式，它們是被有意識(shí)的提出的。因此對(duì)于你所遇到的任何與并發(fā)相關(guān)的問(wèn)題，它們都可能成為首選方案。但是我不確定它們是否適合于我遇到的所有問(wèn)題，我仍在考慮其中的平衡點(diǎn)。

通道和 Goroutine 對(duì)于查詢(xún)共享狀態(tài)（或從共享狀態(tài)中獲取某些信息）這類(lèi)問(wèn)題看起來(lái)似乎并不完全契合。假設(shè)你想要記錄那些與服務(wù)端建立 TLS 通信失敗的 SMTP 客戶(hù)端的 IP，以便在 TLS 握手失敗的情況下，不再提供 TLS 通信（或至少在給定的時(shí)間段內(nèi)不提供）。大多數(shù)基于通道的解決方案都很直白：一個(gè)主 Goroutine 維護(hù)一個(gè) IP 集合，通過(guò)通道向主 Goroutine 發(fā)送一條消息來(lái)向其添加 IP。但是，如何詢(xún)問(wèn)主 Goroutine 某個(gè) IP 是否已經(jīng)存在？問(wèn)題的關(guān)鍵在于，無(wú)法在共享通道上收到來(lái)自主 Goroutine 的答復(fù)，因?yàn)橹?Goroutine 無(wú)法專(zhuān)門(mén)答復(fù)你。

針對(duì)這個(gè)問(wèn)題，目前我看到的基于通道的解決方案是將一個(gè)回復(fù)通道作為查詢(xún)消息的一部分一起發(fā)送給主 goroutine（通過(guò)共享通道發(fā)送）。但是這種方法的有個(gè)副作用，那就是通道的頻繁分配和釋放，每次請(qǐng)求都會(huì)對(duì)通道進(jìn)行分配、初始化、使用一次然后銷(xiāo)毀（我認(rèn)為這些通道必須通過(guò)垃圾回收機(jī)制回收，而不是在棧上分配和釋放）。另一種方案是提供一個(gè)由 sync 包中鎖或其他同步工具顯式保護(hù)的數(shù)據(jù)結(jié)構(gòu)，這是更底層的解決方案，需要更多的管理操作，但是卻避免了通道的頻繁分配和釋放。

對(duì)于我將要編寫(xiě)的大多數(shù) Go 程序來(lái)說(shuō)，效率往往不是首要的關(guān)注點(diǎn)，真正的問(wèn)題是，如何使編寫(xiě)更容易并且代碼更清晰。目前我沒(méi)有一個(gè)徹底的結(jié)論，但卻有一個(gè)初步的、并不完全是我所期待的那個(gè)：如果要針對(duì)同一共享狀態(tài)處理不止一種查詢(xún)，那么基于鎖的方案會(huì)更容易些。

在面對(duì)多種類(lèi)型的狀態(tài)查詢(xún)時(shí)，通道方案的問(wèn)題在于它需要很多我稱(chēng)之為“類(lèi)型官僚主義”的東西。因?yàn)橥ǖ朗菗碛蓄?lèi)型的，所以對(duì)于每種不同類(lèi)型的答復(fù)都需要定義相應(yīng)的答復(fù)通道類(lèi)型（顯式或隱式）。然后，基本上每個(gè)不同的查詢(xún)也都需要自己的類(lèi)型，因?yàn)椴樵?xún)消息必須包含（類(lèi)型化的）回復(fù)通道?；阪i的方案并不會(huì)使這些類(lèi)型相關(guān)的瑣事消失，但會(huì)減輕它們帶來(lái)的痛苦，因?yàn)榇藭r(shí)查詢(xún)消息和答復(fù)只是函數(shù)的參數(shù)和返回值，因此不必將它們正式的定義為 Go 類(lèi)型（struct）。實(shí)際上，即便需要進(jìn)行額外的手動(dòng)加鎖，這對(duì)我來(lái)說(shuō)已經(jīng)是很輕松了。

（可以通過(guò)各種手段將這些類(lèi)型合并在一起從而減少通道方案中所需類(lèi)型的數(shù)量，但是此時(shí)便開(kāi)始失去類(lèi)型的安全性，尤其是編譯時(shí)類(lèi)型檢查。我喜歡 Go 中的編譯時(shí)類(lèi)型檢查，因?yàn)樗鼤?huì)很靠譜的告訴我是否遇到了明顯的錯(cuò)誤，并且這也有助于加快重構(gòu)的速度。）

從某種意義上說(shuō)，我認(rèn)為通道和 Goroutine 是 Turing tarpit 的一種形式，因?yàn)槿绻阕銐蚵斆鞯脑?huà)，可以將它們應(yīng)用于所有問(wèn)題。

（另一方面，有時(shí)通道是解決看似與它們無(wú)關(guān)的問(wèn)題的絕佳方案^[1]，在看到該文章之前，我從未想過(guò)在詞法分析器中使用 Goroutine 和通道。）

Sidebar：我所采用的 Go 鎖模式

這不是我的原創(chuàng)，而是來(lái)源于 Go blog 中的 Go maps 實(shí)戰(zhàn)^[2]一文，如下所示：

// ipEnt 是共享數(shù)據(jù)結(jié)構(gòu)中的真實(shí)條目。
type?ipEnt?struct?{
??when??time.time
??count?int
}

// ipMap 是由讀寫(xiě)鎖保護(hù)的共享數(shù)據(jù)結(jié)構(gòu)。
type?ipMap?struct?{
??sync.RWMutex
??ips?map[string]*ipEnt
}

var?notls?=?&ipMap{ips:?make(map[string]*ipEnt)}

// Add 方法用于外部調(diào)用對(duì)共享數(shù)據(jù)進(jìn)行操作，每次都會(huì)首先獲取鎖，隨后釋放它。
func?(i?*ipMap)?Add(ip?string)?{
??i.Lock()
??...?manipulate?i.ips?...
??i.Unlock()
}

使用方法來(lái)操作數(shù)據(jù)結(jié)構(gòu)感覺(jué)是最自然的方式，部分原因是由于操作和鎖定的約束條件緊密的耦合在一起。而我喜歡它純粹是因?yàn)樗鶐?lái)的簡(jiǎn)潔書(shū)寫(xiě)方式：

if?res?==?TLSERROR?{
??notls.Add(remoteip)
??....
}

最后這點(diǎn)只是個(gè)人喜好，當(dāng)然，也有人更喜歡將 ipMap 作為參數(shù)傳遞給獨(dú)立的函數(shù)。

via: https://utcc.utoronto.ca/~cks/space/blog/programming/GoGoroutinesVsLocks

作者：ChrisSiebenmann^[3]譯者：anxk^[4]校對(duì)：polaris1119^[5]

本文由 GCTT^[6] 原創(chuàng)編譯，Go 中文網(wǎng)^[7]

參考資料