sync.Mutex 在高争用场景下易成瓶颈，适合小临界区低频修改；读多写少用 RWMutex，高频计数优先 atomic，channel 须带缓冲+单消费者且避免滥用。
sync.Mutex 在高争用场景下容易成为瓶颈
当多个 goroutine 频繁读写同一共享变量时，sync.Mutex 的锁竞争会显著抬高延迟。实测中，100 个 goroutine 对单个计数器做 10 万次递增，平均耗时比 channel 方案高出 3–5 倍——这不是因为 Mutex 本身慢，而是因为所有 goroutine 被串行堵在同一个锁上。
关键点在于：Mutex 适合保护「小块临界区 + 低频修改」；一旦临界区变长（比如含网络调用、文件读写），或 goroutine 数量远超 CPU 核心数，争用就会指数级上升。
- 避免在
Lock()和Unlock()之间做任何阻塞操作 - 考虑用
sync.RWMutex替代，若读多写少（如配置缓存） - 不要用 Mutex 保护整个函数逻辑，只锁真正需要互斥的那几行
channel 实现计数器时要注意缓冲与死锁
用 channel 模拟原子计数器（如通过 chan int 发送/接收值）看似优雅，但默认无缓冲 channel 会强制同步等待：每次 send 都要等对应 recv，这本质上把并发压成了串行。性能反而比 Mutex 更差。
正确做法是使用带缓冲的 channel + 单独的“处理 goroutine”：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int, 1024) // 缓冲足够大，避免发送阻塞
go func() {
var sum int
for v := range ch {
sum += v
}
}()
// 其他 goroutine 只管 send，不关心谁 recv
- 缓冲大小需权衡内存占用与阻塞概率；1024 是常见起点，可按压测结果调整
- 必须确保有且仅有一个 goroutine 调用
range ch，否则会漏数据或 panic - channel 不适合高频、细粒度状态更新（如每毫秒更新一次指标），此时 Mutex 或
atomic更合适
atomic 比 sync.Mutex 和 channel 都快，但能力有限
对整数、指针、unsafe.Pointer 的原子操作（如 atomic.AddInt64、atomic.LoadUint64）在 x86-64 上通常编译为单条 CPU 指令，无锁无调度开销。在纯计数类 benchmark 中，它比 Mutex 快 10 倍以上，比带缓冲 channel 快 3–4 倍。
但它只支持有限类型和操作：atomic 无法直接保护结构体、map、slice 或任意函数逻辑。
- 能用
atomic就别用 Mutex 或 channel —— 前提是操作满足其约束 -
atomic.Value可安全读写任意类型，但写入是整体替换，不适合部分更新 - 注意内存顺序：默认是
SeqCst，若需更高性能且能控制依赖关系，可用atomic.LoadAcquire等显式语义
基准测试时 goroutine 数量和工作负载必须贴近真实场景
用 go test -bench 测出来的数字，离开具体参数就毫无意义。例如：10 个 goroutine 下 Mutex 可能略快于 channel；但升到 500 个，channel（带缓冲+单消费者）可能反超——因为 Mutex 争用爆炸，而 channel 把压力转移到了 goroutine 调度器。
真实服务中，goroutine 往往混合执行 IO、计算、锁操作。单一 micro-benchmark 容易误导。
- 用
runtime.GOMAXPROCS控制并行度，模拟不同 CPU 配置 - 在
Benchmark函数里加入真实业务逻辑片段（如 JSON 解析、DB 查询），而非只测加法 - 观察
pprof中sync.Mutex.Lock和runtime.gopark的调用占比，比 raw ns/op 更能定位瓶颈
最常被忽略的一点：channel 的“性能”其实取决于你如何组织数据流。一个设计不良的 channel 网络（比如多层转发、无缓冲扇出）会比 Mutex 慢一个数量级，而这不是 channel 的问题，是你没把它当通信原语用，而是当作了锁的替代品。
