为什么 len() 在并发环境下不是线程安全的，尽管 slice 和 map 的 len() 都是 O(1)？

本篇文章给大家分享《为什么 len() 在并发环境下不是线程安全的，尽管 slice 和 map 的 len() 都是 O(1)？》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

我读了一些帖子（Go 中的 len(string) 和 len(slice)s O(1) 操作吗？，如何检查 Golang 中的映射是否为空？），发现 len() 用于切片和映射是 O(1)，实现是获取结构体的成员（例如大小、长度）。 但是测试（Is len() thread safe in golang?）显示len()不是线程安全的，为什么？

正确答案

您所指的称为 benign data race。map size 只是一个 int，因此可以假设读取和写入单个 int 是原子的，对吗？嗯，不。

Go memory model 源自 C memory model，其中从两个或多个线程访问同一内存（其中至少一个线程正在写入）而没有同步，这是一种数据竞争 - undefined behavior 的一种形式。如果您'重新访问单个 int 或更复杂的结构。

良性数据争用实际上不存在的原因有两个：

1。硬件。cpu 缓存架构有两种类型：一种具有强缓存一致性（例如 x86），另一种具有弱缓存一致性（例如 arm）。对内存的定期写入可能不会立即在其他内核上变得“可见”，具体取决于硬件。需要特殊的“原子”指令才能使数据在内核之间可见。

2。软件。根据内存模型，假定每个线程独立执行（直到发生具有先发生语义的同步事件）。编译器可以假设读取相同的内存位置将提供相同的结果，例如，提升循环的这些读取（从而破坏程序）。这就是为什么同步必须在代码中是显式的，即使针对具有强缓存一致性的硬件也是如此。

以下程序可能会也可能不会完成，具体取决于 cpu 和编译器优化标志：

func main() {
    x := 0
    go func() {
        x = 1
    }()
    for x == 0 {  // data race! also, the compiler is allowed to simplify "x == 0" to "true" here
        // wait ...
    }
}

为了使其正确，请使用同步让编译器知道涉及并发：

func main() {
    var mtx sync.Mutex
    x := 0
    go func() {
        mtx.Lock()
        x = 1 // protect writes by a mutex
        mtx.Unlock()
    }()
    for {
        mtx.Lock()
        x_copy := x // yes, also reads must be protected
        mtx.Unlock()
        if x_copy != 0 {
            break
        }
        // wait ...
    }
}

同一互斥锁的锁定和解锁会创建一个获取释放栅栏，以便在解锁互斥锁之前完成的所有内存写入都被“释放”，并对随后锁定互斥锁的线程可见，并且“获取”它们。

今天关于《为什么 len() 在并发环境下不是线程安全的，尽管 slice 和 map 的 len() 都是 O(1)？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！