Go并发计数器实现：Atomic与Mutex对比分析

在Go并发编程中，计数器的正确实现关乎性能与可靠性：atomic.AddInt64凭借无锁、轻量、高吞吐的优势，是绝大多数场景下的首选；而sync.Mutex仅在需保障多步逻辑原子性（如条件判断、跨变量协同或副作用操作）时才不可替代——但真正容易踩坑的，不是选错工具，而是误以为用了atomic就高枕无忧，结果混用普通读写、忽略类型安全或绕过原子操作，反而引入更隐蔽的竞态问题。

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 以上）、高频（每秒百万次以上）计数时才明显。

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

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

今天关于《Go并发计数器实现：Atomic与Mutex对比分析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！