当前位置：首页 > 文章列表 > Golang > Go问答 > Go sync/atomic.Bool CompareAndSwap 怎么做一次性状态切换：竞态判断与失败重试边界

Go sync/atomic.Bool CompareAndSwap 怎么做一次性状态切换：竞态判断与失败重试边界

来源：17golang原创 2026-08-28 12:47:58 0浏览收藏

一次性初始化、只允许一个 goroutine 刷新缓存，或者只执行一次迁移，都可以用 atomic.Bool.CompareAndSwap 把“检查当前状态”和“切换到已占用”合成一个原子动作。调用返回 true 说明当前 goroutine 抢到了执行权，返回 false 则说明别的 goroutine 已经先切换了状态；失败分支应根据业务决定跳过、等待或稍后重试，不能把失败误当成异常。

CompareAndSwap(false, true) 适合做一次性门闩：只有观察到当前值确实是 false 的调用能把它改成 true，其余调用都会走失败分支。

要点速览

CAS 的比较和写入是一个不可拆开的原子步骤。
成功只代表拿到一次执行权，不代表业务函数已经成功。
不要复制已经使用过的 atomic.Bool；多进程场景也不能靠它做全局锁。

先从一次重复初始化现场看结果

假设服务启动时有多个 goroutine 同时触发 initCache。普通的“先 Load、再 Store”会把判断和写入拆开，两个调用都可能看到 false。CompareAndSwap(false, true) 则把竞争压缩到一个原子状态转换。

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

type CacheInit struct {
    started atomic.Bool
}

func (c *CacheInit) initCache(id int) {
    if !c.started.CompareAndSwap(false, true) {
        fmt.Println(id, "skip")
        return
    }
    fmt.Println(id, "initialize")
}

func main() {
    var c CacheInit
    var wg sync.WaitGroup
    for id := 1; id

两次输出的顺序不固定，但只有一次会打印 initialize，另一次会打印 skip。这里的成功路径是“抢到门闩后执行初始化”，不是“CAS 自动完成初始化”；业务函数仍然需要自己处理返回值和错误。

沿着 CompareAndSwap 的真实状态路径排查

代码里的节点很少：initCache 读取 started，调用 CompareAndSwap(false, true)，再分流到 skip 或 initialize。CAS 失败时并不会把状态改回去，也不会自动排队等待。

Go initCache 调用 CompareAndSwap 后从 started=false 转为 started=true，并进入 initialize 或 skip 的状态变化示意图

图中 initCache、started、CompareAndSwap(false, true)、initialize 和 skip 都来自本节代码。若初始化函数返回错误，状态已经是 true，下一次调用不会自动重试，这正是一次性门闩和可重试任务的边界。

先确认失败是竞争，还是业务失败

排查时先把结果分成两类。CompareAndSwap(false, true) 返回 false，表示当前值不是期望的 false，通常意味着别人已经抢先；它不是初始化函数的错误。相反，CAS 返回 true 后，initialize 仍可能因为网络、磁盘或配置校验失败而出现 业务错误。

Go CompareAndSwap false 进入 skip、true 进入 initialize 并单独处理业务错误的控制流示意图

观察结果	状态变化	处理建议
CAS 返回 false	没有获得执行权	按场景跳过、等待已有人完成，或安排明确重试
CAS 返回 true，initialize 成功	false → true	继续使用已完成的资源
CAS 返回 true，initialize 失败	仍为 true	设计回滚或把状态模型改成可表达失败/重试