sync/atomic通过CPU指令提供整数和指针类型的原子操作，如Add、CompareAndSwap、Load、Store、Swap及Value类型，实现无锁并发安全，适用于计数器、标志位、配置更新等简单场景，性能优于sync.Mutex；而sync.Mutex适用于保护复杂数据结构或临界区含耗时操作的场景，两者选择需权衡操作复杂度与性能需求。
Golang的
sync/atomic
包提供了一系列底层的、由CPU指令支持的原子操作，主要针对基本数据类型，如整数和指针。这些操作允许在不使用传统互斥锁（
sync.Mutex
）的情况下，对共享变量进行并发安全的读写、增减或比较并交换，从而有效减少锁竞争，提升高并发场景下的性能。
解决方案
sync/atomic
包提供了以下主要的原子操作，它们都以
atomic.
为前缀：
AddInt32
/
AddInt64
/
AddUint32
/
AddUint64
: 原子性地将一个值加到现有变量上，并返回新值。
var counter int64atomic.AddInt64(&counter, 1) // counter现在是1
CompareAndSwapInt32
/
CompareAndSwapInt64
/
CompareAndSwapUint32
/
CompareAndSwapUint64
/
CompareAndSwapPointer
: 比较并交换（CAS）操作。如果变量的当前值等于期望值，则原子性地将其更新为新值，并返回
true
；否则不进行任何操作并返回
false
。这是许多无锁算法的基石。
var value int32 = 10// 如果value当前是10，就把它设置为20swapped := atomic.CompareAndSwapInt32(&value, 10, 20) // swapped为true, value为20// 如果value当前是10（现在是20了），就把它设置为30swapped = atomic.CompareAndSwapInt32(&value, 10, 30) // swapped为false, value仍为20
LoadInt32
/
LoadInt64
/
LoadUint32
/
LoadUint64
/
LoadPointer
/
LoadValue
: 原子性地读取变量的当前值。这确保了即使在并发写入时，也能获取到最新的、完整的变量状态，避免了部分写入的问题。
var config atomic.Valueconfig.Store("initial_config")loadedConfig := config.Load().(string) // loadedConfig为"initial_config"
StoreInt32
/
StoreInt64
/
StoreUint32
/
StoreUint64
/
StorePointer
/
StoreValue
: 原子性地将一个新值写入变量。与
Load
类似，它确保写入操作的完整性。
var status int32atomic.StoreInt32(&status, 1) // status现在是1
SwapInt32
/
SwapInt64
/
SwapUint32
/
SwapUint64
/
SwapPointer
: 原子性地将变量设置为新值，并返回变量的旧值。
var oldVal int64 = 5// 将oldVal设置为10，并返回它原来的值5previous := atomic.SwapInt64(&oldVal, 10) // previous为5, oldVal为10
Value
类型:
atomic.Value
是一个特殊的原子操作，它可以存储任意类型的接口值，并提供
Load()
和
Store()
方法进行原子性的读写。它常用于存储配置或不可变的数据结构，避免在更新时锁定整个结构。
为什么选择
sync/atomic
sync/atomic
而非
sync.Mutex
来处理并发？
这问题问得好，因为很多时候我们写并发代码，第一反应就是上锁。但实际上，
sync/atomic
和
sync.Mutex
解决的是不同粒度、不同场景下的并发问题。
sync.Mutex
是一种悲观锁，它假设多个协程会同时访问共享资源并产生冲突，因此在访问前就将资源锁住，确保同一时间只有一个协程能操作。这就像你进图书馆借书，为了避免别人拿走你要的书，你直接把整个书架都锁起来，等你自己拿完再解锁。这种方式简单、安全，适用于保护复杂的共享数据结构，或者涉及多个操作步骤需要原子性完成的场景。
立即学习“go语言免费学习笔记（深入）”；
而
sync/atomic
则是一种乐观锁的思路。它不锁住资源，而是尝试直接对共享变量进行操作。如果操作成功（即在操作期间没有其他协程修改该变量），那就完成了；如果失败（说明有其他协程抢先修改了），它会重试。这就像你借书，你直接去拿，如果书还在就拿走，如果不在了就再去看看有没有别的书。这种方式通常由CPU的特定指令（如CAS指令）支持，避免了操作系统层面的上下文切换，因此对于简单的数值或指针操作，它的性能开销远低于互斥锁。
我个人经验来看，当你只是想对一个计数器进行增减，或者更新一个配置指针，却用了
sync.Mutex
，那往往是“杀鸡用牛刀”了。互斥锁引入的开销，尤其是在高并发竞争激烈时，会非常显著。
sync/atomic
在这些场景下，不仅能提供更好的性能，代码也可能更简洁。但反过来，如果你的操作涉及多个字段的更新，或者需要维护复杂的数据结构一致性，那
sync.Mutex
的安全性就显得不可替代了。选择哪个，真的要看具体需求和场景。
CompareAndSwap
CompareAndSwap
（CAS）操作在
sync/atomic
中扮演什么核心角色？
CompareAndSwap
（CAS），或者说比较并交换，绝对是
sync/atomic
包乃至整个现代并发编程中的一个核心概念。它不是简单地设置一个值，而是先检查一个条件（当前值是否等于期望值），如果条件满足，才执行更新操作。这个“检查-更新”的整个过程是原子性的，不可中断。
你可以把它想象成一个守门员，你告诉他：“如果现在是A状态，就把门打开到B状态。”守门员会迅速检查，如果确实是A，他会立即打开到B，并告诉你“搞定！”。如果他发现已经不是A了（比如别人在他检查前已经改成了C），他会告诉你“不行，状态不对！”。
CAS的强大之处在于，它允许我们构建无锁（lock-free）或免锁（wait-free）的数据结构和算法。传统的锁机制，比如
sync.Mutex
，在竞争激烈时，会频繁地导致协程阻塞和唤醒，带来上下文切换的开销。而基于CAS的算法，协程在发现冲突时，不会被阻塞，而是选择重试，这在某些场景下能提供更高的吞吐量和更低的延迟。
举个例子，一个简单的原子计数器就可以用CAS来实现，尽管
atomic.AddInt64
更直接。但更复杂的，比如实现一个无锁的栈（stack）或队列（queue），CAS就是不可或缺的。你需要用CAS来更新栈顶指针或队列的头尾指针，确保在多协程同时出入栈/队时，数据结构依然保持一致性。
当然，CAS也不是万能药。它可能会导致“ABA”问题（如果一个值从A变为B，又变回A，CAS会误以为没有发生变化），虽然在Go的标准库中，对于基本类型这通常不是大问题，但在构建复杂无锁结构时需要考虑。此外，频繁的CAS失败重试也可能导致“忙等”（busy-waiting），消耗CPU资源。但无论如何，理解CAS是深入理解现代并发编程的关键一步。
在实际项目中，何时优先考虑使用
sync/atomic
sync/atomic
而不是
sync.Mutex
？
在实际开发中，选择
sync/atomic
还是
sync.Mutex
，这其实是一个权衡和取舍的问题，没有绝对的答案，但有一些清晰的指导原则。
我通常会优先考虑
sync/atomic
的场景：
简单的计数器或标志位：这是最典型的应用场景。比如统计请求数量、并发任务数、或者一个布尔型的开关状态。使用
atomic.AddInt64
或
atomic.StoreInt32
来更新，比加锁解锁效率高得多。
var requestCount int64// 每次处理请求atomic.AddInt64(&requestCount, 1)
单个指针的原子性更新：当需要原子性地更换一个指向不可变数据结构的指针时，
atomic.Pointer
或
atomic.Value
非常有用。例如，更新一个全局配置对象，你可以创建一个新的配置对象，然后原子性地替换旧的指针，这样读取方总能看到一个完整的、一致的配置版本，而不需要加锁。
type Config struct { // ... 配置字段}var currentConfig atomic.Value // 存储 *Config// 初始化currentConfig.Store(&Config{/* ... */})// 更新配置newConfig := &Config{/* ... */}currentConfig.Store(newConfig)// 读取配置cfg := currentConfig.Load().(*Config)
性能敏感的临界区：如果你的代码段非常短，只涉及对一个基本类型变量的读写，并且这个代码段是系统性能瓶颈之一，那么
sync/atomic
可以显著降低开销。比如，在一个高并发的缓存系统中，更新缓存命中率的统计。构建无锁数据结构的基础：如果你正在尝试实现一些高级的无锁数据结构（如无锁队列、无锁哈希表），那么CAS操作（
CompareAndSwap
）是构建这些结构的基础。但这通常是高级且复杂的任务，需要对并发模型有深刻理解。
反之，我会倾向于使用
sync.Mutex
的场景：
复杂数据结构的操作：当你需要保护
map
、
slice
、包含多个字段的结构体，或者需要执行一系列操作（比如先检查、再修改、再记录日志）作为一个整体原子性完成时，
sync.Mutex
是更安全、更易于理解和维护的选择。
atomic
操作只能针对单个变量。临界区包含I/O或耗时操作：如果你的临界区中包含了文件I/O、网络请求或者其他可能长时间阻塞的操作，那么使用
sync.Mutex
是合适的。因为这些操作的耗时远超锁本身的开销，而且
atomic
的忙等重试在这种情况下会浪费大量CPU周期。代码可读性和维护性优先：对于大多数业务场景，
sync.Mutex
的代码逻辑更直观，出错的概率也相对较低。
atomic
虽然性能好，但它的语义更底层，如果使用不当，很容易引入难以调试的并发bug。
总结来说，
sync/atomic
是针对简单、单值操作的“快车道”，适用于对性能有极致要求的特定场景。而
sync.Mutex
则是“安全通道”，适用于大多数需要保证数据一致性的复杂场景。在做选择时，我的建议是：先考虑
sync.Mutex
，如果分析后发现它确实是性能瓶颈，并且操作足够简单，才转向
sync/atomic
。 过早优化往往是万恶之源。
以上就是Golang的sync/atomic包提供了哪些原子操作以避免锁竞争的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1405302.html
微信扫一扫 
支付宝扫一扫 
