Go atomic.Bool 怎样安全维护服务开关

如果一个 Go 服务只有“接不接受新请求”这一项共享状态，atomic.Bool 是比普通 bool 更稳妥的开关实现：请求侧用 Load，管理侧用 Store，需要拿到旧状态时再用 Swap。它解决的是这个布尔值在多个 goroutine 间的原子读写，不是完整的配置中心，也不会自动取消已经开始执行的请求。

官方文档：https://pkg.go.dev/sync/atomic#Bool

atomic.Bool 先解决共享开关的读写一致性

服务开关通常是读多写少：每个请求都要判断一次，真正修改状态的操作却很少。普通 bool 在并发读写下会形成数据竞争；给它包一层 atomic.Bool 后，读写入口被明确限制为原子方法。官方文档说明它的零值为 false，因此可以把“默认关闭”直接编码进结构体的初始状态。

把它放进一个小的服务对象里，能让开关的所有权更清楚：

package service

import "sync/atomic"

type ServiceSwitch struct {
	// enabled 只通过 Load、Store 等原子方法访问。
	enabled atomic.Bool
}

func (s *ServiceSwitch) Accepting() bool {
	// 请求侧只读取当前状态，不在这里修改开关。
	return s.enabled.Load()
}

func (s *ServiceSwitch) SetAccepting(enabled bool) {
	// 管理侧一次性替换布尔值，避免普通读写和原子读写混用。
	s.enabled.Store(enabled)
}

这里的模式很窄：Accepting 只回答“现在是否允许继续进入”，SetAccepting 只负责改变共享状态。它没有把数据库连接、关闭流程和配置刷新都塞进一个布尔字段，所以后续的边界仍然容易判断。

请求侧用 Load，管理侧用 Store

把开关接到请求入口时，判断应该发生在真正开始业务动作之前。下面的示例只表达控制边界：它没有声称返回码或业务处理已经在本机执行。

type Handler struct {
	gate ServiceSwitch
}

func (h *Handler) Serve() string {
	// 先读取开关，再决定是否进入新的业务处理。
	if !h.gate.Accepting() {
		return "service is not accepting new requests"
	}

	// 这里代表已经通过开关判断的后续工作。
	return "request accepted"
}

func (h *Handler) Disable() {
	// 切换只影响之后来到判断点的新请求。
	h.gate.SetAccepting(false)
}

最容易误解的地方是“关闭开关”等于“服务已经停止”。它只保证后续判断能看到新的布尔状态；正在执行的请求、已经投递到队列的任务、已经打开的连接，仍需各自的取消、超时和排空策略。若业务要求“关闭后等待所有工作结束”，那是生命周期协调问题，不能由 atomic.Bool 单独完成。

Swap 和 CompareAndSwap 负责表达切换意图

Store 只关心新值是什么。如果管理接口还需要知道“这次是否真的发生了状态变化”，可以用 Swap：它原子地写入新值并返回旧值。若只有在旧状态符合预期时才能切换，则使用 CompareAndSwap，把检查和写入放在同一个原子动作里。

func (s *ServiceSwitch) DisableOnce() bool {
	// Swap 返回切换前的状态；只有从开启到关闭才报告一次变化。
	return s.enabled.Swap(false)
}

func (s *ServiceSwitch) EnableIfDisabled() bool {
	// 只有旧值为 false 时才切到 true，避免重复启用副作用。
	return s.enabled.CompareAndSwap(false, true)
}

三个边界决定这个模式是否安全

把字段换成 atomic.Bool 并不等于所有并发问题都消失，至少要守住三个边界。

• 访问边界：同一个状态不要一边调用 Load，另一边直接读取内部字段。外部只拿到方法，不暴露可变字段，最容易保持一致。
• 对象边界：官方文档规定 Bool 首次使用后不能复制。把包含它的服务对象按值传递、放进会复制的结构，都会让所有权变得危险；优先使用指针和稳定的单一实例。
• 业务边界：布尔开关只能表达两种状态。若还需要“排空中、切换原因、版本号或恢复动作”，就已经超出一个布尔值的表达能力，应把状态协调设计单独拿出来。

也要注意，原子状态只保护这个字段本身。如果切换开关的同时还要更新一组配置，不能因为其中一个字段是原子类型，就默认整组配置具备一致快照。

用清单判断是否该用 atomic.Bool

这个模式适合“一个值、两种状态、读多写少、切换动作简单”的服务入口。如果答案大多为“是”，atomic.Bool 通常足够：

• 请求是否只需要判断允许或拒绝，而不是读取一组彼此关联的配置？
• 切换是否可以只影响之后到达判断点的工作？
• 是否能把所有访问收口到 Load、Store、Swap 或 CompareAndSwap？
• 包含该字段的对象是否能保持单一实例，并避免首次使用后的复制？
• 关闭后的排空、取消和资源释放是否由独立机制负责？

反过来，如果开关背后牵涉多个字段、多个阶段和必须回滚的动作，继续增加布尔判断只会把状态机藏进业务代码。此时应先画清状态和转移，再决定原子类型在其中承担哪一小块职责。

常见问题

atomic.Bool 的默认值是什么？

零值是 false。如果服务默认不接收新请求，可以直接声明字段；如果默认开启，则在初始化阶段调用一次 Store(true)。

Store(false) 会立即停止正在处理的请求吗？

不会。它改变共享开关的状态，正在处理的请求是否结束要由取消信号、超时或业务流程负责。

为什么不直接使用普通 bool？

当多个 goroutine 同时访问并且至少一方写入时，普通字段需要额外同步；atomic.Bool 把这个单字段的原子访问语义直接放在 API 中。

什么时候应该用 CompareAndSwap？

当“只有旧值仍然是某个预期状态时才允许切换”很重要，例如只允许第一个关闭者触发一次后续动作时，它比先 Load 再 Store 更能表达条件更新。

把 atomic.Bool 当作服务入口的一枚原子闸门，读写职责会很清楚：Load 负责判断，Store 负责设置，Swap 和 CompareAndSwap 负责把切换意图说完整；至于已经开始的工作和多字段配置，则交给各自的生命周期机制。