這不會又是一個Go的BUG吧？
hello，大家好呀，我是小樓。
最近我又雙叒叕寫了個BUG，一個線上服務死鎖了，不過幸虧是個新服務，沒有什麼大影響。
出問題的是Go的讀寫鎖，如果你是寫Java的，不必划走，更要看看本文，本文的重點在於Java和Go的讀寫鎖對比，甚至看完後你會有一個隱隱的感覺：Go的讀寫鎖是不是有BUG？
故障回放
背景簡單抽象一下：一個server服務（Go語言實現），提供了一個http介面，另有一個client服務來呼叫這個介面，整體架構非常簡單，甚至都不用畫架構圖你也能夠理解。
這兩個服務上線執行了一段時間都沒什麼問題，突然有一天client呼叫這個server的介面全都超時了。
碰到這種問題，第一時間去檢視紀錄檔和監控，client端全是超時紀錄檔，server端紀錄檔沒有異常，甚至連請求的監控都沒有上報，彷彿client端的請求沒有到達server端一樣。
於是去server伺服器上手動請求了一下介面，結果卡主不動，這下排除了client，一定是server端出了問題。
這種卡死的問題其實很好查，直接用pprof看協程卡在哪裡基本就能得出結論（和Java的jstack類似的工具），但這個服務沒有開啟pprof，只能改了程式碼開啟pprof重新發布，等待下次問題復現。
好在運氣不錯，2天后問題就出來了，用pprof看下程式卡在了哪裡：
原來卡在了一個判斷叢集或服務是否是小流量的地方，該介面會接受一個叢集名或服務名的引數，然後判斷該叢集或服務是否是小流量叢集，進而做一系列事，至於做了啥不重要。小流量叢集是設定在設定中心中。
我把這段程式碼摘出來（圖中是走的判斷叢集分支，下面程式碼以更簡單的服務分支講解，底層一致）。為了避免空洞，這裡我先簡單講解一下程式的邏輯：
- 首先小流量的設定定義了一個讀寫鎖（sync.RWMutex），以及在記憶體中保持了哪些服務需要灰度的規則（scopesMap）
- 設定變更時呼叫reset重新整理這個scopesMap，用寫鎖，後續邏輯省略
- 判斷是否為灰度服務，先加讀鎖看看規則是否存在：
- 再加鎖判斷服務是否命中規則：
這樣圈出重點，你可能一眼就看出問題了，讀鎖加了兩次，第二次沒有必要，屬於手誤了。確實，刪除第二個加讀鎖的程式碼就沒問題了。如果事情到這就結束了，那這篇文章也沒有必要寫了，下面我們分析下為什麼會死鎖。
為什麼會死鎖
看到這個結果，我第一反應是Go的鎖的重入性問題。
熟悉Java的同學對鎖的重入並不陌生，以防有讀者不明白鎖的重入性，我用一句話來概括：
可重入鎖就是可以重複進入的鎖，也叫遞迴鎖。
Java中有一個ReentrantLock，比如這樣，重複加鎖是沒有問題的：
但Go裡面的鎖是不可重入的：
這個坑我也踩過，這是Go的實現問題。只要你願意，用Java也能實現不可重入鎖，但Java中大多數使用的還是可重入鎖，因為用起來比較方便。
至於Go為什麼不實現一個可重入的鎖，可以參考煎魚大佬的這篇文章《Go 為什麼不支援可重入鎖？》 ，其原因總結起來就是Go的設計者覺得重入鎖是個不好的設計，所以沒有采納。不過我覺得這篇文章的評論更精彩：
說到這，你可能會說，上面出問題的明明是讀寫鎖（sync.RWMutex），讀寫鎖的特點是什麼？
- 讀與讀之間不互斥
- 讀與寫、寫與寫之間互斥
既然讀鎖之間是不互斥，也就是可加兩次讀鎖，那麼讀鎖必然是可重入的。我們寫個demo測試下：
果然如我們所想，順便看一下加讀鎖的邏輯：
看我框出的程式碼，如果有寫鎖在等待，讀鎖需要等寫鎖！
這是什麼邏輯？
如果一個協程已經拿到了讀鎖，另一個協程嘗試加寫鎖，這時應該加不了，沒什麼問題。如果這個讀鎖的協程再去拿讀鎖，需要等寫鎖，這就死鎖了啊！
為了驗證，我構造了一個demo：
這段程式碼按①、②、③順序執行，第②段寫鎖需要等第①個讀鎖釋放，第③段讀鎖需要等第②段寫鎖釋放，最終就是一個死鎖的邏輯。
仔細想，這裡面最有爭議的要屬已經拿到讀鎖再次進入讀鎖需要等寫鎖這個邏輯。
Java中是這樣的嗎？寫個demo試試：
Java一點事都沒有，這是為啥？遇事不決，看原始碼！但Java的原始碼太長，又不是本文重點，所以就只說幾點重要的結論：
- Java的ReentrantReadWriteLock支援鎖
降級，但不能升級，即獲取了寫鎖的執行緒，可以繼續獲取讀鎖，但獲取讀鎖的執行緒無法再獲取寫鎖； - ReentrantReadWriteLock實現了公平和非公平兩種鎖，公平鎖的情況下，獲取讀鎖、寫鎖前需要看同步佇列中是否先執行緒在我之前排隊；非公平鎖的情況下：寫鎖可以直接搶佔鎖，但是讀鎖獲取有一個讓步條件，如果當前同步佇列head.next是一個寫鎖在等待，並且自己不是重入的，就要讓步等待。
在Java的實現下，如果一個執行緒持有了讀鎖，寫鎖自然是需要等待的，但是持有讀鎖的執行緒也可以再次重入該讀鎖。
我們發現Java和Go的讀寫鎖實現不一致，這個不一致也就是導致我們寫出BUG的原因。
這合理嗎
拋開實現，我們思考一下這樣合理嗎？
- 一個協程（或執行緒）已經獲取到了讀鎖，別的協程（執行緒）獲取寫鎖時必然需要等待讀鎖的釋放
- 既然這個協程（或執行緒）已經擁有了這個讀鎖，那麼為什麼再次獲取讀鎖時需要管別的寫鎖是否等待呢？
可以想象病人排隊看醫生，前面一個病人向醫生問診，進去後把門關上，在裡面無論問多長時間（理論上）是他的權利，後面的病人在他沒出來前是不能開啟門的。
但Go的實現卻是，前一個病人每問完一句話得看一眼門外是否有人在等，如果有人在等，那他就要等門外的人問完才能問，但門外的人又在等他問，所以大家死鎖了，誰都別想看完病。
是不是細思下來，感覺這是不是Go的一個BUG？
Go為什麼這麼實現
我嘗試去github上搜尋了一下，發現了這個issue：
從標題就能看出他遇到了和我一樣的問題：
Read-locking shouldn't hang if thread has already a write-lock? #30657
看看裡面有人是怎麼回答的：
這位大佬說，這不符合Go鎖的原理，Go的鎖是不知道協程或者執行緒資訊的，只知道程式碼呼叫先後順序，即讀寫鎖無法升級或降級。
Java中的鎖記錄了持有者（執行緒id），但Go的鎖是不知道持有者是誰，所以獲取了讀鎖之後再次獲取讀鎖，這裡的邏輯是區分不了是持有者還是其他的協程，所以就統一處理。
這點其實在Go原始碼的註釋中體現了，我也是後來才注意到：
翻譯一下是：
如果一個協程持有讀鎖，另一個協程可能會呼叫Lock加寫鎖，那麼再也沒有一個協程可以獲得讀鎖，直到前一個讀鎖釋放，這是為了禁止讀鎖遞迴。也確保了鎖最終可用，一個阻塞的寫鎖呼叫會將新的讀鎖排除在外。
不過這個警示實在是太不起眼了，大概就是這個效果：
這一幕像極了產品和程式設計師：
- 產品經理：我要實現這個功能，怎麼實現我不管
- Go：這破壞了我的設計原則，不接受這個功能
- 產品經理：大家都退一步，你換個代價小的方法解決吧
於是，程式設計師在讀寫鎖上寫下了一段註釋：
最後
這個死鎖的坑確實很容易踩，尤其是Java程式設計師來寫Go，所以我們寫Go程式碼時還是得寫得更Go一點才行。
Go的設計者比較「偏執」，認為「不好」的設計堅決不去實現，就如鎖的實現不應該依賴執行緒、協程資訊；可重入（遞迴）鎖是一種不好的設計。所以這種看似有BUG的設計，也存在一定的道理。
當然每個人都有自己的想法，你覺得Go的讀寫鎖這樣實現合理嗎？
如果你看完覺得有點收穫，給個贊、在看吧，你的支援是我持續創作的動力~
搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。