Go sync.Map.CompareAndSwap 怎样原子替换旧值

在多个 goroutine 共享一个状态值时，最容易出错的写法是先 Load，再无条件 Store。读取和写入之间如果有另一个 goroutine 修改了同一个 key，后一次 Store 可能把较新的结果覆盖掉。Go 1.20 为 sync.Map 增加了 CompareAndSwap，可以把“只有旧值仍然是我刚刚看到的值，才替换成新值”交给一次原子操作完成。

官方文档：https://pkg.go.dev/sync#Map.CompareAndSwap

它的核心形式是 m.CompareAndSwap(key, old, new)：返回 true 表示当前值等于 old 并已换成 new；返回 false 表示没有完成替换。下面只围绕这个条件更新动作展开。

CompareAndSwap 解决的是哪种替换问题

sync.Map 适合多个 goroutine 并发访问共享键值。直接调用 Store 是无条件写入，而 CompareAndSwap 多了一层保护：写入者必须证明自己看到的旧值还没有被别人改掉。

例如，某个 key 当前保存的是整数 10。调用 CompareAndSwap("quota", 10, 9) 时，只有当前值仍然是 10，才会变为 9。如果另一个 goroutine 已经把它改成 8，这次调用就返回 false，不会把 8 覆盖回 9。

用最小示例完成一次条件更新

先把初始状态放入 sync.Map，然后用旧值 10 作为更新条件。这个例子中的 int 是可比较类型，适合直接作为 old 参与比较。

package main

import (
	"fmt"
	"sync"
)

func main() {
	var states sync.Map
	states.Store("quota", 10) // 先保存一个可比较的旧状态

	swapped := states.CompareAndSwap("quota", 10, 9) // 只有当前值仍为 10 才替换
	value, loaded := states.Load("quota")

	fmt.Println(swapped, value, loaded) // true 9 true
}

这里的 swapped 才是条件写入的判断依据，Load 只是用于读取最终状态。不要忽略返回值，也不要把 CompareAndSwap 当成无条件的 Store 来使用。

并发下为什么要根据 false 重新读取

在实际代码中，新的值通常由当前值计算出来，例如把计数减一。此时要先读取，再尝试 CAS。如果 CAS 失败，说明读取到的旧值已经过期，应重新读取并重新计算，而不是直接调用 Store 抢写。

func decrement(states *sync.Map, key string) bool {
	for {
		value, ok := states.Load(key)
		if !ok {
			return false // key 不存在时不创建新状态
		}

		current, ok := value.(int)
		if !ok || current 

这个循环的关键不是“失败就多试几次”，而是每次失败后都重新取得当前值。若业务不能无限重试，还应增加重试次数、上下文取消或退避策略；文章中的示例只展示条件更新本身。

返回 false 时要区分哪些边界

一次 CAS 返回 false，最常见的含义是当前值与 old 不相等，也可能是 key 根本不存在。它不是一个“自动插入”的操作：如果 key 没有值，拿 nil 去比较也不能凭空创建条目。

另外，官方文档要求 old 是可比较类型。字符串、整数、指针以及字段可比较的结构体通常可以直接比较；切片、映射和包含不可比较字段的结构体不能作为相等比较条件。若业务状态本身不可比较，可以把它包装成可比较的版本号、指针或其他稳定标识，再围绕那个标识做 CAS。

不要把 Load 加 Store 当成同一种操作

下面两段代码的意图不同：

如果写成 value, _ := states.Load(key)，再根据 value 计算结果并调用 states.Store(key, next)，中间的判断和写入就不是同一个条件操作。并发更新场景应优先使用 CAS；无条件覆盖才使用 Store 或 Swap。

使用前的四项检查

• 确认当前项目的 Go 版本支持 CompareAndSwap；该方法从 Go 1.20 开始提供。
• 确认 key 已经存在，或者业务确实允许 CAS 失败后走单独的初始化分支。
• 让 old 与实际存入的动态类型一致，不要用看起来相同但类型不同的值比较。
• 对 CAS 失败设计重试、放弃或冲突提示，不要失败后无条件 Store。

可以把 CompareAndSwap 理解为“带版本条件的单次替换”。它适合保护小而明确的共享状态；如果更新动作同时要维护多个字段、多个 key 或其他业务不变量，应该重新评估是否由一把互斥锁统一保护，而不是把复杂事务拆成多次 CAS。

相关问题

CompareAndSwap 会在 key 不存在时插入吗？

不会。它只尝试替换已有 key 的当前值；初始化可以单独使用 LoadOrStore，再根据业务决定是否进入 CAS 更新。

new 也必须是可比较类型吗？

官方签名明确要求 old 可比较，因为它要参与相等判断。为了让后续 CAS 仍然可用，实际状态通常也应选用稳定、可比较的表示，避免把不可比较值作为下一次比较条件。

CompareAndSwap 能替代所有互斥锁吗？

不能。它只对一个 key 的一次替换提供条件更新语义；需要同时修改多个共享对象或维护跨字段不变量时，互斥锁往往更直接。