具有固定大小的Golang并发访问映射/数组

Question

我正在探索使用固定密钥同时访问地图的可能性，而没有锁定以提高性能。我以前用切片探索过类似的东西，似乎有效：

func TestConcurrentSlice(t *testing.T) {
    fixed := []int{1, 2, 3}
    wg := &sync.WaitGroup{}
    for i := 0; i < len(fixed); i++ {
        idx := i
        wg.Add(1)
        go func() {
            defer wg.Done()
            fixed[idx]++
        }()
    }
    wg.Wait()
    fmt.Printf("%v\n", fixed)
}

上面的代码将通过-race测试。

这让我有信心用固定大小的地图（固定数量的键）实现同样的事情，因为我假设如果键的数量没有改变，那么下划线数组（在地图中）不需要扩展，所以它我们可以安全地访问不同的例行程序中的不同密钥（不同的内存位置）。所以我写了这个测试：

type simpleStruct struct {
    val int
}

func TestConcurrentAccessMap(t *testing.T) {
    fixed := map[string]*simpleStruct{
        "a": {0},
        "b": {0},
    }
    wg := &sync.WaitGroup{}
    // here I use array instead of iterating the map to avoid read access
    keys := []string{"a", "b"}
    for _, k := range keys {
        kcopy := k
        wg.Add(1)
        go func() {
            defer wg.Done()
            // this failed the race test
            fixed[kcopy] = &simpleStruct{}

            // this actually can pass the race test!
            //fixed[kcopy].val++
        }()
    }
    wg.Wait()
}

但是，测试未通过runtime.mapassign_faststr（）函数的错误消息并发写入的竞争测试失败。

我发现的另一个有趣的是我已注释掉的代码“fixed [kcopy] .val ++”实际上通过了竞赛测试（我认为这是因为这些着作位于不同的内存位置）。但我想知道，因为go-routines正在访问地图的不同键，为什么它会通过比赛测试失败？

Answer 1

在没有来自多个goroutine的同步的情况下访问不同的切片元素是可以的，因为每个切片元素充当单个变量。有关详细信息，请参阅Can I concurrently write different slice elements。

但是，地图不是这种情况。特定键的值不作为变量，并且它不可寻址（因为存储的值的实际存储空间可以在内部更改 - 由实现自行决定）。

因此，对于地图，一般规则适用：如果从多个goroutine访问地图，其中至少有一个是写入（为键指定值），则需要显式同步。