这不会又是一个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看下程序卡在了哪里：

原来卡在了一个判断集群或服务是否是小流量的地方，该接口会接受一个集群名或服务名的参数，然后判断该集群或服务是否是小流量集群，进而做一系列事，至于做了啥不重要。小流量集群是配置在配置中心中。

我把这段代码摘出来（图中是走的判断集群分支，下面代码以更简单的服务分支讲解，底层一致）。为了避免空洞，这里我先简单讲解一下程序的逻辑：

这样圈出重点，你可能一眼就看出问题了，读锁加了两次，第二次没有必要，属于手误了。确实，删除第二个加读锁的代码就没问题了。如果事情到这就结束了，那这篇文章也没有必要写了，下面我们分析下为什么会死锁。

看到这个结果，我第一反应是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的原因。