在Golang开发中，缓存是提升接口响应速度、降低数据库压力的常用手段。但当多个goroutine同时对缓存进行读写时，若未做同步控制，就会引发数据竞争甚至程序崩溃。要实现并发安全的缓存，需要理解Go运行时对map的约束，并选择合适的同步机制。
一、为什么普通map不是并发安全的
Go语言内置的map类型在设计与实现上并未包含内部锁。在源码runtime/map.go中，对并发写操作有显式检查，一旦检测到多个goroutine同时写入，会主动抛出并发写错误并终止进程。这是因为map在扩容、桶迁移等过程中，结构处于不一致状态，并发访问可能导致指针错乱。
很多初学者在写本地缓存时，直接用map[string]interface{}存储数据，并在HTTP handler中并发读写。这种写法在单元测试的低并发下可能正常运行，但在压测或线上流量波动时就会偶发崩溃。因此，任何可能被多个goroutine接触的map，都必须通过外部同步手段保护。
二、基于sync.RWMutex的缓存设计
最常用的方案是用读写锁sync.RWMutex包裹普通map。读操作使用RLock，允许多个goroutine同时读取；写操作使用Lock，保证同一时间只有一个goroutine修改。这种方式逻辑直观，且能在锁内实现过期判断、统计计数等复杂逻辑。
下面给出一个支持过期时间的并发安全缓存实现。我们将缓存值封装为带有过期时间戳的结构体，在获取时判断是否失效：
package cache
import (
"sync"
"time"
)
type item struct {
value interface{}
expireAt int64
}
type SafeCache struct {
mu sync.RWMutex
data map[string]item
}
func NewSafeCache() *SafeCache {
return &SafeCache{
data: make(map[string]item),
}
}
func (c *SafeCache) Set(key string, value interface{}, ttl time.Duration) {
c.mu.Lock()
defer c.mu.Unlock()
c.data[key] = item{
value: value,
expireAt: time.Now().Add(ttl).UnixNano(),
}
}
func (c *SafeCache) Get(key string) (interface{}, bool) {
c.mu.RLock()
it, ok := c.data[key]
c.mu.RUnlock()
if !ok {
return nil, false
}
if it.expireAt < time.Now().UnixNano() {
return nil, false
}
return it.value, true
}
func (c *SafeCache) Delete(key string) {
c.mu.Lock()
defer c.mu.Unlock()
delete(c.data, key)
}
上述代码中，Set和Delete使用写锁，Get使用读锁，性能在读写均衡场景下表现良好。但要注意，如果某个value是切片或map，获取后外部修改仍可能影响其他协程，因此建议在存入时拷贝，或约定缓存值为不可变类型。
为了避免过期数据长期占用内存，可以启动一个后台goroutine定时清理。由于清理需要写锁，建议间隔不宜过短，例如每5秒扫描一次，将过期key批量删除，从而减少锁持有次数。
三、使用sync.Map的轻量方案
Go在标准库提供了sync.Map，它内部采用分段、只读副本等技巧，适合读多写少且key集合相对稳定的场景。与RWMutex方案不同，sync.Map的Load和Store方法自身已是并发安全，无需额外加锁。
下面是用sync.Map实现的简易缓存，过期判断仍在用户层做：
package cache
import (
"sync"
"time"
)
type mapItem struct {
value interface{}
expireAt int64
}
type SyncMapCache struct {
m sync.Map
}
func (c *SyncMapCache) Set(key string, value interface{}, ttl time.Duration) {
c.m.Store(key, mapItem{
value: value,
expireAt: time.Now().Add(ttl).UnixNano(),
})
}
func (c *SyncMapCache) Get(key string) (interface{}, bool) {
v, ok := c.m.Load(key)
if !ok {
return nil, false
}
it := v.(mapItem)
if it.expireAt < time.Now().UnixNano() {
c.m.Delete(key)
return nil, false
}
return it.value, true
}
sync.Map在频繁写入且key不断变化的场景下，可能因内部副本膨胀导致内存和延迟上升。因此它更适合配置缓存、元数据缓存等写少读多的用途。如果业务写入频繁，RWMutex加普通map通常更可控。
另外，sync.Map没有提供长度统计、范围删除等便捷方法，Range遍历时若在其中做Delete，需注意不会阻塞其他操作，但遍历本身可能看到中间状态，设计清理逻辑时要容忍这种不一致。
四、操作方法与最佳实践
在实际项目中，操作并发缓存时应遵循几个原则。第一，明确缓存边界，不要将大对象直接存入本地缓存，以免锁内拷贝或GC压力增大。第二，为缓存设置默认上限，结合RWMutex可实现简单LRU，防止内存无限增长。
第三，对于跨进程共享的数据，本地并发缓存并不能代替Redis等分布式缓存，它只解决单实例内的竞态。第四，在单元测试中应使用-race参数运行，Go的竞态检测器能直接发现未加锁的并发访问，是验证缓存安全性的最低成本手段。
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| RWMutex+map | 读写均衡、逻辑复杂 | 灵活、易扩展 | 锁竞争需调优 |
| sync.Map | 读多写少 | 无显式锁、易用 | 写多时性能差 |
通过上述设计与操作方法，你可以在Golang中构建出稳定、并发安全的本地缓存，支撑高并发服务的热点数据访问需求。