仅在读远多于写的场景（如配置缓存）才用 sync.rwmutex；读写均等或写多时应选 sync.mutex；需避免写饥饿、死锁及锁混用，且写操作耗时长时宜改用无锁快照。
什么时候该用 sync.RWMutex 而不是 sync.Mutex
只在读操作远多于写操作的场景下才值得换——比如配置缓存、状态快照、只读映射表。如果读写频率接近，甚至写更多，RWMutex 反而因额外的计数和信号量开销更慢。
- 读多写少：100 次读 + 1 次写 → 适合
- 读写均等或写主导：50 次读 + 50 次写 → 用
sync.Mutex更稳、更简单 - 写操作耗时长（如调用 HTTP 或 DB）→ 会加剧“写饥饿”，应拆分逻辑或改用无锁快照（如
atomic.Value）
RLock() 和 Lock() 必须严格配对，且不能混用
这是最常导致死锁或 panic 的地方：同一个 goroutine 持有 RLock() 后再调 Lock()，或者反过来，都会立即死锁；重复 RLock() 不报错但不推荐，重复 Unlock() 会 panic。
- ✅ 正确：先
RLock()，只做读，然后RUnlock() - ✅ 正确：先
Lock()，做完写，再Unlock() - ❌ 危险：在
RLock()持有期间调Lock()→ 死锁 - ❌ 错误：用
RUnlock()解Lock()拿的锁 → panic
示例中常见错误写法：defer mu.RLocker().Unlock() 看似简洁，但一旦函数中途 panic，RUnlock() 可能没执行；显式写 defer mu.RUnlock() 更可控。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
为什么写操作总在等，却等不到？——理解“写饥饿”真实成因
RWMutex 默认不保证公平性：只要还有新 RLock() 不断进来，正在排队的 Lock() 就永远卡在后面。这不是 bug，是设计取舍。
- 现象：写操作日志一直卡在 “waiting for readers…”，CPU 却不高
- 根因：高频轮询、短读+快释放+持续并发请求，导致 readerCount 始终 > 0
- 缓解方式：控制读协程节奏（加限流）、缩短读锁持有时间（别在
RLock()里做网络/DB 调用）、或改用带公平队列的第三方实现（如github.com/cespare/xxhash配合自定义调度）
零值可用，但别省略字段初始化
sync.RWMutex 零值有效，不需要显式 new() 或 &sync.RWMutex{}，这点和 sync.Mutex 一致。但若把它嵌入结构体，必须确保整个结构体本身是可寻址的（即不能传值拷贝后操作锁）。
- ✅ 安全：
type Config struct { data map[string]string; mu sync.RWMutex }，然后用config.mu.RLock() - ❌ 危险：把
Config当参数传值，再在函数内调mu.RLock()→ 锁作用在副本上，完全失效 - ⚠️ 注意：不要在持有
RLock()时修改结构体字段（哪怕只是导出字段），这属于未定义行为；读锁只保“读安全”，不保“结构稳定”
真正容易被忽略的是：写饥饿不是配置问题，而是流量模式与锁语义的天然冲突。与其强行调优 RWMutex，不如先问一句——这个数据，真的需要强一致性实时读到最新写入吗？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
