17370845950

不能直接用 int 类型做并发计数，因为 i++ 非原子，包含读取、加1、写回三步，多 goroutine 竞争会导致丢失更新；sync/atomic 提供 Add、Load、Store、CAS 等位宽明确的原子操作，Go 1.19+ 推荐使用 atomic.Int64 封装安全计数器。

为什么不能直接用 int 类型做并发计数

多个 goroutine 同时对一个普通 int 变量执行 ++ 或 --，结果大概率出错。因为 i++ 实际包含三步：读取、加 1、写回，中间可能被其他 goroutine 插入修改，导致丢失更新。这不是“偶尔出错”，而是只要并发足够高，就一定会复现。

sync/atomic 提供哪些原子操作函数

sync/atomic 对 int32、int64、uint32、uint64、uintptr 和指针类型提供原子读写与运算。最常用的是：

• atomic.AddInt32(&i, 1) —— 原子加，返回新值
• atomic.LoadInt32(&i) —— 原

  

  子读，避免编译器/CPU 重排序
• atomic.StoreInt32(&i, 10) —— 原子写
• atomic.CompareAndSwapInt32(&i, old, new) —— CAS，成功返回 true

注意：没有 atomic.AddInt，必须显式指定位宽（int32 或 int64），否则编译报错。

完整可运行的并发安全计数器示例

下面是一个基于 atomic.Int64（Go 1.19+ 推荐）的计数器封装，比裸用 atomic.AddInt64 更安全、更易复用：

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

package main

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

type Counter struct {
    v atomic.Int64
}

func (c *Counter) Inc() int64 {
    return c.v.Add(1)
}

func (c *Counter) Load() int64 {
    return c.v.Load()
}

func main() {
    var wg sync.WaitGroup
    var counter Counter

    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for j := 0; j < 1000; j++ {
                counter.Inc()
            }
        }()
    }

    wg.Wait()
    fmt.Println("Final count:", counter.Load()) // 总是输出 100000
}

如果你还在用 Go atomic.AddInt64(&v, 1) 替代 c.v.Add(1)，原理相同，只是 API 更底层。

容易踩的坑和性能提示

原子操作不是万能锁替代品，用错反而引入隐蔽 bug：

• 别对局部变量或栈上变量取地址传给 atomic 函数——地址无效，行为未定义
• atomic.Load* 和 atomic.Store* 是内存屏障，但不保证临界区逻辑原子性（比如“先读再算再写”仍需锁）
• 频繁调用 atomic.LoadInt64 本身开销极小，但若在 tight loop 中反复读同一变量，现代 CPU 通常会缓存该 cacheline，实际性能影响不大
• 如果计数器需要支持 reset、min/max 比较等复杂逻辑，atomic 不够用，应考虑 sync.Mutex 封装

真正要注意的，是位宽匹配和变量生命周期——这两点出错，程序不会 panic，但结果不可预测。