sync.Mutex 一多就卡顿并非锁本身慢，而是多 goroutine 抢锁引发调度等待、自旋退避和线程切换等高开销；应按访问模式拆分锁、避免锁内阻塞，并在适用场景优先用 sync/atomic 或 sync.RWMutex。
为什么 sync.Mutex 一多就卡顿？
不是锁本身慢，而是多个 goroutine 频繁抢同一个 sync.Mutex 时，会陷入调度等待、自旋退避、甚至操作系统线程切换——这些开销远超临界区执行时间。常见于高频更新的共享计数器、缓存 map、状态标志等场景。
实操建议：
- 先用
go tool trace或runtime/pprof确认是否真有锁竞争：关注SyncMutexLock事件占比和平均阻塞时间，别凭感觉优化 - 避免把整个结构体用一把锁保护；按数据访问模式拆分，比如读多写少的字段单独用
sync.RWMutex - 别在锁内做任何可能阻塞的操作：
http.Get、time.Sleep、channel send/receive（除非确定接收方已就绪）
什么时候该换 sync/atomic 而不是锁？
sync/atomic 不是万能替代品，只适用于简单值类型（int32、int64、uintptr、unsafe.Pointer）的原子读写或 CAS 操作。它快，因为直接映射到 CPU 原子指令，无调度开销。
使用前提：
立即学习“go语言免费学习笔记（深入）”；
- 操作必须是单个变量，不能是结构体字段组合逻辑（比如“先读 A 再写 B”就不行）
- 不需要条件等待（
Cond）或复杂同步协议 - 注意对齐：64 位原子操作在 32 位系统上要求变量地址 8 字节对齐，否则 panic；可用
go vet检查
示例：高频计数器
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
var counter int64 // 替代 mutex + counter++ atomic.AddInt64(&counter, 1)
map 并发读写 panic 怎么安全处理？
Go 的原生 map 非并发安全，只要有一个 goroutine 写，其他 goroutine 无论读写都会触发 fatal error: concurrent map read and map write。这不是概率问题，是必然 panic。
方案选择取决于读写比例和一致性要求：
- 读远多于写（如配置缓存）：用
sync.RWMutex包裹map，读用RUnlock/RUnlock，写用Lock/Unlock - 写也频繁且需强一致性：改用
sync.Map，但注意它不保证迭代一致性，且零值初始化后不能直接赋值（要用LoadOrStore） - 写极少、读极多、可接受短暂 stale：用
atomic.Value存整个 map 指针，每次更新替换整张 map（copy-on-write）
如何判断该用 channel 还是锁？
channel 和锁解决的是不同层次的问题：channel 是**通信机制**，用于 goroutine 间传递控制流或数据；锁是**互斥机制**，用于保护共享内存访问。混用或误用会导致死锁或隐蔽竞态。
典型误判点：
- 用 channel 实现“计数器累加”——本质是共享状态修改，应优先考虑
atomic或细粒度锁，channel 只会增加调度和内存分配开销 - 用锁代替 channel 传递信号（如“任务完成”）——这剥夺了 goroutine 的协作语义，容易漏通知或重复通知
- 高吞吐管道场景（如日志批量刷盘），用带缓冲 channel + 单独 consumer goroutine，比多个 goroutine 抢同一把锁更清晰、更易压测
真正需要锁的地方，往往是：状态机转换、资源池分配、非幂等写操作（如数据库 insert）、需要精确顺序的复合更新。
锁优化最难的部分，往往不在代码怎么写，而在于你有没有准确识别出哪段逻辑真的需要串行——很多所谓“临界区”，其实只是设计时没想清楚数据边界。
