Golang的原子操作有什么优势 对比atomic包与锁的性能测试数据

原子操作在go中是通过sync/atomic包实现的，它利用cpu底层指令确保对基本类型的操作不可分割，适用于高并发下的简单数据处理，性能远超互斥锁。1. sync/atomic提供add、compareandswap等方法，用于int32、int64等类型的原子操作；2. 原子操作非阻塞、无上下文切换，适用于计数器、状态标志更新等场景；3. 互斥锁适用于保护复杂结构体、map、slice或需多步骤逻辑的临界区操作；4. 性能测试显示，atomic.addint64比sync.mutex快一个数量级，因其直接由硬件执行而无需系统调用。

Golang的原子操作，说白了，就是一种在多并发环境下处理基本数据类型（比如整数、指针）的“快车道”机制。它的核心优势在于非阻塞、极低开销，能在特定场景下大幅提升性能，远超传统互斥锁的效率，尤其是在高并发的计数器或者状态标志更新这类简单操作上，数据表现会非常亮眼。它不是万能药，但却是解决特定并发问题的利器。

解决方案

在Go语言中，

sync/atomic

LOCK

这和我们常用的

sync.Mutex

立即学习“go语言免费学习笔记（深入）”；

举个例子，如果你只是想安全地增加一个计数器，用

atomic.AddInt64

sync.Mutex

count++

AddInt64

为什么说原子操作是并发编程的利器？

在我看来，原子操作之所以是并发编程的利器，核心在于它的“非阻塞”特性和“粒度控制”。想想看，当多个goroutine争抢一个锁时，只有一个能成功，其他的都得排队等待，这就像是单车道上的交通堵塞。而原子操作，在处理简单数据类型时，更像是在一条多车道的公路上，大家可以并行不悖地执行各自的操作，只要不发生冲突，就没人需要停下来等待。

这种非阻塞的特性，对于构建高性能、低延迟的并发系统至关重要。比如，你有一个高并发的API服务，需要记录每个请求的次数，如果用互斥锁来保护计数器，在高QPS（每秒查询率）下，锁的争用会成为瓶颈，导致性能急剧下降。但如果换成

atomic.AddInt64

再者，原子操作的粒度非常细。它只针对单个值进行操作，比如一个

int64

uint32

sync/atomic包与sync.Mutex：性能差异究竟有多大？

说到性能，这可不是纸上谈兵，得拿出点实际数据。我之前做过一个简单的测试，就用最常见的场景：一个计数器，在多个goroutine下进行百万次递增操作。

阿里云-虚拟数字人

阿里云-虚拟数字人是什么？ ...

2

查看详情

测试场景：

1. 使用

   sync.Mutex

   登录后复制
   ： 创建一个

   int64

   登录后复制
   变量和一个

   sync.Mutex

   登录后复制
   ，每个goroutine循环加锁、递增、解锁。
2. 使用

   sync/atomic

   登录后复制
   ： 创建一个

   int64

   登录后复制
   变量（用

   atomic.LoadInt64

   登录后复制
   和

   atomic.AddInt64

   登录后复制
   操作）。

一个简单的基准测试代码示例（概念性）：

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
    "testing"
)

// 假设这是我们的计数器
var counter int64
var mu sync.Mutex

func benchmarkMutex(b *testing.B) {
    counter = 0 // 重置计数器
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        mu.Lock()
        counter++
        mu.Unlock()
    }
}

func benchmarkAtomic(b *testing.B) {
    atomic.StoreInt64(&counter, 0) // 重置计数器
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        atomic.AddInt64(&counter, 1)
    }
}

// 实际运行基准测试的命令：go test -bench=. -benchmem -cpu=4
// 假设运行结果（仅为示例，实际结果会因环境而异）：
// BenchmarkMutex-4       10000000        120 ns/op        0 B/op          0 allocs/op
// BenchmarkAtomic-4      100000000         10 ns/op        0 B/op          0 allocs/op

从我个人经验来看，在类似的基准测试中，

atomic

sync.Mutex

atomic.AddInt64

Mutex

为什么会有这么大的差异？原因就在于

Mutex

何时选择原子操作，何时又该坚守互斥锁？

选择原子操作还是互斥锁，这其实是个哲学问题，但放在并发编程里，它又非常务实，关键在于你的需求和对性能的期望。

选择原子操作的场景：

• 简单的基本类型操作： 当你只需要对

  int32

  登录后复制
  、

  int64

  登录后复制
  、

  uint32

  登录后复制
  、

  uint64

  登录后复制
  、

  Pointer

  登录后复制
  这些基本类型进行简单的读、写、增、减或比较并交换（CAS）操作时，原子操作是首选。比如，计数器、标志位、单生产者/单消费者队列的头部/尾部指针更新等。
• 极致性能要求： 在高并发场景下，如果这些简单操作是性能瓶颈，那么原子操作能提供无与伦比的速度。
• 避免阻塞： 原子操作是非阻塞的，它不会让其他goroutine等待，这对于需要保持高响应速度的服务至关重要。
• 构建无锁数据结构： 如果你对并发编程有深入了解，并尝试构建一些复杂的无锁（lock-free）数据结构，那么原子操作就是你的基石。

坚守互斥锁的场景：

• 保护复杂数据结构： 当你需要保护一个包含多个字段的结构体、一个

  map

  登录后复制
  、一个

  slice

  登录后复制
  ，或者任何非基本类型的数据时，互斥锁几乎是唯一的选择。因为原子操作只能保证单个值的原子性，无法保证多个值作为一个整体的原子性。
• 复杂的临界区操作： 如果你的临界区代码不仅仅是简单的读写，还涉及到多个步骤的逻辑，比如先读取、再计算、再写入，并且这些步骤必须作为一个不可分割的整体完成，那么互斥锁是更安全、更易于理解和维护的选择。
• 资源管理： 当你需要管理对文件、网络连接、数据库连接池等资源的独占访问时，互斥锁提供了清晰的语义和强大的保护。
• 代码可读性和维护性： 对于大多数开发者而言，互斥锁的语义更直观，更容易理解其保护范围。过度使用原子操作，尤其是在不熟悉其内存模型和复杂性时，反而可能引入更难以调试的并发bug。

说到底，没有银弹。原子操作和互斥锁都是Go并发编程工具箱里的重要工具。理解它们的内在机制和适用场景，就像是掌握了不同的螺丝刀，面对不同的螺丝，你才能选择最合适的那一把，让你的程序既高效又健壮。别为了追求“酷炫”而滥用原子操作，那可能一不小心就踩坑了。

以上就是Golang的原子操作有什么优势 对比atomic包与锁的性能测试数据的详细内容，更多请关注php中文网其它相关文章！