Go sync/atomic 用 Bool 实现无锁开关

服务里有一个“是否接收新请求”的开关：后台 goroutine 负责切换，多个请求 goroutine 负责读取。若大家直接共享一个普通 bool，读写同时发生时就会形成数据竞争。这个场景只需要一个布尔状态，不需要把整段流程锁住，sync/atomic.Bool 就很合适。

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

把共享开关声明为 atomic.Bool，读取统一使用 Load，修改统一使用 Store；如果要根据旧值抢一次切换，再使用 Swap 或 CompareAndSwap。它解决的是一个布尔值的原子访问，不是多个配置字段的事务锁。

先确认问题是单一共享布尔状态

先看状态模型：如果业务只关心“开启/关闭”，并且读写者之间不需要同时修改其他字段，就可以把普通字段替换成 atomic.Bool。它的零值就是 false，声明后可以直接使用；官方文档也要求它在第一次使用后不要再复制。

下面的例子故意让开关成为结构体字段，避免把它复制到函数参数或局部变量中：

package feature

import "sync/atomic"

type Gate struct {
	// enabled 只表达一个是否放行的共享状态。
	enabled atomic.Bool
}

func (g *Gate) Allowed() bool {
	// 读取必须走 Load，不能把 atomic.Bool 当普通 bool 解引用。
	return g.enabled.Load()
}

func (g *Gate) SetAllowed(v bool) {
	// Store 原子发布新的开关值，调用方不需要持有互斥锁。
	g.enabled.Store(v)
}

这里的“无锁”是访问这个单一状态时不需要业务层 Mutex，并不代表整个请求处理过程都没有阻塞，也不代表修改开关时可以顺手改动其他共享字段。

用 Load 和 Store 读写开关

把读写入口收窄后，问题现场通常很容易定位：凡是判断开关的地方只调用 Load，凡是管理端或控制循环改变状态的地方只调用 Store。Go 内存模型把原子操作作为同步机制；多个 goroutine 看到的值不会因为普通读写重排成数据竞争。

func (g *Gate) Handle() error {
	// 先原子读取当前状态，再决定是否进入后续逻辑。
	if !g.enabled.Load() {
		return ErrClosed
	}
	// 这里执行的是与开关无关的业务操作。
	return processRequest()
}

func (g *Gate) Open() {
	// 管理操作只发布布尔状态，不在同一处修改其他共享配置。
	g.enabled.Store(true)
}

排查时可以沿着这条线索检查：是否仍有代码直接读写普通副本、是否把 atomic.Bool 作为值传参、是否用一个开关去暗示多个字段已经同时更新。后两种写法都会让“原子”边界变得不清楚。

根据竞争方式选择 Swap 或 CompareAndSwap

当需求从“设置成某个值”变成“我想拿到旧值”或“只有旧值符合条件才允许切换”，就不要用一次 Load 再接一次 Store 来拼装。两个调用之间可能插入另一个 goroutine 的修改。

func (g *Gate) CloseAndReport() bool {
	// Swap 一次完成替换，并返回替换前的状态。
	return g.enabled.Swap(false)
}

func (g *Gate) OpenOnce() bool {
	// 只有仍为关闭状态时才切换为开启，成功者得到 true。
	return g.enabled.CompareAndSwap(false, true)
}

Swap 适合“无论旧值是什么，都替换并告诉我旧值”；CompareAndSwap 适合“只允许满足条件的一方完成切换”。例如多个 goroutine 同时调用 OpenOnce 时，只有观察到旧值为 false 的一次切换会成功。

复制和复合状态是两个高频误区

第一，atomic.Bool 在第一次使用后不要复制。把包含它的结构体按值返回、放进值切片，或者把它作为值参数传递，都可能产生两个看似相同、实际分离的状态。通常应使用指针接收者，并在对象生命周期内保持同一个实例。

第二，如果开关变化必须和阈值、模式、版本号一起生效，单独一个 atomic.Bool 不够。可以把完整配置做成不可变快照，再用 atomic.Value 或 atomic.Pointer 发布；如果多个字段需要原地协同修改，则应重新评估 sync.Mutex。原子布尔值只保证这个值的访问和切换，不会自动把旁边的字段绑成一个事务。

最终判断可以归纳为一句话：如果共享对象只有一个布尔事实，用 atomic.Bool 把读写边界固定下来；一旦需要复制、协同修改或维护多个字段，就应该升级状态模型，而不是继续堆原子调用。

相关问题

atomic.Bool 的零值是什么？

零值是 false，可以声明后直接调用 Load，无需额外初始化。

Load 后再 Store 能实现只切换一次吗？

不能把两次调用当成一个不可分割操作。需要条件切换时使用 CompareAndSwap，让判断和更新由一次原子操作完成。

atomic.Bool 能替代互斥锁吗？

只能替代“单一布尔状态”的互斥访问。若临界区包含多个共享字段或需要保护一组不变量，仍应使用互斥锁或不可变快照方案。