Golang锁与channel怎么选？并发设计思路解析

该用 sync.Mutex 而非 chan 时：保护小粒度共享内存读写（如计数器、字段更新），无需协程协作；chan 适用于解耦生产消费、传递语义化消息（如任务、信号、超时）。

什么时候该用 sync.Mutex 而不是 chan

当你要保护一段共享内存的读写，且操作粒度小、不涉及协程协作逻辑时，sync.Mutex 更直接。比如更新一个计数器、修改结构体字段、缓存命中后填充值——这些都不需要“通知别人我改完了”，只需要“别同时改”。

常见错误是强行用 channel 做互斥：开一个容量为 1 的 chan struct{}，每次操作前 select 发送，完后再接收。这不仅多出 goroutine 调度开销，还掩盖了本质是“临界区保护”的事实。

• 适合场景：map 并发读写（需配合 sync.RWMutex）、全局配置热更新、对象状态标记
• 注意点：避免在锁内做阻塞操作（如 HTTP 调用、数据库查询），否则会拖慢所有等待者
• 性能差异：Mutex 加锁/解锁是纳秒级；channel 操作至少微秒级，尤其带缓冲或跨 goroutine 时

什么时候必须用 chan 而不能用锁

当你需要解耦生产与消费节奏、协调多个 goroutine 的执行顺序、或者传递数据本身带有语义（比如“任务来了”“结果好了”“该退出了”），channel 是唯一自然的选择。锁解决不了“谁来处理这个请求”，只解决“谁能改这个变量”。

典型误用：用 Mutex 包裹一个队列，然后轮询检查是否有新任务——这既浪费 CPU，又无法响应中断。而 chan 天然支持阻塞等待、超时控制、select 多路复用。

• 适合场景：worker pool 分发任务、信号通知（如 done chan struct{}）、流式数据处理（日志、metrics）、超时控制（time.After 配合 select）
• 参数差异：无缓冲 channel 是同步点，有缓冲 channel 是有限缓冲区；别默认设大缓冲，容易掩盖背压问题
• 容易踩的坑：close 已关闭的 channel 会 panic；向已关闭的 channel 发送也会 panic；只从 channel 读不关它，可能造成 goroutine 泄漏

sync.Once 和 chan 在初始化场景中的取舍

单次初始化（如加载配置、连接数据库）首选 sync.Once，而不是用 channel 等待某个 “init done” 信号。后者要额外管理 goroutine 生命周期、channel 关闭时机，还可能因忘记关闭导致死锁。

sync.Once 内部用原子操作+Mutex 实现，轻量且语义清晰；它的 Do 方法保证函数最多执行一次，且所有调用者会阻塞直到完成——这正是你想要的“等初始化完再继续”。

• 反例：起一个 goroutine 做初始化，用 chan bool 通知完成。若初始化失败，channel 可能永远不写入，调用方永久阻塞
• 正解：把初始化函数传给 once.Do(func(){...})，失败时在函数内记录错误，后续调用可检查错误变量
• 注意：sync.Once 不处理错误传播，错误需自行保存到包级变量或返回值中

混合使用时的关键边界：别让 channel 成为锁的替身

常见设计陷阱是用 channel 封装状态变更，比如定义 type Cmd int; const Inc Cmd = iota; Dec，再起一个 goroutine 从 chan Cmd 里读指令并更新变量。表面看“没有锁”，实际只是把锁逻辑移到了单个 goroutine 内部——它仍是串行处理，且引入了额外调度和内存分配。

这种写法只有在需要异步化 + 命令合并（如防抖）或跨进程边界时才有意义。如果只是保护一个整数，sync/atomic 或 sync.Mutex 更合适。

• 真正值得封装成 channel 的操作：涉及 IO、网络、外部依赖，或需要与其他事件交叉响应（如定时器 + 用户输入）
• 性能提示：频繁发送小结构体到 channel 会产生大量堆分配；可考虑复用对象或使用指针 + 同步池
• 最易忽略的一点：channel 的方向性（<-chan / chan<-）是编译期契约，但 runtime 不强制检查；把双向 channel 当单向用，可能在后期重构中意外破坏隔离性