sync.Mutex的作用和原因是什么？

大家好，今天本人给大家带来文章《sync.Mutex的作用和原因是什么？》，文中内容主要涉及到，如果你对Golang方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

为什么我们有 sync.RWMutex 时却存在 sync.Mutex？我可以锁定/解锁读写互斥体。它们之间的主要区别是什么？

解决方案

确实，当您需要 sync.Mutex 时，您可以使用 sync.RWMutex。

我认为两者都存在，因为在很多情况下 sync.mutex 就足够了（不需要读写级别锁定），并且 sync.mutex 的实现更简单：需要更少的内存，并且很可能更快。

sync.mutex 只有 8 个字节：

type mutex struct {
    state int32
    sema  uint32
}

虽然 sync.rwmutex 是 8 + 16 = 24 字节（它包括 sync.mutex）：

type rwmutex struct {
    w           mutex  // held if there are pending writers
    writersem   uint32 // semaphore for writers to wait for completing readers
    readersem   uint32 // semaphore for readers to wait for completing writers
    readercount int32  // number of pending readers
    readerwait  int32  // number of departing readers
}

是的，您可以说 8 或 24 字节并不重要。只要你只有几个互斥锁就不会这样。

但是将互斥锁放入它应该保护的结构中（嵌入或常规的命名字段）并不罕见。现在，如果您有这些结构值的一部分，甚至可能是数千个，那么是的，它将产生显着的差异。

此外，如果您只需要一个互斥锁，sync.mutex 可以减少误用它的机会（您不会意外调用 rlock()，因为它没有该方法）。

正如 @icza 提到的，除了占用更多空间之外，它在执行时间方面也效率较低。

如果我们看一下rwmutex.lock的源代码：

// Lock locks rw for writing.
// If the lock is already locked for reading or writing,
// Lock blocks until the lock is available.
func (rw *RWMutex) Lock() {
    if race.Enabled {
        _ = rw.w.state
        race.Disable()
    }
    // First, resolve competition with other writers.
    rw.w.Lock()
    // Announce to readers there is a pending writer.
    r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
    // Wait for active readers.
    if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
        runtime_SemacquireMutex(&rw.writerSem, false)
    }
    if race.Enabled {
        race.Enable()
        race.Acquire(unsafe.Pointer(&rw.readerSem))
        race.Acquire(unsafe.Pointer(&rw.writerSem))
    }
}

我们可以看到它调用了 mutex.lock，因此它花费了 mutex.lock 以及它执行的所有其他操作的相同时间。

我们看到调用了race对象的atomic.addint32、runtime_semacquiremutex等方法，这会有一个开销。

以上就是《sync.Mutex的作用和原因是什么？》的详细内容，更多关于的资料请关注golang学习网公众号！