sync.RWMutex 仅在读多写少（写
用 sync.RWMutex 替代 sync.Mutex 前先确认读写比例
读多写少是 sync.RWMutex 发挥优势的前提。如果写操作占比超过 15%～20%，它反而可能比 sync.Mutex 更慢——因为读锁的升级/降级开销、goroutine 唤醒调度成本会上升。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
pprof的mutexprofile（go tool pprof http://localhost:6060/debug/pprof/mutex）看锁等待总时长和争用次数，再结合日志统计读写频次 - 对高频读场景（如配置缓存、状态快照），优先用
RWMutex；但若写操作常伴随批量更新或条件重置（比如定时刷新 token map），sync.Map或分片锁更稳妥 -
RWMutex的RLock不可嵌套，且不能在持有RLock时调用Lock（会死锁），必须显式RUnlock后再Lock
避免在锁内做 IO、网络调用或长耗时计算
这是锁竞争恶化最常见原因：一个 goroutine 持有锁执行 HTTP 请求或 JSON 解析，其他 goroutine 全部排队阻塞。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 把锁范围缩到最小——只包裹真正需要保护的共享数据读写，IO 和计算提到锁外
- 例如：从数据库查数据 → 解析成 struct → 加锁写入全局
map，而不是加锁后才发起查询 - 若必须在临界区内触发异步动作（如发通知），改用 channel 或 worker pool 转移出去，锁内只做
select发送信号
用分片锁（sharded mutex）降低单点争用
当热点数据是大容量 map 或 slice，且 key 可哈希时，用分片锁能将锁竞争分散到多个 sync.Mutex 实例上，吞吐量常提升 3–10 倍。
实操示例（简易分片 map）：
type ShardedMap struct {
mu [32]*sync.Mutex
data [32]map[string]int
}
func (m *ShardedMap) Get(key string) int {
idx := int(uint32(hash(key)) % 32)
m.mu[idx].Lock()
defer m.mu[idx].Unlock()
return m.data[idx][key]
}
注意点：
- 分片数不宜过小（易热点）或过大（内存/CPU 开销上升），32 或 64 是较安全起点
- hash 函数要均匀，避免某些 shard 长期空闲、某些持续争抢；
fnv或xxhash比string直接取模更稳 - 无法支持跨分片原子操作（如“所有 key 的 sum”），这类需求得退回到全局锁或用
sync.Map+ 迭代器
sync.Map 不是万能替代，它只适合特定读写模式
sync.Map 对“一次写、多次读”的场景做了优化（读走无锁 fast path），但写操作代价高、不支持遍历、无 CAS 原语，且 key 类型必须是可比较的（不能是 slice/map/func）。
适用边界很明确：
- ✅ 适合：
map[string]*User类型的注册表，用户上线写一次、后续大量读取 - ❌ 不适合：频繁更新同一 key（如计数器自增）、需要按顺序遍历、或 key 是
[]byte等不可比较类型 - ⚠️ 注意：
sync.Map.LoadOrStore在 key 不存在时才写，看似原子，但内部仍可能触发内存分配和锁，高并发下不如预分配 + 分片锁稳定
