這不會(huì)又是一個(gè)Go的BUG吧？

作者：小樓MrRoshi 2022-06-15 08:14:40

Go的設(shè)計(jì)者比較「偏執(zhí)」，認(rèn)為「不好」的設(shè)計(jì)堅(jiān)決不去實(shí)現(xiàn)，就如鎖的實(shí)現(xiàn)不應(yīng)該依賴線程、協(xié)程信息；可重入（遞歸）鎖是一種不好的設(shè)計(jì)。所以這種看似有BUG的設(shè)計(jì)，也存在一定的道理。

hello，大家好呀，我是小樓。

最近我又雙叒叕寫了個(gè)BUG，一個(gè)線上服務(wù)死鎖了，不過幸虧是個(gè)新服務(wù)，沒有什么大影響。

出問題的是Go的讀寫鎖，如果你是寫Java的，不必劃走，更要看看本文，本文的重點(diǎn)在于Java和Go的讀寫鎖對(duì)比，甚至看完后你會(huì)有一個(gè)隱隱的感覺：Go的讀寫鎖是不是有BUG？

故障回放

背景簡(jiǎn)單抽象一下：一個(gè)server服務(wù)（Go語言實(shí)現(xiàn)），提供了一個(gè)http接口，另有一個(gè)client服務(wù)來調(diào)用這個(gè)接口，整體架構(gòu)非常簡(jiǎn)單，甚至都不用畫架構(gòu)圖你也能夠理解。

這兩個(gè)服務(wù)上線運(yùn)行了一段時(shí)間都沒什么問題，突然有一天client調(diào)用這個(gè)server的接口全都超時(shí)了。

碰到這種問題，第一時(shí)間去查看日志和監(jiān)控，client端全是超時(shí)日志，server端日志沒有異常，甚至連請(qǐng)求的監(jiān)控都沒有上報(bào)，仿佛client端的請(qǐng)求沒有到達(dá)server端一樣。

于是去server服務(wù)器上手動(dòng)請(qǐng)求了一下接口，結(jié)果卡主不動(dòng)，這下排除了client，一定是server端出了問題。

這種卡死的問題其實(shí)很好查，直接用pprof看協(xié)程卡在哪里基本就能得出結(jié)論（和Java的jstack類似的工具），但這個(gè)服務(wù)沒有開啟pprof，只能改了代碼打開pprof重新發(fā)布，等待下次問題復(fù)現(xiàn)。

好在運(yùn)氣不錯(cuò)，2天后問題就出來了，用pprof看下程序卡在了哪里：

原來卡在了一個(gè)判斷集群或服務(wù)是否是小流量的地方，該接口會(huì)接受一個(gè)集群名或服務(wù)名的參數(shù)，然后判斷該集群或服務(wù)是否是小流量集群，進(jìn)而做一系列事，至于做了啥不重要。小流量集群是配置在配置中心中。

我把這段代碼摘出來（圖中是走的判斷集群分支，下面代碼以更簡(jiǎn)單的服務(wù)分支講解，底層一致）。為了避免空洞，這里我先簡(jiǎn)單講解一下程序的邏輯：

首先小流量的配置定義了一個(gè)讀寫鎖（sync.RWMutex），以及在內(nèi)存中保持了哪些服務(wù)需要灰度的規(guī)則（scopesMap）

配置變更時(shí)調(diào)用reset刷新這個(gè)scopesMap，用寫鎖，后續(xù)邏輯省略:

判斷是否為灰度服務(wù)，先加讀鎖看看規(guī)則是否存在：

再加鎖判斷服務(wù)是否命中規(guī)則：

這樣圈出重點(diǎn)，你可能一眼就看出問題了，讀鎖加了兩次，第二次沒有必要，屬于手誤了。確實(shí)，刪除第二個(gè)加讀鎖的代碼就沒問題了。如果事情到這就結(jié)束了，那這篇文章也沒有必要寫了，下面我們分析下為什么會(huì)死鎖。

為什么會(huì)死鎖

看到這個(gè)結(jié)果，我第一反應(yīng)是Go的鎖的重入性問題。

熟悉Java的同學(xué)對(duì)鎖的重入并不陌生，以防有讀者不明白鎖的重入性，我用一句話來概括：

可重入鎖?就是可以重復(fù)進(jìn)入的鎖，也叫遞歸鎖。

Java中有一個(gè)ReentrantLock，比如這樣，重復(fù)加鎖是沒有問題的：

但Go里面的鎖是不可重入的：

這個(gè)坑我也踩過，這是Go的實(shí)現(xiàn)問題。只要你愿意，用Java也能實(shí)現(xiàn)不可重入鎖，但Java中大多數(shù)使用的還是可重入鎖，因?yàn)橛闷饋肀容^方便。

至于Go為什么不實(shí)現(xiàn)一個(gè)可重入的鎖，其原因總結(jié)起來就是Go的設(shè)計(jì)者覺得重入鎖是個(gè)不好的設(shè)計(jì)，所以沒有采納。不過我覺得這篇文章的評(píng)論更精彩：

說到這，你可能會(huì)說，上面出問題的明明是讀寫鎖（sync.RWMutex），讀寫鎖的特點(diǎn)是什么？

讀與讀之間不互斥

