为什么golang不支持可重入锁

这里是小奏 ,觉得文章不错可以关注公众号小奏技术

java中的可重入锁

熟悉java的朋友都知道,在java中不管是synchronized还是ReentrantLock都是可重入锁,使用起来也非常简单

synchronized

  • 同步实例方法
java 复制代码
public synchronized void instanceMethod() {
    // 同步方法的代码
}
  • 同步静态方法
java 复制代码
public static synchronized void staticMethod() {
    // 同步方法的代码
}
  • 同步代码块
java 复制代码
public void someMethod() {
    synchronized(this) {
        // 同步代码块
    }
}

上面都是基于this对象实例的锁,静态方法的锁是当前类的Class对象

当然也可以使用其他对象实例的锁,手动传入一个对象

java 复制代码
private final Object lock = new Object();

public void someMethod() {
    synchronized(lock) {
        // 同步代码块
    }
}

ReentrantLock

ReentrantLock就是手动挡,但是也支持重入

java 复制代码
public class XiaoZou {
    
    private final Lock lock = new ReentrantLock();

    public void someMethod() {
        lock.lock();
        lock.lock();
        try {
            // 同步代码块
        } finally {
            lock.unlock();
            lock.unlock();
        }
    }
}

核心原理

其实可重入锁的核心原理就是维护一个monitor计数器即可,每次加锁+1,解锁-1,当monitor0的时候才能释放锁

大致流程如下图

对于大佬们来说设计支持可重入锁的锁也是非常简单的,那为什么golang不支持呢?

golang中的Mutex

实际golang中比较简单经典的锁用法就是

go 复制代码
func main() {
    var mu sync.Mutex
    mu.Lock()
    defer mu.Unlock()
}

如果我们试试一把锁加多次会怎么样呢?

go 复制代码
func main() {
    var mu sync.Mutex
    mu.Lock()
    mu.Lock()
    defer mu.Unlock()
}

没错,报错了

sql 复制代码
fatal error: all goroutines are asleep - deadlock!

说明golang是不支持可重入锁的

golang为什么不支持可重入锁

我们去golang官方社区,查找相关issues就会发现早有人提出一样的问题

go/issues/24192: github.com/golang/go/i...

有一位小伙伴提出可重入锁通常意味着坏代码,然后贴上了stackoverflow的讨论地址 stackoverflow:stackoverflow.com/questions/1...

golang的官方说法,如果你遇到了需要使用重入锁的场景,实际是你的代码出现了坏味道,你需要重新设计你的代码

互斥锁的本意就是"我需要保持不变".可重入锁会破坏他们

我们看看官方给的例子

go 复制代码
     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

如果递归互斥锁的实现允许在当前线程已经持有 mu 时, 让 G 中的 mu.Lockmu.Unlock 调用变成无操作, 那么当在 G 内部 mu.Lock 返回时,不变量可能成立,也可能不成立。这取决于 F 在调用 G 之前做了什么。 或许 F 并没有意识到 G 需要这些不变量,并且已经破坏了它们(在复杂代码中这完全有可能)

从互斥宏观角度来看,要么是F执行,要么是G执行,两者是互斥的,这就是mu的原语 但是可重入打破了这个原语,因为F和G都可以同时执行,这就是mu的原语被破坏了

所以如果你要实现类似的功能推荐你使用如下方式去代替

go 复制代码
     func g() {
             ... do some stuff ...
     }

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

递归互斥锁只是一个错误,不过是滋生漏洞的温床

总结

总的来说就是goalng的设计者Russ Cox认为可重入是一种错误设计,会破坏mu互斥的原语

本来在原语上两个应该互斥的方法因为可重入变的不互斥了,出现需要可重入锁的场景,实际上是你的代码出现了坏味道,需要重新设计

可以看到golang从设计层面就避免了很多坏代码的味道,比如不支持可重入锁,不支持循环引用等。从编译层面去规范代码,这也是golang的一大特色

但是也就带来了一些开发上的不便利,你需要花费更多的重新设计你的代码,但是这也是golang的设计初衷

质量和效率总归互斥的,你需要在两者之间做出平衡

复制代码
相关推荐
等什么君!28 分钟前
springmvc-拦截器
后端·spring
brzhang1 小时前
代码即图表:dbdiagram.io让数据库建模变得简单高效
前端·后端·架构
Jamesvalley1 小时前
【Django】新增字段后兼容旧接口 This field is required
后端·python·django
秋野酱1 小时前
基于 Spring Boot 的银行柜台管理系统设计与实现(源码+文档+部署讲解)
java·spring boot·后端
獨枭2 小时前
Spring Boot 连接 Microsoft SQL Server 实现登录验证
spring boot·后端·microsoft
shanzhizi2 小时前
springboot入门-controller层
java·spring boot·后端
电商api接口开发3 小时前
ASP.NET MVC 入门指南三
后端·asp.net·mvc
声声codeGrandMaster3 小时前
django之账号管理功能
数据库·后端·python·django
我的golang之路果然有问题3 小时前
案例速成GO+redis 个人笔记
经验分享·redis·笔记·后端·学习·golang·go
嘻嘻嘻嘻嘻嘻ys3 小时前
《Vue 3.3响应式革新与TypeScript高效开发实战指南》
前端·后端