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

前幾天不是發(fā)了一篇文章《這不會又是一個Go的BUG吧？》么，沒想到這篇文章話題性有點強，引發(fā)了不小的討論。

而且我當時在文章末尾給出了一個「Go的讀寫鎖是否合理」的投票：

一共62人投票，投票人數(shù)還是超出我的預期的，公眾號關(guān)注者本來就不多，打開這篇文章的人更少，打開看完的少之又少，打開看完并且投票的，寥寥無幾，從文章打開到投票的轉(zhuǎn)化來看，接近10%，欣慰了。

從投票結(jié)果來看，58%選擇合理，看來大家還是比較贊成Go的做法，但也有部分人覺得Go的實現(xiàn)還是不太合理。

這個結(jié)果意料之外，但也在情理之中。因為我的讀者Java居多，我覺得Javaer可能會更偏向Java的設(shè)計，但結(jié)果卻是相反。為什么呢？我覺得可能這篇文章的打開者本身就是Gopher更多，所以投票結(jié)果也在情理之中了。

說實話，這篇文章其實是個蠻好的題材，但感覺自己沒寫好，沒有寫出想要的感覺。卻引發(fā)了不少討論，由于我的公眾號沒有開通留言功能，這些評論主要來自發(fā)表在其他的平臺如掘金、知乎、頭條、博客園以及被大佬們轉(zhuǎn)載的文章。我從這些討論中挑選一些有代表性的評論，這些都引起了我一些思考，也分享給大家。

1. 為什么要重復上讀鎖

這可能是大家看完文章的一大疑問，我也在文中說了，這是個手誤，本不該加鎖兩次。奈何出了問題，大家第一反應(yīng)是「為什么當初要這么做」。其實這個想法非常符合常理，但我覺得如果稍微深入一點，應(yīng)該問「有什么方法可以避免重復上鎖」。

比較有建設(shè)性的回復應(yīng)該是：打開race，提前發(fā)現(xiàn)問題

2. Go不是這么玩的

其實這篇文章發(fā)出去之后，我自己也是有個思想的轉(zhuǎn)換，寫這篇文章時，覺得Java的設(shè)計更優(yōu)，但現(xiàn)在來看各有千秋。

而且文章中有一句話，我覺得說的不妥：

這里我的理解有誤，「可重入鎖」如果翻譯為「遞歸鎖」可能會更好理解，Go無論讀還是寫鎖都是不支持可重入。

既然用Go就要遵循Go的規(guī)則，之前是我沒有好好學習Go，所以這些評論也讓我下定決心系統(tǒng)地學習一遍Go。

3. 可重入鎖是個「很垃圾」的設(shè)計

作為一位Javaer，我覺得好用才是王道，至于可重入是否是個垃圾的設(shè)計，我之前沒思考過，現(xiàn)在也說不上是否好或壞。調(diào)研過只要問的是Java開發(fā)者，他們都覺得好。不知道為什么Gopher一致地認為可重入是個垃圾的設(shè)計？

4. 應(yīng)該是通訊而不是共享

這是應(yīng)了Go的那句經(jīng)典的「不要用共享內(nèi)存來通信，要通過通信來共享內(nèi)存」，但這句話我還是不能很好的理解，誰來給我一個有說服力的理解？

5. Go就是不想實現(xiàn)

這位老哥可能get到我的點了，Go要做成可重入鎖肯定是可以做的，究竟是覺得麻煩還是發(fā)自肺腑覺得不可重入是個好設(shè)計？

最后

感謝大家能仔細看完這一篇文章，提的意見、反饋的想法我都有仔細思考，通過本文的編寫過程，與小伙伴們的討論，以及看大家的回復，我覺得我可能需要系統(tǒng)性地學習一下Go的底層原理了，學習過程可能會被寫成文章，當然這種文章沒那么「好看」，但我覺得是有意義的，如果你也剛好想學Go的底層原理，可以給我一個關(guān)注，未來我們一起成長。

搜索關(guān)注微信公眾號"捉蟲大師"，后端技術(shù)分享，架構(gòu)設(shè)計、性能優(yōu)化、源碼閱讀、問題排查、踩坑實踐。