用 Channel 替代锁可彻底消除竞争：启动专属 Goroutine 监听 Channel 处理写请求，读取快照即可，适用于计数器、日志等场景。
Go 语言中，锁竞争（Lock Contention）是并发性能瓶颈的常见原因。过度依赖 sync.Mutex 或 sync.RWMutex 会导致 Goroutine 频繁阻塞、调度开销上升，甚至引发延迟毛刺。真正有效的优化不是“少用锁”，而是“用对机制”：该上 Channel 的地方别硬扛，该用原子操作的地方别加锁。
用 Channel 替代共享内存 + 锁
Go 的哲学是“不要通过共享内存来通信，而要通过通信来共享内存”。很多场景下，把“多个 Goroutine 竞争修改同一变量”改成“单个 Goroutine 串行处理请求”，能彻底消除锁竞争。
- 适用场景：计数器更新、状态聚合、日志写入、配置热更新等低频写、高频读或需顺序保证的操作。
- 典型模式：启动一个专属 Goroutine 监听 Channel，所有写请求发消息过去；读操作可直接读取当前快照（若需一致性，可加简单读锁或用原子值）。
-
例子：替代带锁的请求计数器
type Counter struct {
ch chan int
val int
}
func NewCounter() *Counter {
c := &Counter{ch: make(chan int, 100)}
go func() {
for delta := range c {
c.val += delta
}
}()
return c
}
func (c *Counter) Inc() { c.ch func (c *Counter) Get() int { return c.val }
用 atomic 替代简单字段的互斥锁
当只对整数、指针、布尔等基础类型做无依赖的读写（如开关、计数、标志位），sync/atomic 是零分配、无调度、无锁的最优解。
-
关键原则：只要操作是“读-改-写原子”（如
atomic.AddInt64）或“比较并交换”（atomic.CompareAndSwapInt32），就不用 Mutex。 - 注意边界：不能用 atomic 操作复合结构（如 struct 字段部分更新），也不能替代需要临界区逻辑（如“先查再删”这类非原子业务逻辑）。
-
常用组合：
atomic.LoadUint64+atomic.StoreUint64做状态快照；atomic.Value安全存取任意类型（如配置对象）；atomic.Bool（Go 1.19+）替代 bool 字段锁。
缩小锁粒度 + 读写分离
如果必须用锁，避免“一把大锁护全局”。合理拆分能显著降低竞争概率。
立即学习“go语言免费学习笔记（深入）”；
- 分片锁（Sharding）：比如缓存 Map，按 key 哈希分到 N 个独立 Mutex，冲突率下降至约 1/N。
-
读写分离：读多写少时，优先用
sync.RWMutex；更进一步，用atomic.Value+ 写时复制（Copy-on-Write），让读完全无锁。 - 避免锁内调用未知函数：锁持有期间不要做网络 IO、阻塞系统调用或调用可能死锁的第三方库——这会人为拉长临界区。
诊断先行：确认真有锁竞争
别凭感觉优化。先用工具定位热点：
-
go tool trace查看 Goroutine 阻塞在 Mutex 上的时间； -
go tool pprof -mutex分析 mutex contention profile； - 用
runtime.SetMutexProfileFraction(1)开启采样（上线慎用，有开销）。
基本上就这些。Channel、atomic、细粒度锁不是互斥选项，而是不同抽象层级的协作工具。选哪个，取决于你要保护的是“状态变更顺序”、“内存可见性”，还是“业务逻辑排他性”。用对地方，锁竞争自然退场。