讀與寫、寫與寫之間互斥

既然讀鎖之間是不互斥，也就是可加兩次讀鎖，那么讀鎖必然是可重入的。我們寫個(gè)demo測(cè)試下：

果然如我們所想，順便看一下加讀鎖的邏輯：

看我框出的代碼，如果有寫鎖在等待，讀鎖需要等寫鎖！

這是什么邏輯？

如果一個(gè)協(xié)程已經(jīng)拿到了讀鎖，另一個(gè)協(xié)程嘗試加寫鎖，這時(shí)應(yīng)該加不了，沒什么問題。如果這個(gè)讀鎖的協(xié)程再去拿讀鎖，需要等寫鎖，這就死鎖了啊！

為了驗(yàn)證，我構(gòu)造了一個(gè)demo：

這段代碼按①、②、③順序執(zhí)行，第②段寫鎖需要等第①個(gè)讀鎖釋放，第③段讀鎖需要等第②段寫鎖釋放，最終就是一個(gè)死鎖的邏輯。

仔細(xì)想，這里面最有爭(zhēng)議的要屬已經(jīng)拿到讀鎖再次進(jìn)入讀鎖需要等寫鎖這個(gè)邏輯。

Java中是這樣的嗎？寫個(gè)demo試試：

Java一點(diǎn)事都沒有，這是為啥？遇事不決，看源碼！但Java的源碼太長(zhǎng)，又不是本文重點(diǎn)，所以就只說幾點(diǎn)重要的結(jié)論：

Java的ReentrantReadWriteLock支持鎖降級(jí)?，但不能升級(jí)，即獲取了寫鎖的線程，可以繼續(xù)獲取讀鎖，但獲取讀鎖的線程無法再獲取寫鎖；
ReentrantReadWriteLock實(shí)現(xiàn)了公平和非公平兩種鎖，公平鎖的情況下，獲取讀鎖、寫鎖前需要看同步隊(duì)列中是否先線程在我之前排隊(duì)；非公平鎖的情況下：寫鎖可以直接搶占鎖，但是讀鎖獲取有一個(gè)讓步條件，如果當(dāng)前同步隊(duì)列head.next是一個(gè)寫鎖在等待，并且自己不是重入的，就要讓步等待。

在Java的實(shí)現(xiàn)下，如果一個(gè)線程持有了讀鎖，寫鎖自然是需要等待的，但是持有讀鎖的線程也可以再次重入該讀鎖。

我們發(fā)現(xiàn)Java和Go的讀寫鎖實(shí)現(xiàn)不一致，這個(gè)不一致也就是導(dǎo)致我們寫出BUG的原因。

這合理嗎

拋開實(shí)現(xiàn)，我們思考一下這樣合理嗎？

一個(gè)協(xié)程（或線程）已經(jīng)獲取到了讀鎖，別的協(xié)程（線程）獲取寫鎖時(shí)必然需要等待讀鎖的釋放

既然這個(gè)協(xié)程（或線程）已經(jīng)擁有了這個(gè)讀鎖，那么為什么再次獲取讀鎖時(shí)需要管別的寫鎖是否等待呢？

可以想象病人排隊(duì)看醫(yī)生，前面一個(gè)病人向醫(yī)生問診，進(jìn)去后把門關(guān)上，在里面無論問多長(zhǎng)時(shí)間（理論上）是他的權(quán)利，后面的病人在他沒出來前是不能打開門的。

但Go的實(shí)現(xiàn)卻是，前一個(gè)病人每問完一句話得看一眼門外是否有人在等，如果有人在等，那他就要等門外的人問完才能問，但門外的人又在等他問，所以大家死鎖了，誰都別想看完病。

是不是細(xì)思下來，感覺這是不是Go的一個(gè)BUG？

Go為什么這么實(shí)現(xiàn)

我嘗試去github上搜索了一下，發(fā)現(xiàn)了這個(gè)issue：

https://github.com/golang/go/issues/30657

從標(biāo)題就能看出他遇到了和我一樣的問題：

Read-locking shouldn't hang if thread has already a write-lock? #30657

看看里面有人是怎么回答的：

這位大佬說，這不符合Go鎖的原理，Go的鎖是不知道協(xié)程或者線程信息的，只知道代碼調(diào)用先后順序，即讀寫鎖無法升級(jí)或降級(jí)。

Java中的鎖記錄了持有者（線程id），但Go的鎖是不知道持有者是誰，所以獲取了讀鎖之后再次獲取讀鎖，這里的邏輯是區(qū)分不了是持有者還是其他的協(xié)程，所以就統(tǒng)一處理。

這點(diǎn)其實(shí)在Go源碼的注釋中體現(xiàn)了，我也是后來才注意到：

翻譯一下是：

如果一個(gè)協(xié)程持有讀鎖，另一個(gè)協(xié)程可能會(huì)調(diào)用Lock加寫鎖，那么再也沒有一個(gè)協(xié)程可以獲得讀鎖，直到前一個(gè)讀鎖釋放，這是為了禁止讀鎖遞歸。也確保了鎖最終可用，一個(gè)阻塞的寫鎖調(diào)用會(huì)將新的讀鎖排除在外。

不過這個(gè)警示實(shí)在是太不起眼了，大概就是這個(gè)效果：