为何在进行首次存储后无法复制atomic.Value？

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《为何在进行首次存储后无法复制atomic.Value？》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

Value 提供一致类型值的原子加载和存储。 Value 的零值从 Load 返回 nil。一旦 Store 被调用，Value 就不能被复制。

我从atomic.Value 读到了上述评论。 它说“值不能被复制”，但没有说明原因。

为什么atomic.Value不能在第一个Store之后复制？

正确答案

除了@Volker的回答和@icza的评论之外，推理非常简单：atomic.Value的实现包括一些东西，它用于提供类型保证的原子性直接合同——而不是包含对此类事物的引用或指针，因此当 atomic.Value 类型的变量被复制到“事物”被复制的另一个变量时， （克隆）也是如此。

现在假设一个实现决定在 atomic.Value 类型中包含一个（通常是内核提供的）semaphore 或 mutex 或 critical section 或其他任何方便的锁定机制。

现在考虑一种争用情况：一些 goroutine 尝试读取该值，而另一个 goroutine 尝试并行修改它。 写入 goroutine 通过该内部保护机制“获取”“独占写入权限”（无论它是如何实现的），然后复制该值。 撇开这种复制创建经典数据竞争案例的问题不谈，您现在可以看到复制的结果将是两个 atomic.Value 类型的变量，并且每个变量都将被“锁定”以获得独占写入权限。 但是，虽然原始变量仍处于合理状态 - 想要更新变量的 Goroutine 最终将完成此操作，并将“释放”其许可，将变量返回到正常状态，但副本将永远锁定在该状态中“已获取更新”状态，而没有 goroutine 打算执行该更新。 糟糕！

顺便说一句，出于完全相同的原因，您无法在第一次使用 sync.Mutex 变量后复制它。

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