我正在探索使用固定密钥同时访问地图的可能性,而没有锁定以提高性能。我以前用切片探索过类似的东西,似乎有效:
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正在访问地图的不同键,为什么它会通过比赛测试失败?
在没有来自多个goroutine的同步的情况下访问不同的切片元素是可以的,因为每个切片元素充当单个变量。有关详细信息,请参阅Can I concurrently write different slice elements。
但是,地图不是这种情况。特定键的值不作为变量,并且它不可寻址(因为存储的值的实际存储空间可以在内部更改 - 由实现自行决定)。
因此,对于地图,一般规则适用:如果从多个goroutine访问地图,其中至少有一个是写入(为键指定值),则需要显式同步。