Go 中使用原子操作的计数器和使用互斥锁的计数器有区别吗？

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《Go 中使用原子操作的计数器和使用互斥锁的计数器有区别吗？》，这篇文章主要讲到golang等等知识，如果你对Golang相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

问题内容

我最近看到了一些关于使用原子增量/加载实现的计数器与使用互斥锁来同步增量/加载的计数器之间是否存在差异的讨论。

以下计数器实现在功能上是否等效？

type Counter interface {
    Inc()
    Load() int64
}

// Atomic Implementation

type AtomicCounter struct {
    counter int64
}

func (c *AtomicCounter) Inc() {
    atomic.AddInt64(&c.counter, 1)
}

func (c *AtomicCounter) Load() int64 {
    return atomic.LoadInt64(&c.counter)
}

// Mutex Implementation

type MutexCounter struct {
    counter int64
    lock    sync.Mutex
}

func (c *MutexCounter) Inc() {
    c.lock.Lock()
    defer c.lock.Unlock()

    c.counter++
}

func (c *MutexCounter) Load() int64 {
    c.lock.Lock()
    defer c.lock.Unlock()

    return c.counter
}

我已经运行了一堆测试用例（Playground Link）并且无法看到任何不同的行为。PrintAll在我的机器上运行测试，所有测试功能的数字都乱序打印。

有人可以确认它们是否等效，或者是否存在任何不同的边缘情况？是否偏好使用一种技术而不是另一种技术？原子文档确实说它应该只在特殊情况下使用。

更新： 让我问这个问题的最初问题是这个，但是现在被搁置了，我觉得这方面值得自己讨论。在答案中，似乎使用互斥锁可以保证正确的结果，而原子可能不能，特别是如果程序在多个线程中运行。我的问题是：

• ~~他们可以产生不同的结果是否正确？~~ （见下面的更新。答案是肯定的。）。
• 是什么导致了这种行为？
• 两种方法之间的权衡是什么？

另一个更新：

我发现了一些代码，其中两个计数器的行为不同。在我的机器上运行时，此功能将以 结束MutexCounter，但不会以AtomicCounter. 不要问我为什么你会运行这段代码：

func TestCounter(counter Counter) {
    end := make(chan interface{})

    for i := 0; i = 0 {
                    counter.Inc()
                }
            }
        }()
    }

    go func() {
        prevValue := int64(0)
        for counter.Load() != 10000000 { // Sometimes this condition is never met with AtomicCounter.
            val := counter.Load()
            if val%1000000 == 0 && val != prevValue {
                prevValue = val
            }
        }

        end 

    正确答案

好吧，我将尝试自我回答一些关闭。欢迎编辑。
[这里](https://groups.google.com/forum/#!topic/golang-
nuts/0uPDCRiBWqc)有一些关于原子包的讨论。但引用最有说服力的评论：

非常简短的总结是，如果你不得不问，你可能应该避免使用这个包。或者，阅读 C++11 标准的原子操作章节；如果您了解如何在 C++
中安全地使用这些操作，那么您就完全能够使用 Go 的sync/atomic 包。
也就是说，只要你只是报告统计信息，而不是真正依赖对不同 goroutine
的状态有任何意义的值，坚持atomic.AddInt32下去atomic.LoadInt32是安全的。

和：

原子性不能保证的是值的可观察性的任何顺序。我的意思是，atomic.AddInt32()只保证这个操作在 &cnt
中存储的内容是准确的（当操作开始时，执行活动的 goroutine 的 CPU 从内存中获取*cnt + 1的值就是这个值）；*cnt它不提供任何保证，如果另一个 goroutine 将尝试同时读取此值，它将获取相同的值*cnt + 1。
另一方面，互斥锁和通道保证了对共享/传递值的访问的严格排序（受 Go 内存模型规则的约束）。

关于为什么问题中的代码示例永远不会完成，这是因为func读取计数器的循环非常紧密。使用原子计数器时，没有同步事件（例如mutex锁定/解锁、系统调用），这意味着
goroutine 永远不会产生控制权。这样做的结果是，这个 goroutine 使正在运行的线程饿死，并阻止调度程序将时间分配给分配给该线程的任何其他
goroutine，这包括增加计数器的值，这意味着计数器永远不会达到 10000000。
以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。