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

前几天不是发了一篇文章《这不会又是一个Go的BUG吧？》么，没想到这篇文章话题性有点强，引发了不小的讨论。

而且我当时在文章末尾给出了一个「Go的读写锁是否合理」的投票：

一共62人投票，投票人数还是超出我的预期的，公众号关注者本来就不多，打开这篇文章的人更少，打开看完的少之又少，打开看完并且投票的，寥寥无几，从文章打开到投票的转化来看，接近10%，欣慰了。

从投票结果来看，58%选择合理，看来大家还是比较赞成Go的做法，但也有部分人觉得Go的实现还是不太合理。

这个结果意料之外，但也在情理之中。因为我的读者Java居多，我觉得Javaer可能会更偏向Java的设计，但结果却是相反。为什么呢？我觉得可能这篇文章的打开者本身就是Gopher更多，所以投票结果也在情理之中了。

说实话，这篇文章其实是个蛮好的题材，但感觉自己没写好，没有写出想要的感觉。却引发了不少讨论，由于我的公众号没有开通留言功能，这些评论主要来自发表在其他的平台如掘金、知乎、头条、博客园以及被大佬们转载的文章。我从这些讨论中挑选一些有代表性的评论，这些都引起了我一些思考，也分享给大家。

1. 为什么要重复上读锁

这可能是大家看完文章的一大疑问，我也在文中说了，这是个手误，本不该加锁两次。奈何出了问题，大家第一反应是「为什么当初要这么做」。其实这个想法非常符合常理，但我觉得如果稍微深入一点，应该问「有什么方法可以避免重复上锁」。

比较有建设性的回复应该是：打开race，提前发现问题

2. Go不是这么玩的

其实这篇文章发出去之后，我自己也是有个思想的转换，写这篇文章时，觉得Java的设计更优，但现在来看各有千秋。

而且文章中有一句话，我觉得说的不妥：

这里我的理解有误，「可重入锁」如果翻译为「递归锁」可能会更好理解，Go无论读还是写锁都是不支持可重入。

既然用Go就要遵循Go的规则，之前是我没有好好学习Go，所以这些评论也让我下定决心系统地学习一遍Go。

3. 可重入锁是个「很垃圾」的设计

作为一位Javaer，我觉得好用才是王道，至于可重入是否是个垃圾的设计，我之前没思考过，现在也说不上是否好或坏。调研过只要问的是Java开发者，他们都觉得好。不知道为什么Gopher一致地认为可重入是个垃圾的设计？

4. 应该是通讯而不是共享

这是应了Go的那句经典的「不要用共享内存来通信，要通过通信来共享内存」，但这句话我还是不能很好的理解，谁来给我一个有说服力的理解？

5. Go就是不想实现

这位老哥可能get到我的点了，Go要做成可重入锁肯定是可以做的，究竟是觉得麻烦还是发自肺腑觉得不可重入是个好设计？

最后

感谢大家能仔细看完这一篇文章，提的意见、反馈的想法我都有仔细思考，通过本文的编写过程，与小伙伴们的讨论，以及看大家的回复，我觉得我可能需要系统性地学习一下Go的底层原理了，学习过程可能会被写成文章，当然这种文章没那么「好看」，但我觉得是有意义的，如果你也刚好想学Go的底层原理，可以给我一个关注，未来我们一起成长。

搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。