登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go教程

Go atomic.Uint64 CompareAndSwap 怎样实现条件更新

来源:17golang原创

时间:2026-10-28 17:41:20 423浏览 收藏

并发代码里经常会出现这样的判断:只有当计数器仍然是某个旧值时,才把它改成新值。用普通的 Load、条件判断和 Store 拆开写,看起来逻辑正确,但两个 goroutine 可能同时通过判断,后写入者覆盖前写入者。atomic.Uint64.CompareAndSwap 把“比较旧值”和“写入新值”放在同一个原子操作中,返回值为 true 才表示这次更新真正成功。

官方文档:https://pkg.go.dev/sync/atomic#Uint64.CompareAndSwap

需要条件更新一个 uint64 时,先读取当前值作为旧值,再调用 CompareAndSwap(old, new);返回 false 说明期间已有并发修改,不能把它当成成功,应该跳过、重新读取或按业务规则重试。

本文只围绕一个数值字段的条件更新展开,不把 CAS 当成多字段事务,也不把它替代所有锁和同步工具。

先看清楚:为什么 Load 加 Store 仍会丢更新

下面的写法把“检查”和“写入”分成两个时间点。假设两个 goroutine 都读到 10,它们都满足条件,最后写入的结果会覆盖另一个 goroutine 的更新。这里即使 Load 与 Store 各自是原子的,中间的判断仍不是原子的。

package main

import "sync/atomic"

func wrongUpdate(v *atomic.Uint64) {
	// Load 和 Store 各自安全,但二者之间的判断可能被并发修改插入。
	old := v.Load()
	if old == 10 {
		// 这次 Store 没有再次确认 old 仍然是当前值。
		v.Store(11)
	}
}

CAS 的区别是:它只在当前值仍等于 old 时写入 new,并把是否交换成功直接返回。另一个 goroutine 先改动了值时,当前调用会得到 false,不会悄悄覆盖对方的结果。

Go atomic Uint64 的 Load 判断与 CompareAndSwap 条件更新边界说明图
图1:结构说明图,比较 Load、条件判断、Store 与 CompareAndSwap 的原子边界;这是静态说明图,不是运行截图。

用 CompareAndSwap 完成一次条件更新

最小用法是先调用 Load 取得候选旧值,再把旧值和目标新值交给 CompareAndSwap。示例把“只允许从 10 变为 11”封装成一个函数,并用返回的布尔值区分成功与竞争失败。

package main

import "sync/atomic"

func moveFromTen(v *atomic.Uint64) bool {
	// 先读出候选旧值;这里只接受状态 10。
	old := v.Load()
	if old != 10 {
		return false
	}

	// 比较和写入绑定为一次原子条件更新。
	return v.CompareAndSwap(old, 11)
}

func setIfGreater(v *atomic.Uint64, candidate uint64) bool {
	for {
		// 每轮都重新读取,避免沿用已经失效的旧值。
		old := v.Load()
		if candidate 

moveFromTen 适合只尝试一次的状态迁移;setIfGreater 展示了带重试的上限更新。重试不是无条件死循环:每轮都要重新读取、重新判断退出条件,并确认业务允许在高竞争下继续尝试。

如何处理 false:失败不是异常,而是并发信号

CompareAndSwap 返回 false 时,常见原因是读取旧值后,另一个 goroutine 先完成了更新。此时不要直接再次使用原来的 old,因为它已经不是当前观察值。根据业务目标,可以采取三种策略:

  • 状态迁移只允许一次:返回“未抢到”或跳过本次任务。
  • 目标是写入更大值:重新 Load,判断候选值是否仍然满足条件,再重试。
  • 连续失败有成本:设置最大重试次数或退避,避免热点变量让 goroutine 长时间自旋。

CAS 只保护这个 Uint64 的比较与交换。如果更新同时要求修改结构体里的其他字段,不能因为其中一个字段用了 CAS 就声称整个对象是一致的;这类事务性约束通常需要重新设计状态编码,或使用互斥锁等更高层同步方式。

Go atomic Uint64 CompareAndSwap 成功失败返回值与重试边界说明图
图2:关系说明图,展示旧值、候选新值、竞争修改与 swapped 返回值之间的静态关系;这是原创说明图,不是运行结果截图。

零值、类型和使用边界

atomic.Uint64 的零值可以直接使用,初始值就是 0。但原子类型不能在第一次使用后复制;应把它作为结构体字段的长期状态,并通过指针或稳定对象访问。官方文档还强调,原子操作适合低层同步算法,普通业务同步优先评估 channel 或 sync 包中的设施。

工程上可以用下面的速查表做决定:

目标适合做法注意点
只有值等于旧值才更新CompareAndSwap(old, new)必须检查返回值
只做无条件累加Add不要为简单累加手写 CAS 循环
多个字段必须一起改变重新设计状态或使用锁单个 Uint64 CAS 不提供对象级事务
竞争很激烈且重试成本高限制重试或采用更高层同步避免无限自旋

相关问题

CompareAndSwap 成功后还要 Store 吗? 不需要。成功返回 true 就表示 new 已经写入;再次 Store 反而可能覆盖后续更新。

CAS 返回 false 是否代表程序出错? 不一定。它首先表示旧值不再匹配,是否记录日志、重试或跳过取决于业务语义。

记住一个边界即可:CAS 解决的是“一个原子值的条件交换”,不是自动解决所有共享状态的一致性。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>