用 go test -bench 对比锁吞吐量最直观，重点看单位时间操作次数而非单次耗时；读多场景下 rwmutex 比 mutex 快 2–5 倍，但 map 频繁扩容/删除时 mutex 更稳；务必用 -race 检测竞争，pprof 分析锁等待与饥饿，避免值拷贝导致锁失效。
用 go test -bench 对比锁的吞吐量
直接跑压测是最直观的方式。重点不是看单次加锁耗时，而是看单位时间内能完成多少次读/写操作。比如对一个 map 做 100 万次并发读写，sync.Mutex 和 sync.RWMutex 的 Benchmark 结果通常差 2–5 倍（读多场景下）。
常见错误是只测写操作，或没控制读写比例。真实场景中读写比影响极大——如果读写比是 9:1，RWMutex 优势明显；如果是 1:1，sync.Mutex 可能更稳、开销更低。
- 必须用
-race开关跑一次，确认没有数据竞争（否则 benchmark 结果无意义） - 读操作要统一用
RLock()/RUnlock()，别误写成Lock()，否则RWMutex就退化成互斥锁 - 避免在 benchmark 函数里做 I/O、sleep、fmt 等干扰项，只保留临界区核心逻辑
pprof 查锁等待时间与争用热点
压测时加上 go tool pprof -http=:8080 cpu.prof，重点关注 sync.(*Mutex).Lock 或 sync.(*RWMutex).RLock 的调用栈耗时占比。如果某个锁的阻塞时间占总 CPU 时间 >15%，说明它已成为瓶颈。
特别注意 RWMutex 的写锁饥饿问题：当持续有 goroutine 调用 RLock()，Lock() 可能长期得不到执行。pprof 中会表现为 sync.(*RWMutex).Lock 在调用栈底部堆积，且等待时间逐次拉长。
- 用
runtime.SetMutexProfileFraction(1)提高锁事件采样率（默认是 0，不采集） -
RWMutex的readerCount字段飙升但writerSem长期不释放，就是写锁被饿死的信号 - 不要只看锁本身耗时，还要查它保护的那段代码是否做了不该做的事（比如在临界区内调用 http.Client）
map 并发读写场景下 sync.RWMutex 不一定更快
很多人默认“读多就该用 RWMutex”，但在 map 上容易踩坑：Go 的 map 本身不支持并发读，但它的读操作（如 m[key]）底层可能触发扩容或迭代器检查，这些动作在 RWMutex 的读锁下仍可能和写操作冲突，尤其在 map 大小剧烈变化时。
实测发现，当 map 元素数超过 10 万且写操作频繁插入/删除时，RWMutex 的读锁实际获得延迟反而高于 sync.Mutex，因为其内部需要维护读计数+写等待队列，状态机更重。
- 若 map 写操作只是更新已有 key（不增删），且 key 数量稳定，
RWMutex优势明显 - 若写操作含
delete(m, key)或大量m[key] = val导致扩容，sync.Mutex更可控 - 更彻底的解法是换
sync.Map，但它只适合读远多于写、key 生命周期长的场景，且不支持遍历
锁的零值可用但不可复制，结构体嵌入要小心
sync.Mutex 和 sync.RWMutex 的零值都是有效未锁定状态，所以声明 var mu sync.Mutex 后可直接调用 mu.Lock()。但一旦你把它作为结构体字段，又做了值拷贝（比如函数传参时传 struct 值而非指针），就会触发“copy of unlocked mutex”警告，且导致锁失效。
典型错误是：把带锁的结构体放进 map，然后通过 m[key].Lock() 调用——这实际是对 map 中 struct 的副本加锁，原结构体没变。
- 永远用指针传递含锁结构体：
func (s *MyStruct) Do() { s.mu.Lock() } - 切忌在结构体里嵌入锁后还实现
Copy()方法或用json.Marshal直接序列化整个 struct - 用
go vet检查 “possible misuse of unsafe.Pointer” 或 “copy of unlocked mutex” 类提示
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
