Go atomic.Bool 怎么实现无锁开关并保持可见性

如果多个 goroutine 只需要共享一个“开/关”状态，直接读写普通 bool 会产生数据竞争。更稳妥的写法是使用 sync/atomic 的 atomic.Bool：写入方调用 Store，读取方调用 Load。它不需要显式互斥锁，原子操作还能提供跨 goroutine 的同步语义。

atomic.Bool 只保证这个布尔状态的原子读写。若要让它代表“配置已经发布”，应先完成配置写入，再调用 Store(true)；读到 true 的 goroutine 才能安全读取那份之后不再并发修改的配置。

用 Load 和 Store 管理一个并发开关

先看一个功能开关。atomic.Bool 的零值就是关闭状态，因此可以直接作为结构体字段使用。下面的示例让工作 goroutine 在开关打开时处理任务：

package main

import (
    "fmt"
    "sync/atomic"
)

type FeatureGate struct {
    // enabled 只允许通过 Load 和 Store 访问。
    enabled atomic.Bool
}

func (g *FeatureGate) Enable() {
    // 原子写入 true，不与其他 goroutine 的 Load 形成数据竞争。
    g.enabled.Store(true)
}

func (g *FeatureGate) Enabled() bool {
    // 原子读取当前状态；不要直接读取内部字段。
    return g.enabled.Load()
}

func main() {
    var gate FeatureGate
    gate.Enable()
    fmt.Println(gate.Enabled()) // true
}

这里的“无锁”是指业务代码没有显式调用 Mutex.Lock，并不表示所有场景都没有等待，也不代表一次 Load 会连同其他业务字段一起形成快照。官方文档把 Bool 定义为原子布尔值，零值为 false，并明确要求首次使用后不能复制。

可见性来自“先写配置，再发布状态”

开关经常不是孤立的。例如服务启动时要先准备一份配置，再告诉工作 goroutine“配置可用了”。这时可以把配置视为发布后不再修改的只读数据：

type RuntimeConfig struct {
    Endpoint string
    Timeout  int
}

type ConfigGate struct {
    // cfg 在 Publish 返回后不再被并发修改。
    cfg   RuntimeConfig
    ready atomic.Bool
}

func (g *ConfigGate) Publish(cfg RuntimeConfig) {
    // 普通字段先写完，再用原子状态宣布配置已经就绪。
    g.cfg = cfg
    g.ready.Store(true)
}

func (g *ConfigGate) Read() (RuntimeConfig, bool) {
    // 读到 true 表示已跨过同一原子同步点。
    if !g.ready.Load() {
        return RuntimeConfig{}, false
    }
    return g.cfg, true
}

关键不在于把所有字段都改成原子类型，而在于建立清楚的生命周期：发布前由一个 goroutine 初始化，发布后读者只读。如果 cfg 之后还会被修改，就不能只靠 ready 保护；应使用互斥锁、重新发布不可变对象，或把完整状态放进合适的原子容器。

需要判断旧值时再用 Swap 或 CompareAndSwap

若只是“打开功能”，Store(true) 足够。若需要知道之前是否关闭，可以用 Swap(true)：

func (g *FeatureGate) EnableOnceWithNotice() bool {
    // Swap 原子地写入 true，并返回切换前的状态。
    wasEnabled := g.enabled.Swap(true)
    // false 表示这次调用确实完成了首次打开。
    return !wasEnabled
}

“只有一个 goroutine 能把它从关闭改为打开”则更适合 CompareAndSwap(false, true)：

func (g *FeatureGate) StartOnce() bool {
    // 只有观察到 false 的调用者才能完成这次状态转换。
    return g.enabled.CompareAndSwap(false, true)
}

多个 goroutine 同时调用时，成功者得到 true，其余调用者得到 false。这比先 Load、再根据结果 Store 更可靠，因为“检查旧值”和“写入新值”必须是同一个原子转换。

三个容易踩到的边界

1. 不要复制。把已经使用过的结构体按值传递、放进会复制元素的容器，都可能复制 atomic.Bool。优先使用指针，并在设计上避免复制包含原子字段的对象。
2. 不要混用普通读写。同一个状态不能一部分路径调用 Load/Store，另一部分直接把它当作普通字段读写。
3. 不要扩大保护范围。atomic.Bool 只保护自己的值；它可以作为发布信号，但不能让一个正在被修改的 map、slice 或配置结构体自动变成线程安全。

常见问题

atomic.Bool 和 Mutex 哪个更快？

不能只凭“无锁”下结论。单个状态位的读写可以优先考虑 atomic.Bool；如果需要保护多个字段的一致性，Mutex 往往更直接、更容易维护。

Load 读到 true 就一定能读到配置吗？

在配置写入先于被观察到的 Store，并且发布后不再并发修改的前提下，可以建立这条可见性链。若配置仍在变化，仍需额外同步。

什么时候用 CompareAndSwap？

当业务规则是“只有当前值为 old 才能改成 new”，例如只允许一个 goroutine 抢到首次启动权时使用；普通开关切换不需要增加 CAS 复杂度。