Golang 中的 map 为什么是并发不安全的？

一、并发不安全的

golang 中的 map 是并发不安全的，多个 go 协程同时对同一个 map 进行读写操作时，会导致数据竞争（data race）问题，程序会 panic。

如果一个协程正在写入 map，而另一个协程正在读取或写入 map，那么就有可能出现一些未定义的行为，例如：读取到的值可能是过期的、不正确的或 nil；写入的值可能被覆盖、丢失或者多次计数。

go 官方认为，map 更应适配典型使用场景（不需要从多个 goroutine 中进行安全访问），而不是为了小部分情况（并发访问），导致大部分程序付出加锁的代价，影响性能，所以决定了不支持。

二、并发场景

多个协程同时读和写，以下程序会出现致命错误：fatal error: concurrent map writes

func main() {
	s := make(map[int]int)
	for i := 0; i < 100; i++ {
		go func(i int) {
			s[i] = i
		}(i)

	}
	for i := 0; i < 100; i++ {
		go func(i int) {
			fmt.Printf("map 的第%d个元素是%d\n", i, s[i])
		}(i)
	}
	time.Sleep(1 * time.Second)
}

三、实现 map 并发安全

如果想实现 map 并发安全，有2种方式：

方式一：使用读写互斥锁 map + sync.RWMutex

读不用加锁；写之前调用 Lock() 函数加锁，写完之后，调用 Unlock() 解锁。

func main() {
	// 读写互斥锁
	var lock sync.RWMutex
	s := make(map[int]int)
	for i := 0; i < 100; i++ {
		go func(i int) {
			lock.Lock() // 加写锁
			s[i] = i
			lock.Unlock() // 解写锁
		}(i)

	}
	for i := 0; i < 100; i++ {
		go func(i int) {
			fmt.Printf("map 的第%d个元素是%d\n", i, s[i])
		}(i)
	}
	time.Sleep(1 * time.Second)
}

正常打印，没有 panic。

方式二：使用 go 提供的 sync.Map

使用 Store() 函数赋值，使用 Load() 函数获取值。

func testMap2() {
	var s sync.Map
	for i := 0; i < 100; i++ {
		go func(i int) {
			s.Store(i, i)
		}(i)
	}
	for i := 0; i < 100; i++ {
		go func(i int) {
			v, _ := s.Load(i)
			fmt.Printf("map 的第%d个元素是%d\n", i, v)
		}(i)
	}
	time.Sleep(1 * time.Second)
}

正常打印，没有 panic。

两种方式的比较

sync.Map 支持并发读写，采用空间换时间的机制，冗余了两个数据结构，分别是: read 和 dirty。

type Map struct {
	mu Mutex
	read atomic.Value
	dirty map[any]*entry
	misses int
}

和 map+ RWLock 的实现并发的方式相比，减少了加锁对性能的影响，它做了一些优化：可以无锁访向read map，而且会优先操作read mp，如果只操作 read map 就可以满足要求，那就不用去操作write map(dirty)，所以在某些特定场景中它发生锁竞争的频率会远远小于 map+RWLock 的实现方式。

sync.map 的实现方式是通过分段锁（shard-locking）来保证并发安全性，每个分段锁只控制一部分数据，从而减少锁的竞争。虽然 sync.map 比普通的 map 更安全，但是需要注意的是，在读取和写入操作之间仍然存在风险，因此要谨慎使用。

优点:

适合读多写少的场景。

缺点:

写多的场景，会导致 read map 缓存失效，需要加锁，冲突变多，性能急剧下降。