Go atomic.Int32 怎样用 CompareAndSwap 管理有限状态

如果一个任务只有“空闲、运行中、已完成、已失败”几种状态，直接给共享变量赋值很容易把合法迁移和并发覆盖混在一起。atomic.Int32 可以保存一个原子读取的 int32，但真正决定状态能否前进的是 CompareAndSwap：只有当前值仍然等于 expected，才会写入 next；返回 false 时，不能把它当成“写入失败后再强行覆盖”。

先把状态编号与转移条件固定下来

有限状态的第一步不是写 CAS，而是把状态域写清楚。下面的例子约定 0 表示空闲，1 表示运行中，2 表示完成，3 表示失败；任务只能从空闲进入运行中，再从运行中进入完成或失败。

package main

import "sync/atomic"

const (
	stateIdle int32 = iota // 0：任务尚未领取
	stateRunning           // 1：任务已经被一个执行者领取
	stateDone              // 2：任务正常结束
	stateFailed            // 3：任务结束但结果失败
)

type Task struct {
	state atomic.Int32 // 零值就是 Idle，首次使用后不能复制 Task
}

func (t *Task) Start() bool {
	// 只有仍处于 Idle 的任务才允许被当前执行者领取。
	return t.state.CompareAndSwap(stateIdle, stateRunning)
}

Start 返回 true，说明这次调用完成了唯一的状态领取；返回 false，说明任务已经被其他调用者推进，当前调用者不应继续执行同一份任务。这里的原子性只覆盖 state 这个字段，并不会自动保护任务结构体中的其他字段。

CompareAndSwap 的关键是当前值仍是旧状态

CompareAndSwap(old, new) 同时完成比较和条件写入。假设两个 goroutine 都读取到 Running，其中一个先把它改成 Done，另一个随后用 Running 作为 expected 去 CAS，就会得到 false，而不会把已经完成的任务改回运行中。

func (t *Task) Finish() bool {
	for {
		current := t.state.Load() // 先读取当前状态，避免凭旧快照写回
		if current != stateRunning {
			return false // 只有 Running 才能结束，其他状态不重复处理
		}
		if t.state.CompareAndSwap(current, stateDone) {
			return true // expected 仍匹配，状态迁移成功
		}
		// CAS 失败说明并发方先改了状态，回到循环重新观察。
	}
}

循环不是为了“保证最终成功”，而是给短暂竞争留出一次重新判断的机会。如果新状态已经是 Done 或 Failed，下一轮会直接返回；这比无条件重试更重要，因为状态机必须尊重业务终态。

CAS 失败时怎样决定重试还是拒绝

可以把返回值按下面的方式解释：

不要把 CAS 失败改写成 Store(next)。Store 会绕过“我看到的旧状态是否仍然有效”这个条件，可能让失败请求覆盖成功请求的结果。若一次迁移还要同时修改多个字段，应该把完整快照放在合适的同步协议中，不能把 atomic.Int32 当成事务锁。

常见问题

atomic.Int32 的零值能直接使用吗？

可以，零值是 0，正好可以对应初始化状态。但要在代码中明确 0 的业务含义，避免把“未初始化”和“空闲”混成两个状态。

为什么不能复制已经使用过的 atomic.Int32？

官方文档明确要求 Int32 首次使用后不能复制。把包含它的结构体按值传递、赋值或放入会复制元素的容器，都可能破坏原子状态的唯一归属。

CompareAndSwap 能保护多个字段的一致性吗？

不能。它只对一个 Int32 的比较和写入提供原子性；多个字段要么改成不可变快照后整体替换，要么使用互斥锁或其他明确的组合协议。

把状态编号、允许迁移和 CAS 失败策略先写成表，再落到 Load、CompareAndSwap 和终态判断，通常就能避免并发状态被旧请求覆盖。最后再检查结构体是否可能复制，以及状态之外的字段是否需要另一层同步。