外观
锁、原子操作与内存模型
- 状态：未准备
- 适用方向：Go 全栈 / Go 后端
- 最近复习：待填写
- 下次复习：待安排
一句话回答
锁保护共享状态及业务不变量，原子操作适合简单独立状态；同步关系决定写入何时可见，睡眠和启动顺序不提供同步保证。
原理解释
数据竞争是无同步地并发访问同一内存且至少一个写入。count++ 包含读改写，不自动原子；可由同一 Mutex 保护或适当使用 atomic。
Unlock 与后续成功 Lock 建立同步关系。RWMutex 支持多个读者或一个写者，不支持读锁直接升级，也不应递归读锁；持锁时避免慢网络与不受控回调。
WaitGroup 等待完成，不限制并发。兼容常见版本的写法是启动前 Add(1)，任务里 defer Done()，最后 Wait；不要等 Wait 可能返回后才由新任务 Add。
sync.Once 首次执行 panic 后也视为已执行，不是失败重试器。sync.Pool 是可能随 GC 清理的临时对象复用池，不是可靠缓存或连接池。
场景与边界
余额检查与扣减等多步不变量应整体保护；逐个字段 atomic 不等于跨字段一致。锁使用后不能复制；原子读与普通写混用也可能竞态。
项目中的应用
沿 SimulSpeak 会话协调核对结果优先级、停止状态、配音派发是否遵循同一同步协议。
常见追问
- 如何避免死锁？ 固定多锁顺序、缩小临界区，避免持锁等待依赖自己释放的任务。
- 读多就必用读写锁？ 短操作和低竞争时可能更慢，按基准判断。
- race 通过就安全？ 只说明本次覆盖路径未检出，不能证明所有调度安全。