Go sync 怎样用 Mutex 保护复合读改写

在 Go 里，给一条赋值语句加锁并不等于保护了业务操作。只要逻辑包含“读出当前值、判断条件、再写回新值”，中间就存在竞争窗口。这个窗口可能让两个 goroutine 都基于旧快照做决定，最后一次写回覆盖前一次结果。

官方资料：https://pkg.go.dev/sync#Mutex

把共享状态和同一把 sync.Mutex 绑定，并让读取、判断、写回处于同一个临界区，才能把复合读改写当成一个不可分割的动作。方法用指针接收者，解锁放进 defer，锁外只保留不需要共享状态的慢操作。

本文只讨论标准库 sync.Mutex 的使用边界，不把它扩展成第三方并发方案的对比。示例代码是静态示例，配图也是结构说明图，不是运行截图。

先识别复合读改写的竞争窗口

假设账户余额不能为负，扣款逻辑看起来只有三步：读取余额、判断余额是否足够、写回余额。若读取和写回之间没有同一把锁，两个请求可能同时读到 100，各自判断扣款 80 合法，最终余额却只减了一次。

// 演示危险边界：读取、判断和写回不应被拆成彼此独立的临界区。
func unsafeSpend(balance *int, amount int) bool {
    // 这里读到的快照可能在下一行之后就已经过时。
    if *balance 

图中的关键不是某一次执行顺序，而是共享计数同时受到两个调用方影响。保护目标应是整个“读取快照—条件判断—写回值”组合，而不是只保护其中一行。

把共享状态和 Mutex 绑定

更稳妥的做法是把锁放进拥有共享数据的结构体。零值 Mutex 可以直接使用，但已经使用过的 Mutex 不能再复制，所以更新方法应使用指针接收者，避免把状态对象按值传递。

package account

import "sync"

type AccountState struct {
    mu      sync.Mutex
    balance int
}

// AddIfEnough 把余额判断和扣减绑定在同一个临界区内。
func (a *AccountState) AddIfEnough(amount int) bool {
    a.mu.Lock()
    defer a.mu.Unlock() // 任何返回路径都负责释放同一把锁。

    // 读取、判断和写回之间没有对外暴露窗口。
    if a.balance 

这里的“不变量”是余额不能小于零。只要所有修改余额的入口都遵守同一把锁，判断和更新就不会被另一个入口插入。若还有充值、退款或批量调整方法，它们也必须把相关字段纳入同一套保护边界。

让读取、判断、写回处于同一个临界区

复合操作内部可以做必要的计算，但不要在持锁期间调用不受控的外部慢操作，例如网络请求、文件写入或等待另一个可能回调当前对象的组件。需要把结果带出锁时，先复制一个快照，再在解锁后处理。

// Snapshot 返回副本，让调用方在锁外读取稳定数据。
func (a *AccountState) Snapshot() int {
    a.mu.Lock()
    defer a.mu.Unlock()

    // 基础类型直接复制；复杂对象则应做足够深度的副本。
    return a.balance
}

func settle(a *AccountState, amount int) bool {
    // 只把共享状态决策放在锁内，外部结算放在锁外。
    if !a.AddIfEnough(amount) {
        return false
    }
    // 这里可以执行不属于 AccountState 的慢操作。
    recordSettlement(amount)
    return true
}

// recordSettlement 代表锁外的外部操作；示例不依赖真实服务。
func recordSettlement(amount int) { _ = amount }

如果返回的是切片、映射或指针，不能只复制容器头部就认为安全；要根据调用方是否会修改底层数据决定是否做深拷贝。锁保护的是对象内部状态，不自动保护已经交给外部的可变引用。

处理锁的边界与审计清单

可以按下面几项审查一段复合更新代码：

• 同一个状态对象是否始终使用同一把 Mutex，是否有按值复制或隐式复制？
• 读取、条件判断、写回是否全部位于锁内，是否存在“先解锁再决定”的间隙？
• 是否用指针接收者，是否用 defer Unlock 覆盖提前返回和错误分支？
• 是否把慢操作、回调和可能再次访问该对象的调用移到了锁外？
• 快照是否复制了底层可变数据，调用方是否会绕过锁直接修改内部字段？

还要记住两个 API 边界：Mutex 的零值可直接使用，但第一次使用后不能复制；Unlock 必须对应已经加锁的 Mutex，否则会触发运行时错误。TryLock 虽然存在，但官方文档也提醒正确使用场景较少，不能用它掩盖临界区设计不清的问题。

常见问题

只给写操作加锁，读取可以不加吗？

如果读取与写入之间存在并发访问，就不能只看“这行是不是赋值”。读取也必须使用与写入匹配的同步协议，否则可能读到不一致状态，或者让复合判断基于过期快照。

为什么不把整个业务函数都放进锁里？

锁的范围要覆盖不变量所需的最小连续区间。过度扩大范围会让无关请求排队；过度缩小范围又会重新暴露竞争窗口。实践中可以先锁住共享状态决策，再复制结果，最后在锁外做外部操作。

小结

sync.Mutex 保护复合读改写的核心，是把“读取—判断—写回”视为一个整体，并把这项约束落实到拥有状态的对象上。指针接收者、defer Unlock、快照复制和锁外慢操作共同决定了边界是否可靠。