如何在Golang中实现并发环境下的计数器 Go语言Atomic与Mutex性能对比

go 并发计数器该用 atomic.Addint64 还是 sync.Mutex

绝大多数场景下，优先用 atomic.AddInt64 —— 它快、轻量、无锁，且能正确保证计数器的原子性。只有当你需要「复合操作」（比如“读+判+写”）或计数器只是更大临界区的一部分时，才考虑 sync.Mutex。

哪些操作不能靠 atomic 完成，必须上 Mutex

atomic 只保证单个操作的原子性，不提供「多步逻辑的原子封装」。一旦涉及条件判断或依赖当前值做决策，atomic 就力不从心了。

• 「如果计数器小于 100 才加 1」—— atomic.LoadInt64 + atomic.AddInt64 中间可能被其他 goroutine 修改，结果不可靠
• 「加 1 后立刻记录日志并触发回调」—— 日志和回调不在原子范围内，atomic 无法保护
• 多个变量需同步更新（如 count 和 lastUpdated）—— atomic 无法跨变量协调

atomic 计数器的典型写法和易错点

别直接对变量做 ++ 或 +=；所有修改必须走 atomic 函数，且类型严格匹配（int64 是默认安全类型，int 在 32 位系统上非原子）。

• 初始化必须用 int64 类型： var counter int64，不是 int
• 读取用 atomic.LoadInt64(&counter)，不是 counter 直接读（可能看到脏值）
• 自增用 atomic.AddInt64(&counter, 1)，别写 counter++（竞态！）
• 避免在循环里高频调用 atomic.LoadInt64 做轮询判断——可能掩盖设计问题，也影响性能

性能差多少？实测常见场景下的开销差异

在纯递增场景下，atomic.AddInt64 比 sync.Mutex 快 3–5 倍，内存占用更低，且不会因锁竞争导致 goroutine 阻塞。但这个差距只在高并发（数百 goroutine 以上）、高频（每秒百万次以上）计数时才明显。

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

• 低频计数（如每秒几百次）：两者感知不到差别，选哪个都行，但 atomic 更简洁
• 争抢激烈时：Mutex 会排队、休眠、唤醒，带来调度开销；atomic 是 CPU 级指令，无上下文切换
• 注意：atomic 不解决「可见性」以外的问题——比如你用 atomic 更新了计数，但没用 atomic 读，那读到的仍是旧值

真正容易被忽略的是：很多人以为用了 atomic 就万事大吉，结果在非原子路径上读写同一个变量，或者把 atomic 和普通赋值混用，反而埋下更隐蔽的竞态。