golang 中的双重检查锁定 - 为什么需要 mutex.RLock()？

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《golang 中的双重检查锁定 - 为什么需要 mutex.RLock()？》，文章讲解的知识点主要包括，如果你对Golang方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

我有来自该网站的一段代码，它对对象的初始化进行了双重检查锁定。

func checksyncproducer() {
    mutex.rlock()
    if syncproducer == nil {
        mutex.runlock()
        mutex.lock()
        defer mutex.unlock()
        if syncproducer == nil {
            syncproducer  = createsynckafkaproducer() //this func will initialize syncproducer.
        }
    } else {
        defer mutex.runlock()
    }
}

这段代码在第一次 nil 检查之前有 mutex.rlock() 。

为什么需要这样做？ （页面中有解释，但我无法理解）并且它不会增加开销，因为每次调用 checksyncproducer 时都会获取并释放读锁。

在获取读锁之前是否应该再进行一次 nil 检查，例如：

func checkSyncProducer() {
    if syncProducer == nil {
        mutex.RLock()
        if syncProducer == nil {
            mutex.RUnlock()
            mutex.Lock()
            defer mutex.Unlock()
            if syncProducer == nil {
                createSyncKafkaProducer()
            }
        } else {
            defer mutex.RUnlock()
        }
    }
}

第一个 nil 检查将确保不会不必要地使用 rlock。我对么？

解决方案

如果您没有获取 rlock 来读取 syncproducer，则会发生数据竞争，因为另一个 goroutine 可能会更新它。

如果您假设对指针变量的读/写是原子的，那么这看起来无害—— syncproducer 的快速读取永远不会导致不正确的行为。如果你不做这个原子假设，那么如果你不幸运的话，读取可能只会产生指针的一些字节，并且你的程序将会崩溃。

这可能会也可能不会，具体取决于您所使用的体系结构、机器字大小、编译器版本等。但 rlock 避免了任何担忧。

与其显式地使用 rwlocks，最好使用它（假设目标是延迟初始化变量）：

var (
    syncOnce sync.Once
    syncProducerInternal *syncProducerType
)

func syncProducer() *syncProducerType {
    syncOnce.Do(func() { syncProducerInternal = createSyncKafkaProducer() })
    return syncProducerInternal
}

然后需要同步生产者的代码可以调用 syncproducer() 函数来获取它，并且永远不会看到 nil 指针。

这是必需的，因为检查是只读操作。改为进行 rw 锁是可能的，但这意味着一次只有一个 goroutine 可以进行检查。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~