Go 为什么不提供可重入锁？

分享下Russ大神的观点，英文原版

可重入锁是一个非常差的设计。

使用锁的一个最基本的原因是，锁可以保护变量（后续称之为invariant），使其不被其他因素改变。
明确这一点，就可以判断某个场景下，是否应该使用锁。举例说明：
一个使用原子操作实现的计数器，是否需要使用锁？这取决于invariant.
如果invariant就是这个计数器本身，那么原子操作足以保证并发安全，不需要锁。
但是如果这个计数器需要和其他数据结构（比如列表中元素的个数）保持一致性，那么独立的原子操作就不够了，这种情况下就需要使用锁机制，来保证更高层次的invariant的并发安全。这也是Go中的Map不保证原子性的原因，在一般情况下，需要增加太多的开销，而没有什么收益。
下面看下可重入锁，假设有如下代码：

func F() {
    mu.Lock()
    ... do some stuff ...
    G()
    ... do some more stuff ...
    mu.Unlock()
}

func G() {
    mu.Lock()
    ... do some stuff ...
    mu.Unlock()
}

正常情况下，调用mu.Lock()后，调用者可以认为直到调用mu.Unlock()之前，自己持有了invariant。

当G在F中被调用时，或者在其他已经持有mu.Lock的地方被调用时，可重入锁使得G中的mu.Lock和mu.Unlock不可维护。当G返回时，invariant可能被持有，也可能没有被持有，这取决于F在调用G之前的操作。F甚至不知道G也需要invariant，更不知道G已经破坏了invariant，这在复杂的代码中是很有可能的。

可重入锁无法保护invariant。正常锁只有一个任务，但是可重入锁不是这样的。
即便这样去写，也是有问题的：

func F() {
    mu.Lock()
    ... do some stuff
}

在单线程的测试中，无法发现这个bug。可重入锁无法保护invariant，是可能导致大问题的。

如果想实现一个既能加锁，又可以不加锁的函数，最清晰的做法是写两个版本的函数。拿上面的G函数举例来说：

/ To be called with mu already held.
// Caller must be careful to ensure that ...
func g() {
    ... do some stuff ...
}

func G() {
    mu.Lock()
    g()
    mu.Unlock()
}

最后再次强调，使用可重入锁是一种彻彻底底的错误，它是bug的温床。