大家好，我是煎魚(yú)。

還記得我之前寫(xiě)過(guò)一篇《Go 為什么不支持可重入鎖?》的文章，主要是介紹有其他語(yǔ)言經(jīng)驗(yàn)的小伙伴，想要 Go 支持可重入鎖，被殘忍拒絕的歷程。

來(lái)自《Go 為什么不支持可重入鎖?》

大佬總會(huì)有拗不過(guò)的時(shí)候，雖然不是可重入鎖。但在 Go1.18 實(shí)現(xiàn)了嘗試獲取鎖(TryLock)的新方法，也有點(diǎn)那味道了。

今天煎魚(yú)帶大家學(xué)習(xí)被折騰了 3 回的 “他”。

背景

提新功能，肯定涉及用戶(hù)場(chǎng)景，時(shí)間來(lái)到 2018 年，@deanveloper 就提了一個(gè)經(jīng)典的加載場(chǎng)景：需加載幾個(gè)非常大的文件，想要一個(gè)進(jìn)度條來(lái)顯示我離完成的時(shí)間有多遠(yuǎn)。

他考慮這個(gè)進(jìn)度條可以很好地利用 TryLock 來(lái)實(shí)現(xiàn)，以下為他的示例代碼：

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()
    }
}

上述代碼的基本邏輯，就是不斷地更新計(jì)數(shù)器，接著通過(guò)嘗試獲取鎖，來(lái)實(shí)現(xiàn)他的滾動(dòng)加載進(jìn)度條。

由于大佬們認(rèn)為他這個(gè)用 channel+select-default 來(lái)做，會(huì)更好，這個(gè)用戶(hù)案例不夠足矣支撐 TryLock 的功能增加，再度被拒絕。

再戰(zhàn)

經(jīng)過(guò) 2013、2018 年的幾次大量討論，時(shí)間再度來(lái)到 2021 年，@TyeMcQueen 舉例了大量 h2 庫(kù)的一些例子，表示有 TryLock 方法會(huì)更好的一些期許。

但也被拒絕了，Russ Cox 反對(duì)的原因是：

互斥鎖是用來(lái)保護(hù)不變量的。如果鎖被別人持有，你就沒(méi)有什么可以說(shuō)的不變量了。

TryLock 方法鼓勵(lì)對(duì)鎖進(jìn)行不精確的思考;它鼓勵(lì)對(duì)不變量進(jìn)行假設(shè)，這些假設(shè)可能是真的，也可能不是真的。這最終成為了它自己的競(jìng)賽來(lái)源。

翻身

在前幾次失敗的案例中，Russ Cox 認(rèn)為給出的案例并不足以說(shuō)服作為 TryLock 系列方法添加的理由。

認(rèn)為需要添加的人越來(lái)越多，加上后面 Google 的大佬 Dmitry Vyukov 給出了如下案例：

表示像是 gvisor、v.io/x/lib/nsync、trivago/tgo 等軟件庫(kù)都有使用到 TryLock 的這類(lèi)方法，實(shí)現(xiàn)與模擬代碼基本一致。

最終 Russ Cox 松口，表示：“大家都同意這是不幸的，但有時(shí)是必要的”，感覺(jué)勉強(qiáng)答應(yīng)了。

考慮的是是給一個(gè)官方實(shí)現(xiàn)，而非出現(xiàn)各種第三方 TryLock 方法，顯得就很低效，重復(fù)實(shí)現(xiàn)了。

歷史的整體時(shí)間線歷程如下：

• 2013 年 @lukescott 提出《sync: mutex.TryLock》，被拒絕。
• 2018 年 @deanveloper 提出《proposal: add sync.Mutex.TryLock》，被拒絕。
• 2021 年 @TyeMcQueen 提出《sync: add Mutex.TryLock》，先被拒絕，后接受。
• 2022 年，由于之前 Go1.17 功能特性已凍結(jié)，定在 Go1.18 發(fā)布(3 月)。

新方法 sync.TryLock

在即將發(fā)布的 Go1.18 中，主要是在 sync 標(biāo)準(zhǔn)庫(kù)中新增了 TryLock 系列的相關(guān)方法。

如下圖：

sync@master#Mutex.TryLock

• Mutex.TryLock：嘗試鎖定互斥鎖，返回是否成功。
• RWMutex.TryLock：嘗試鎖定讀寫(xiě)鎖，返回是否成功。
• RWMutex.TryRLock。嘗試鎖定讀鎖，返回是否成功。

官方特意提醒：雖然使用 TryLock 的場(chǎng)景確實(shí)存在。但應(yīng)該是罕見(jiàn)的，使用 TryLock 往往可能是更深層次問(wèn)題的標(biāo)志。

總結(jié)

在 Go1.18，嘗試獲取鎖的 TryLock 方法終于落地了，該方法的存在有利有弊。像是以后可能就會(huì)成為一個(gè) if-else 常用的判斷了，也能規(guī)避掉不少鎖阻塞導(dǎo)致的長(zhǎng)時(shí)間 hold 住。

但從應(yīng)用程序設(shè)計(jì)上來(lái)講，該方法的使用，有的就是有問(wèn)題的，需要特別的關(guān)注和思考。