rwmutex并非读多写少场景的自动加速器，仅在读操作耗时长、并发读goroutine多、写极少时有优势；读若为微秒级操作或含i/o，则易导致写饥饿，应优先用atomic或分片锁。
RWMutex不是读多写少场景的自动加速器，它只在读操作耗时长、并发读goroutine多、写极少（
RLock()和RUnlock()必须严格成对，且不能跨函数或panic路径漏掉
漏掉RUnlock()是最常见的死锁源头。一旦发生，后续所有Lock()和新RLock()都会永久阻塞——因为readerCount始终不归零。
- 错误写法：
mu.RLock()后直接调用可能panic的函数，再defer mu.RUnlock()→ panic时defer不执行 - 正确姿势：显式配对，或用作用域封装（如
func() { mu.RLock(); defer mu.RUnlock(); ... }()） - 尤其注意error分支：读不到key后立刻
mu.RUnlock()，再拿mu.Lock()写入，中间不能跳过释放
写操作占比超过10%时，RWMutex反而拖慢性能
写频繁会触发锁升级开销，且readerCount原子操作在多核上引发Cache Bouncing——几十个goroutine同时RLock()，都在争抢同一缓存行。
- 压测信号：
pprof -mutexprofile显示大量goroutine卡在runtime.semasleep或sync.runtime_SemacquireRWMutexR - 写占比 >10% 时，
sync.Mutex往往更轻量；写占比 >30%，应考虑分片锁或sync.Map - 别信“读多就一定赢”——如果读只是
atomic.LoadInt64()这种微秒级操作，RWMutex纯属加戏
读操作里含HTTP/DB/大循环 = 自找写饥饿
RWMutex不解决IO阻塞问题。读锁持有期间做网络请求，等于把所有等待的写goroutine钉在writerSem上，直到IO结束。
- 典型现象：日志反复出现“waiting for readers…”，CPU不高，但写延迟飙升到秒级
- 根本原因：高频短读（如每毫秒一次健康检查）持续刷新
readerCount，导致排队的Lock()永远等不到readerCount == 0 - 缓解手段有限：写逻辑必须轻量（无I/O、无大循环）；读逻辑重就提前复制数据；极低频写可换
atomic.Value+ 不可变结构体
单值读写优先用atomic，别凑热闹上RWMutex
保护一个int64计数器、bool开关或*Config指针？atomic.LoadInt64()、atomic.StorePointer()零开销、无锁、不抢缓存行。
-
atomic不支持结构体整体读写，但atomic.Value可安全存取任意类型指针（需配合不可变语义） - 复合操作（如“读A→算B→写C”）无法靠
atomic保证原子性，此时才轮到RWMutex出场 - 别把整个配置结构体用一把
RWMutex包住——只锁真正需要同步的字段，拆粒度比换锁更有效
真正难的不是选RWMutex还是atomic，而是确认你的“读”到底耗不耗时、有多少goroutine在争同一个readerCount地址——这些得看go tool trace和pprof，不是凭经验猜。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
