当前位置：首页 > 文章列表 > Golang > Go教程 > Go sync 怎样用 Mutex 保护复合读改写

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

来源：17golang原创 2026-10-18 05:46:33 0浏览收藏

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

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

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

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

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

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

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

goroutine、共享计数、复合读改写和 Mutex 边界的静态结构说明图 — 图1：复合读改写的静态结构说明图，查看共享状态与 Mutex 临界区的边界。

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

把共享状态和 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 }

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