【Go弃用可重入锁】为什么可重入锁/递归锁的设计“不太好”

挺久前就想写一下了，但因太忙一直鸽着，好几月了，今天给补上

虽然网上有很多文章都有说明一些，但却没完全说透，但这里我再以最简洁的方式总结下，给出点自己看法，以最大化节省读者时间

Java里面可重入锁（递归锁）能解决重量级锁引发的死锁问题，不挺好的吗？比如下面代码（mutex相当于Java重量级锁），对外提供了两个方法F和G，如果是Java的话，调用F，进入F时Lock一次，进入G时又Lock一次，此时会出现死锁情况，相当于线程占用了资源后又自己等自己

func F() {
    mutex.Lock()
  
    preF() // 业务f1
  
    G() // 假设需要用到业务g
  
    postF() // 业务f2
  
    mutex.Unlock()
}

func G() {
    mutex.Lock()
    // 业务g
    mutex.Unlock()
}

如果是可重入锁则不会死锁，进入F时Lock一次锁的可重入次数+1，进入G时又Lock一次又+1，对应Unlock时再-1，正常执行结束。而且可重入锁可在用户进程空间实现，避免了额外开销，又能解决死锁，性能也比重量级锁好，为什么还说其设计“不太好”呢？

可以看到，作为为并发而生的Go语言一直没有引入可重入锁，就是因为Russ Cox大佬坚持可重入锁的设计理念不好，他认为，既然你加了锁，那你就要保证锁住的这部分资源/区域具有“状态不变性”，具有状态不变性的集合称为状态不变量（Russ Cox称为“