Golang 映射对于并发读/写操作的安全性如何？

一身祖宗味儿

任何人都能详细解释这一点吗？似乎允许跨例程并发读取操作，但如果尝试读写同一键，并发读/写操作可能会产生竞争条件。
. V1 c: P2 U/ ^; y. S5 h在某些情况下，最终的风险能降低吗？
函数A生成k并设置m[k]=0。这是 A 写入映射 m唯一一次 。k 不在 m 中。
A 将 k 传递给同时运行的函数 B
A 然后读 m[k]。如果 m[k]==等待，只当 m[k]!=0 时继续
' }: F+ i4 R; n6 vB 在地图上寻找 k。如果找到，B 将 m[k] 设置为正整数。如果没有，它会等到 k 在 m 中。即使 A 和 B 都尝试访问 m 没有竞争条件，或者有竞争条件也没关系，因为额外的限制。
/ z( Q4 Q, t& ^* r) V                                                               
    解决方案:                                                               
9 x; \# C8 `+ c) O5 E( M                                                                Golang 1.6前并发读可以，并发写不可以，写并发读可以。Golang 1.6 开始，map 写入时不能读取。Golang 1.6 之后，并发访问映射应该是这样的:

package mainimport  "sync"    "time")var m = map[string]int{"a": 1}var lock = sync.RWMutex{}func main()      go Read()    time.Sleep(1 * time.Second)    go Write()    time.Sleep(1 * time.Minute)}func Read()      for              read()    }}func Write()      for              write()    }}func read()      lock.RLock()    defer lock.RUnlock()    _ = m["a"]}func write()      lock.Lock()    defer lock.Unlock()    m["b"] = 2}
) b  a! F8 J! R, L* v

或者你会犯以下错误:

添加：
通过使用测试种族 go run -race race.go
更改read功能：

func read(){     / / lock.RLock()    // defer lock.RUnlock()    _ = m["a"]}
9 b% D0 }7 q6 M+ d+ ~3 @) ?

. ?9 S( P% I; E. G. K另一种选择：
) W2 e2 ]2 u% @众所周知，map由桶实现，sync.RWMutex所有的桶都会锁定。concurrent-map用于fnv32对键分片，每个存储桶使用一个sync.RWMutex.