Question

我正在探索是否可以同时使用不带锁的固定键访问地图以提高性能的问题。我之前曾经研究过slice的相似之处，并且似乎可以奏效：

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例程正在访问地图的不同键，为什么它会在竞速测试中失败？

Answer 1

在不通过多个goroutine进行同步的情况下访问不同切片元素是可以的，因为每个切片元素都充当一个单独的变量。有关详细信息，请参见Can I concurrently write different slice elements。

但是，地图并非如此。特定键的值不能用作变量，并且不能寻址（因为该值的实际存储空间可能会在内部更改-由实现方式自行决定）。

因此，对于映射，适用一般规则：如果从多个goroutine（其中至少一个是写操作）（将值分配给键）访问映射，则需要显式同步。

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

1 个答案: