在Golang的标准库中，内置的map类型并不具备并发安全特性，当多个goroutine同时对同一个map进行读写操作时，程序会直接抛出panic错误，提示并发map访问冲突。因此在实际的多goroutine并发场景中，使用map前必须考虑并发安全问题，选择合适的方案避免冲突。
为什么Golang内置map不支持并发
Golang的设计者为了保持map的简洁性和基础场景下的高性能，没有为map内置并发控制逻辑。map的内部结构包含哈希表、桶数组等复杂结构，若内置并发控制会增加额外的性能开销，不符合Golang追求简洁高效的设计理念。所以当需要在并发场景使用map时，开发者需要自行实现并发控制。
常见的Golang map并发安全方案
1. 使用sync.Mutex互斥锁
互斥锁是最基础的并发控制方式，通过对map的所有读写操作加锁，保证同一时间只有一个goroutine可以操作map，从而避免并发冲突。这种方案适合读写频率接近的场景。
package main
import (
"fmt"
"sync"
)
func main() {
var (
m = make(map[string]int)
mu sync.Mutex
wg sync.WaitGroup
)
// 启动10个goroutine并发写map
for i := 0; i < 10; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
mu.Lock()
m[fmt.Sprintf("key_%d", idx)] = idx
mu.Unlock()
}(i)
}
// 启动10个goroutine并发读map
for i := 0; i < 10; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
mu.Lock()
val := m[fmt.Sprintf("key_%d", idx)]
mu.Unlock()
fmt.Printf("key_%d value is %dn", idx, val)
}(i)
}
wg.Wait()
}
2. 使用sync.RWMutex读写锁
如果场景中读操作远多于写操作，使用互斥锁会导致读操作之间也互相阻塞，影响性能。此时可以使用读写锁，读操作加读锁，多个goroutine可以同时获取读锁；写操作加写锁，写锁会阻塞所有读锁和其他写锁，性能会优于互斥锁。
package main
import (
"fmt"
"sync"
)
func main() {
var (
m = make(map[string]int)
mu sync.RWMutex
wg sync.WaitGroup
)
// 先写入初始数据
m["init"] = 100
// 启动20个读goroutine
for i := 0; i < 20; i++ {
wg.Add(1)
go func() {
defer wg.Done()
mu.RLock()
val := m["init"]
mu.RUnlock()
fmt.Println("read value:", val)
}()
}
// 启动2个写goroutine
for i := 0; i < 2; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
mu.Lock()
m["init"] = m["init"] + idx
mu.Unlock()
}(i)
}
wg.Wait()
}
3. 使用sync.Map
Golang在1.9版本之后提供了sync.Map类型，这是官方专门为高并发场景设计的线程安全map，内部做了很多性能优化，适合读多写少或者键值对生命周期较短的场景。它提供了Store、Load、Delete等专用方法，不需要额外加锁。
package main
import (
"fmt"
"sync"
)
func main() {
var (
sm sync.Map
wg sync.WaitGroup
)
// 并发写入
for i := 0; i < 10; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
sm.Store(fmt.Sprintf("key_%d", idx), idx)
}(i)
}
// 并发读取
for i := 0; i < 10; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
val, ok := sm.Load(fmt.Sprintf("key_%d", idx))
if ok {
fmt.Printf("key_%d value is %vn", idx, val)
}
}(i)
}
wg.Wait()
}
4. 分片map方案
如果map的键值对数量非常多，单个锁的竞争激烈会影响性能，可以将map拆分为多个小的分片map，每个分片对应一个独立的锁，根据键的哈希值分配到不同的分片，减少锁的竞争。这种方案适合大规模的并发map场景。
package main
import (
"fmt"
"hash/fnv"
"sync"
)
// 分片map结构
type ShardMap struct {
shards []*shard
count int
}
type shard struct {
mu sync.RWMutex
data map[string]int
}
// 初始化分片map
func NewShardMap(count int) *ShardMap {
sm := &ShardMap{
shards: make([]*shard, count),
count: count,
}
for i := 0; i < count; i++ {
sm.shards[i] = &shard{
data: make(map[string]int),
}
}
return sm
}
// 根据key计算分片索引
func (sm *ShardMap) getShardIndex(key string) int {
h := fnv.New32a()
h.Write([]byte(key))
return int(h.Sum32()) % sm.count
}
// 写操作
func (sm *ShardMap) Store(key string, value int) {
idx := sm.getShardIndex(key)
sh := sm.shards[idx]
sh.mu.Lock()
sh.data[key] = value
sh.mu.Unlock()
}
// 读操作
func (sm *ShardMap) Load(key string) (int, bool) {
idx := sm.getShardIndex(key)
sh := sm.shards[idx]
sh.mu.RLock()
val, ok := sh.data[key]
sh.mu.RUnlock()
return val, ok
}
func main() {
shardMap := NewShardMap(8)
var wg sync.WaitGroup
// 并发写入
for i := 0; i < 20; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
shardMap.Store(fmt.Sprintf("key_%d", idx), idx)
}(i)
}
// 并发读取
for i := 0; i < 20; i++ {
wg.Add(1)
go func(idx int) {
defer wg.Done()
val, ok := shardMap.Load(fmt.Sprintf("key_%d", idx))
if ok {
fmt.Printf("key_%d value is %dn", idx, val)
}
}(i)
}
wg.Wait()
}
各方案适用场景对比
不同方案的适用场景和性能表现存在差异，开发者可以根据实际需求选择：
| 方案 | 适用场景 | 性能特点 |
|---|---|---|
| sync.Mutex互斥锁 | 读写频率接近的普通并发场景 | 实现简单，读写都会阻塞，性能一般 |
| sync.RWMutex读写锁 | 读多写少的并发场景 | 读操作可以并发，性能优于互斥锁 |
| sync.Map | 读多写少、键值对生命周期短、高并发场景 | 官方优化实现，性能较好，接口较特殊 |
| 分片map | 大规模键值对、高并发竞争场景 | 减少锁竞争，性能最优，实现较复杂 |
注意事项
- 不要对同一个map同时做无锁的并发读写，一定会触发panic
- sync.Map的键和值都是any类型，使用时需要注意类型断言的正确性
- 分片map的分片数量需要根据实际场景调整，过多分片会增加内存开销，过少则达不到减少竞争的效果
- 如果map的键值对数量很少，且并发量不高，使用互斥锁或读写锁即可，不需要过度设计使用复杂方案