高并发时 map 崩了？我研究了 GMP 调度后找到了解决方案
前言
上个月线上出问题了：某个服务一到高峰期，延迟就飙升，偶尔还会出现 data race。
查了很久，最后发现问题出在 map 上：多个 goroutine 并发读写同一个 map，虽然加了锁，但锁的粒度太大了，而且刚好赶上 map 扩容。
今天就从 GMP 角度聊聊 map 的坑。
一、底层原理
1.1 map 怎么扩容，和 GMP 有什么关系？
map 底层是个哈希表，数据多了就会扩容。扩容时会做两件事：
- 分配新的更大的内存
- 把旧数据重新哈希到新位置
graph TD A["Goroutine 1"] --> B["写 map"] C["Goroutine 2"] --> D["写 map"] B --> E["触发扩容"] E --> F["stop the world"] F --> G["所有 G 等待"] G --> H["P 利用率骤降"]关键点：
- 扩容时 map 内部会加全局锁
- 旧数据搬迁需要时间
- 这期间所有访问 map 的 goroutine 都会卡住
- 从 GMP 看，就是 P 的本地队列积压，调度延迟飙升
1.2 map 相关痛点对比
| 问题 | 影响 | 严重程度 |
|---|---|---|
| 并发读写不加锁 | data race，panic | 🔴 致命 |
| 全局锁 | 性能瓶颈 | 🟠 高 |
| 扩容 | 短暂卡顿 | 🟠 高 |
| 哈希冲突 | 性能下降 | 🟡 中 |
二、快速上手
先看反面教材：
package main import ( "fmt" "sync" "time" ) func main() { m := make(map[int]int) var mu sync.Mutex for i := 0; i < 100; i++ { go func() { for j := 0; j < 10000; j++ { mu.Lock() m[j] = j mu.Unlock() } }() } time.Sleep(2 * time.Second) fmt.Println("Done") }这代码虽然不会 panic，但锁的粒度是整个 map，高并发时性能很差。
再看改进版：
// 用 sync.Map func main() { var m sync.Map for i := 0; i < 100; i++ { go func() { for j := 0; j < 10000; j++ { m.Store(j, j) } }() } time.Sleep(2 * time.Second) fmt.Println("Done") }sync.Map 内部做了优化，读多写少时性能很好。
三、核心 API / 深水区
3.1 map 避坑速查
| 场景 | 推荐方案 | 注意事项 |
|---|---|---|
| 单 goroutine | 普通 map | 不用锁 |
| 读多写少 | sync.Map | 不要频繁 Store |
| 读写均衡 | 分片锁 | 实现复杂一点 |
| 写多读少 | 分片锁 + 通道 | 更好的隔离 |
3.2 分片锁原理
把 map 分成 N 个小 map，每个小 map 一把锁：
type ShardedMap struct { shards []*shard } type shard struct { mu sync.RWMutex m map[int]int }这样扩容时，只影响一个分片，不是整个 map。
3.3 预分配容量，避免扩容
知道大概数据量时，先分配好：
// 好 m := make(map[int]int, 100000) // 不好 m := make(map[int]int)四、实战演练
写个简单的分片 map，对比性能：
package main import ( "fmt" "sync" "time" ) const ShardCount = 32 type Shard struct { mu sync.RWMutex m map[int]int } type ShardedMap struct { shards []*Shard } func NewShardedMap() *ShardedMap { sm := &ShardedMap{ shards: make([]*Shard, ShardCount), } for i := range sm.shards { sm.shards[i] = &Shard{ m: make(map[int]int), } } return sm } func (sm *ShardedMap) getShard(key int) *Shard { return sm.shards[key%ShardCount] } func (sm *ShardedMap) Set(key, val int) { s := sm.getShard(key) s.mu.Lock() s.m[key] = val s.mu.Unlock() } func (sm *ShardedMap) Get(key int) (int, bool) { s := sm.getShard(key) s.mu.RLock() val, ok := s.m[key] s.mu.RUnlock() return val, ok } func main() { sm := NewShardedMap() start := time.Now() var wg sync.WaitGroup for i := 0; i < 100; i++ { wg.Add(1) go func() { defer wg.Done() for j := 0; j < 100000; j++ { sm.Set(j, j) sm.Get(j) } }() } wg.Wait() fmt.Printf("耗时: %v\n", time.Since(start)) }和全局锁版本对比，快很多。
五、避坑指南与最佳实践
💡 **技巧 1：预分配 map 容量make(map[T]U, cap)减少扩容次数。
⚠️ **警告 1：永远不要并发读写普通 map
加了锁也不行？不，加了锁可以，但尽量别这么做，用 sync.Map 或分片。
✅ **推荐：读多写少用 sync.Map，读写均衡用分片锁。
六、综合实战演示
完整的高性能 map 方案：
package main import ( "fmt" "sync" "sync/atomic" "time" ) type Cache struct { sm *ShardedMap hits int64 misses int64 } func NewCache() *Cache { return &Cache{ sm: NewShardedMap(), } } func (c *Cache) Get(key int) (int, bool) { val, ok := c.sm.Get(key) if ok { atomic.AddInt64(&c.hits, 1) } else { atomic.AddInt64(&c.misses, 1) } return val, ok } func (c *Cache) Set(key, val int) { c.sm.Set(key, val) } func (c *Cache) Stats() (hits, misses int64) { return atomic.LoadInt64(&c.hits), atomic.LoadInt64(&c.misses) } func main() { cache := NewCache() var wg sync.WaitGroup for i := 0; i < 50; i++ { wg.Add(1) go func() { defer wg.Done() for j := 0; j < 100000; j++ { cache.Set(j, j) } }() } for i := 0; i < 50; i++ { wg.Add(1) go func() { defer wg.Done() for j := 0; j < 100000; j++ { cache.Get(j) } }() } wg.Wait() hits, misses := cache.Stats() fmt.Printf("Hits: %d, Misses: %d\n", hits, misses) }七、总结
map 是好东西，但高并发场景要小心：
- 预分配容量，减少扩容
- 不要裸用，加保护
- sync.Map 适合读多写少
- 读写均衡考虑分片锁
从 GMP 角度看，就是要减少锁粒度，减少让 P 等待的时间，系统才跑得起来。
