Go atomic.Uint64.And 怎样用位操作清除状态标志

如果一个并发对象只有少量开关状态，可以把它们压进同一个 atomic.Uint64。清除某一位时，关键不是先读取再写回，而是调用 state.And(^flag)：And 会原子地完成按位与，并返回更新前的旧值。这样既能清掉目标状态，也能知道它在清除前是否存在。

官方地址：https://pkg.go.dev/sync/atomic#Uint64.And

清除状态位的公式是“目标位掩码取反后与当前值做 AND”。需要判断旧状态时直接读取 And 的返回值，不要把 Load、普通位运算和 Store 拆成三个并发步骤。

先把业务状态安排到不同 bit

假设一个连接对象有“运行中、已就绪、故障”三个互相独立的标志。每个标志使用不同的 bit，组合值仍然是一个 uint64。要清除“故障”位，目标掩码是 1 ，真正传给 And 的掩码则是它的按位取反。

package main

import (
    "fmt"
    "sync/atomic"
)

const (
    flagRunning uint64 = 1 

这里的 state 是原子容器，三个常量只是对 bit 的命名。调用 clearFlag 后，运行中和已就绪仍保留，故障位被清零；返回值表示故障位在这次更新前是否为 1。图中的分组是数据关系说明，不表示某个运行时步骤。

为什么要用 ^flag，而不是直接传 flag

按位与的规则决定了传参方式：任何 bit 与 0 相与都会变成 0，与 1 相与才会保留。因此 state.And(flag) 会保留目标位、清掉其它位，方向和“清除一个标志”相反。^flag 只把目标位翻成 0，其余位置为 1，正好表达“只清目标位”。

例如当前状态是 111，目标位 010，反掩码就是 101，结果为 101。这个操作同时保护了其它状态位，不需要先拼出一个完整的新状态。

用 And 的返回值判断清除前状态

Uint64.And 的返回值是旧值，不是 AND 之后的新值。判断目标位是否原来存在时，应检查 old&flag != 0。这比先 Load 再 Store 更可靠：多个 goroutine 同时清除或更新不同状态位时，每次 And 都以一个原子读改写完成。

// clearIfSet 只报告目标位在原子清除前是否为 1。
func clearIfSet(state *atomic.Uint64, flag uint64) (wasSet bool) {
    // And 的旧值让“判断”和“清除”绑定在同一次原子更新中。
    old := state.And(^flag)
    return old&flag != 0
}

需要注意的是，返回旧值只能回答“这次 And 发生前目标位是什么”，不能替代完整业务事务。如果清位之后还要基于多个字段一起做条件更新，应考虑 CompareAndSwap，或把相关数据放在明确的互斥保护范围内。

初始化、复制与版本边界

atomic.Uint64 的零值是 0，可以直接声明使用；但它在第一次使用后不能再复制，结构体应通过指针传递，容器也不要按值返回。所有并发访问都应统一使用 Load、Store、Or、And 或 Swap，不要让一部分 goroutine 直接读内部普通整数。

Uint64.And 和同组的 Or 是 Go 1.23 加入的方法。如果项目还要兼容更早的工具链，应先确认版本，并采用项目允许的兼容实现；不要因为方法名存在于本地编辑器中就假定所有构建环境都支持它。

And、Or、Swap 和 CAS 怎么选

对单个 bit 的置位和清位，Or、And 语义最直接。对“只有在状态仍为 A 时才能改成 B”这类条件，则应使用 CAS 循环或锁，不要把一次 Load 后的判断当成保护。

常见问题

And 返回的是清除后的值吗？

不是。它返回更新前的旧值；清除后的值需要再次 Load，或由调用方根据业务继续读取。

为什么不直接用普通 uint64 做位运算？

多个 goroutine 同时读写普通整数会产生数据竞争。若状态确实跨 goroutine 共享，应让读改写都经过原子 API，或者使用互斥锁统一保护。