Go atomic.OrUint32 怎样原子设置状态位

我在给服务加“已就绪、已加载、已同步”这类状态时，最容易犯的错，是把几个布尔变量拆散，再用一串读改写去更新它们。只要这些状态被多个 goroutine 共享，读到旧值、覆盖别人的更新就不再是写法问题，而是竞态问题。sync/atomic.OrUint32适合解决其中一个很明确的场景：把多个独立标记放进一个 uint32 状态字，用按位 OR 原子地设置一个或多个 bit。

调用 atomic.OrUint32(&flags, mask) 会原子设置 mask 中的位，并返回操作前的旧值。它适合“只增不减”的状态标记；如果业务需要复杂状态转换、计数或清除位，就不应把它包装成万能状态机。

先把状态位和掩码分开

状态字的核心不是把数字写得更短，而是先约定每一位的含义。比如最低三位分别表示服务已启动、配置已加载、连接已健康，那么每个标记都应是独立的命名常量，而不是散落在业务代码里的魔法数字。

package main

import (
    "fmt"
    "sync/atomic"
)

const (
    // 每个常量只占状态字中的一位，便于组合和阅读。
    flagStarted  uint32 = 1 

这里的 flagLoaded|flagHealthy 是一个组合掩码，表示本次同时设置两位。设置之后，原来的 0 位会变成 1 位，已经是 1 的位仍然保持 1。读取某一位时，再用 flags&flagLoaded != 0 判断即可。

理解 OrUint32 的原子语义

OrUint32 的函数签名是 func OrUint32(addr *uint32, mask uint32) (old uint32)。第一个参数是共享状态字的地址，第二个参数是要设置的位掩码，返回值是修改前的完整状态，而不是修改后的状态。

这个“返回旧值”很有用。假设多个 goroutine 都可能设置 flagLoaded，你想知道这次是不是第一次设置，就不能先 Load、判断、再 Store，因为两个 goroutine 可能同时读到 0。应该根据同一次原子 OR 返回的 old 判断：

func markLoaded(flags *uint32) bool {
    const loaded uint32 = 1 

这个返回值只说明“这次原子操作前，该 bit 是否为 0”。它不等于完整的业务领主权，也不保证后续代码仍然能独占这个状态。如果需要把设置状态和其他资源分配绑定成不可分割的事务，单个 OR 操作是不够的。

用命名常量构造可读状态字

我更倾向于把状态位定义放在同一个小范围内，并为组合状态提供普通函数。这样调用方看到的是 markReady 或 markLoaded，而不是到处出现 1。状态位的编号一旦进入持久化格式、日志协议或跨进程接口，就应当视为兼容契约，不能随意重排。

const (
    // 位编号一旦对外使用，就不要因为新增状态而重新排列。
    flagStarted uint32 = 1 

这里的要点是“设置”和“读取”都采用与共享数据匹配的原子访问。不能因为某个读取只是一个简单的位判断，就把它改成普通的 *flags 解引用；那会让同一变量同时存在不一致的访问方式。

处理并发写入与旧值判断

按位 OR 的价值，在于不同调用者可以设置不同 bit 而不互相覆盖。一个调用者设置 flagLoaded，另一个调用者设置 flagReady，两次原子 OR 的结果会保留两边的位。

但这不意味着所有状态都能塞进一个字。比如“加载中”和“加载完成”互斥，设置完成前还要检查版本号、回滚旧对象，这已经是多条件状态转换；直接 OR 一个完成位无法表达检查和更新之间的整体约束。此时应把状态转换设计成更明确的同步协议，不要只给整数换一个更像原子的名字。

比较 Uint32.Or 的类型化写法

当前 sync/atomic 也提供了 atomic.Uint32 类型及其 Or 方法。两者的位运算语义相同：都按掩码原子设置 bit 并返回旧值。差别主要在状态字的组织方式：函数式 API 接收一个外部 *uint32，类型化 API 把状态放进 atomic.Uint32 对象中。

type ServiceState struct {
    // Uint32 的零值可直接使用，字段本身表达“这是原子状态”。
    flags atomic.Uint32
}

func (s *ServiceState) markReady() uint32 {
    const ready uint32 = 1 

如果状态是一个结构体的长期成员，atomic.Uint32 往往更能提醒维护者“这个字段必须通过原子方法访问”。如果状态已经由现有结构体中的 uint32 字段承载，或者 API 需要接收指针，那么 atomic.OrUint32 更容易接入。两种写法不要对同一个地址混搭成一套隐含规则。

最后检查：什么时候只用 OrUint32

• 状态可以拆成彼此独立的 bit，并且本次操作只需要把 bit 设为 1。
• 共享变量的所有读写都遵守同一套原子访问约定。
• 需要判断“这次是不是首次设置”时，直接使用 Or 返回的旧值。
• 状态位编号有命名常量，并且不会因为内部重构随意改变。
• 不把一个 OR 操作误当成复杂业务事务、计数器或完整状态机。

一句话概括：atomic.OrUint32 是一个很窄但很稳的工具——它把“给共享状态增加一个标记”做成原子动作。先把状态拆成互不冲突的 bit，再用返回的旧值做判断，代码才既短又不会掩盖真正的并发边界。

相关问题

OrUint32 返回的是新值还是旧值？

返回操作前的旧值。需要读取设置后的完整状态时，再使用 atomic.LoadUint32 或类型化对象的 Load。

多个 goroutine 同时设置不同 bit 会互相覆盖吗？

使用原子 OR 设置不同 bit 时不会像普通读改写那样互相覆盖；但后续业务判断仍可能需要额外同步。

为什么不直接用普通的 flags |= mask？

普通复合赋值包含读和写两个阶段，并不能把共享变量的更新作为一个原子动作。