Go1.18 新特性：被折騰 N 次的 TryLock
大家好，我是煎魚。
還記得我之前寫過一篇《Go 為什么不支持可重入鎖?》的文章，主要是介紹有其他語言經驗的小伙伴，想要 Go 支持可重入鎖，被殘忍拒絕的歷程。
來自《Go 為什么不支持可重入鎖?》
大佬總會有拗不過的時候，雖然不是可重入鎖。但在 Go1.18 實現了嘗試獲取鎖(TryLock)的新方法，也有點那味道了。
今天煎魚帶大家學習被折騰了 3 回的 “他”。
背景
提新功能，肯定涉及用戶場景，時間來到 2018 年，@deanveloper 就提了一個經典的加載場景：需加載幾個非常大的文件，想要一個進度條來顯示我離完成的時間有多遠。
他考慮這個進度條可以很好地利用 TryLock 來實現，以下為他的示例代碼：
func (b *ProgressBar) Add(n int) {
atomic.AddInt64(&b.Progress, int64(n))
if b.Progress >= b.Max {
b.once.Do(b.updateClientsDone)
return
}
if b.pctMx.TryLock() {
defer b.pctMx.Unlock()
b.updateClients()
}
}
上述代碼的基本邏輯，就是不斷地更新計數器，接著通過嘗試獲取鎖，來實現他的滾動加載進度條。
由于大佬們認為他這個用 channel+select-default 來做，會更好，這個用戶案例不夠足矣支撐 TryLock 的功能增加，再度被拒絕。
再戰
經過 2013、2018 年的幾次大量討論，時間再度來到 2021 年，@TyeMcQueen 舉例了大量 h2 庫的一些例子，表示有 TryLock 方法會更好的一些期許。
但也被拒絕了，Russ Cox 反對的原因是：
互斥鎖是用來保護不變量的。如果鎖被別人持有，你就沒有什么可以說的不變量了。
TryLock 方法鼓勵對鎖進行不精確的思考;它鼓勵對不變量進行假設，這些假設可能是真的，也可能不是真的。這最終成為了它自己的競賽來源。
翻身
在前幾次失敗的案例中，Russ Cox 認為給出的案例并不足以說服作為 TryLock 系列方法添加的理由。
認為需要添加的人越來越多，加上后面 Google 的大佬 Dmitry Vyukov 給出了如下案例：
表示像是 gvisor、v.io/x/lib/nsync、trivago/tgo 等軟件庫都有使用到 TryLock 的這類方法，實現與模擬代碼基本一致。
最終 Russ Cox 松口，表示：“大家都同意這是不幸的，但有時是必要的”，感覺勉強答應了。
考慮的是是給一個官方實現，而非出現各種第三方 TryLock 方法，顯得就很低效，重復實現了。
歷史的整體時間線歷程如下：
- 2013 年 @lukescott 提出《sync: mutex.TryLock》，被拒絕。
- 2018 年 @deanveloper 提出《proposal: add sync.Mutex.TryLock》，被拒絕。
- 2021 年 @TyeMcQueen 提出《sync: add Mutex.TryLock》，先被拒絕，后接受。
- 2022 年，由于之前 Go1.17 功能特性已凍結，定在 Go1.18 發布(3 月)。
新方法 sync.TryLock
在即將發布的 Go1.18 中，主要是在 sync 標準庫中新增了 TryLock 系列的相關方法。
如下圖：
sync@master#Mutex.TryLock
- Mutex.TryLock：嘗試鎖定互斥鎖，返回是否成功。
- RWMutex.TryLock：嘗試鎖定讀寫鎖，返回是否成功。
- RWMutex.TryRLock。嘗試鎖定讀鎖，返回是否成功。
官方特意提醒：雖然使用 TryLock 的場景確實存在。但應該是罕見的，使用 TryLock 往往可能是更深層次問題的標志。
總結
在 Go1.18，嘗試獲取鎖的 TryLock 方法終于落地了，該方法的存在有利有弊。像是以后可能就會成為一個 if-else 常用的判斷了，也能規避掉不少鎖阻塞導致的長時間 hold 住。
但從應用程序設計上來講，該方法的使用，有的就是有問題的，需要特別的關注和思考。
