Go 问答：为什么并发读写 map 会 panic，sync.Map 和锁该怎么选

Go 新手经常会遇到一个运行时错误：fatal error: concurrent map read and map write。代码看起来只是多个 goroutine 同时读写一个缓存 map，压测或线上高并发时却突然崩掉。这个问题不是偶发小概率，而是普通 map 的设计边界。

本文用问答方式讲清楚：Go 普通 map 为什么不能并发读写，什么时候用 sync.RWMutex + map，什么时候用 sync.Map，以及热点 Key 和高写入场景该怎么处理。

摘要

Go 内置 map 不是并发安全结构。多个 goroutine 同时读写，或者同时写入，都可能导致运行时 panic。最常见的修复方式是给 map 加锁；读多写少、键稳定、缓存类场景可以考虑 sync.Map；写入频繁或热点明显时，可以考虑分片 map 或单 goroutine 拥有数据。

适合人群

适合正在写 Go Web 服务、缓存、连接管理、配置表、状态表、计数器或任务调度器的开发者。你需要了解 goroutine、map 和基础锁的用法。

目录

1. 问题复现：为什么会 panic
2. 普通 map 为什么不并发安全
3. 方案一：RWMutex 保护 map
4. 方案二：sync.Map 的适用边界
5. 四种方案怎么选
6. 常见误区和排查建议

一、问题复现：为什么会 panic

下面这个例子里，一个 goroutine 持续写入 map，另一个 goroutine 持续读取 map。运行一段时间后，就可能出现运行时错误。

package main

import (
    "fmt"
    "time"
)

func main() {
    cache := make(map[string]int)

    go func() {
        for i := 0; ; i++ {
            cache["count"] = i
        }
    }()

    go func() {
        for {
            fmt.Println(cache["count"])
        }
    }()

    time.Sleep(3 * time.Second)
}

常见输出类似：

fatal error: concurrent map read and map write

注意：即使“只有一个 goroutine 写，多个 goroutine 读”，只要读写并发发生，普通 map 就不安全。

二、普通 map 为什么不并发安全

map 的内部结构会在插入、删除、扩容、搬迁桶数据时变化。读操作如果刚好遇到写操作修改内部结构，可能读到不一致状态。Go 运行时为了避免数据结构被破坏，会检测部分并发读写情况并直接抛出 fatal error。

所以不要把它理解成“偶尔数据不准”，而应该理解成“这个结构没有承诺并发读写安全”。一旦多个 goroutine 共享 map，就必须有明确的同步策略。

三、方案一：RWMutex 保护 map

最通用、最容易维护的方案，是用 sync.RWMutex 包一层。读操作加读锁，写操作加写锁。

package cache

import "sync"

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{
        m: make(map[string]int),
    }
}

func (s *SafeMap) Set(key string, value int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.m[key] = value
}

func (s *SafeMap) Get(key string) (int, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    value, ok := s.m[key]
    return value, ok
}

func (s *SafeMap) Delete(key string) {
    s.mu.Lock()
    defer s.mu.Unlock()
    delete(s.m, key)
}

这种方案适合大多数业务代码：类型清楚、逻辑直观、可控性强。缺点是高并发写入时锁竞争会明显。

四、方案二：sync.Map 的适用边界

sync.Map 是标准库提供的并发安全 map，但它不是“所有场景都更快”。它更适合读多写少、Key 相对稳定、缓存命中率较高的场景。

package main

import "sync"

func main() {
    var cache sync.Map

    cache.Store("user:1", "Tom")

    if value, ok := cache.Load("user:1"); ok {
        _ = value.(string)
    }

    cache.Delete("user:1")
}

sync.Map 的缺点也要记住：它的键和值都是 any，类型需要自己断言；复杂的读改写组合不如锁保护 map 直观；写入特别频繁时不一定更合适。

五、四种方案怎么选

不同场景建议不同：

• 普通业务状态表：优先 RWMutex + map，可读性最好；
• 读多写少缓存：可以考虑 sync.Map；
• 热点 Key 多、并发很高：考虑分片 map，降低单锁竞争；
• 需要严格顺序和状态机：用 channel 把所有操作交给单 goroutine 管理。

type ShardedMap struct {
    shards []struct {
        mu sync.RWMutex
        m  map[string]int
    }
}

func (s *ShardedMap) shard(key string) int {
    return int(fnv32(key)) % len(s.shards)
}

分片 map 的核心是把一个大锁拆成多个小锁。它适合高并发热点较分散的场景，但实现复杂度更高，遍历、统计和批量操作都要额外处理。

六、常见误区和排查建议

1. 只给写操作加锁

读操作也必须和写操作使用同一把锁。否则写入时仍可能和读操作并发，问题不会消失。

2. 持锁期间做耗时操作

不要在锁里调用远程接口、读文件或做重计算。锁里只做 map 读写，把耗时逻辑放到锁外。

3. 误以为 sync.Map 总是更快

sync.Map 是针对特定访问模式优化的工具。写多、类型要求强、需要复合操作时，普通 map 加锁往往更清晰。

4. 忽略竞态检测

本地测试可以加 -race 运行，提前发现数据竞争：

go test -race ./...

七、总结

Go 普通 map 不支持并发读写，这不是使用姿势问题，而是数据结构本身没有提供并发安全保证。实际项目里，默认选 RWMutex + map；读多写少缓存可以试 sync.Map；高并发热点场景再考虑分片；强顺序状态流可以交给单 goroutine。选型的标准不是“哪个高级”，而是访问模式、可维护性和性能瓶颈是否匹配。