Golang单例模式实现全局计数器的并发瓶颈分析

sync.once不能用于计数器更新，因其仅保证初始化函数执行一次，不提供原子读写能力；counter++需独立同步机制，否则并发下值异常。

为什么 sync.Once 不能直接用于计数器更新

因为 sync.Once.Do 只保证初始化函数执行一次，不提供原子读写能力。把它套在 counter++ 外面，看似“只跑一次”，实际每次调用仍会进入临界区竞争，反而掩盖了真正的并发问题。

• 常见错误现象：counter 值远低于预期，尤其在高并发压测下跳变明显
• 本质原因：计数操作（读-改-写）不是原子的，即使初始化用了 sync.Once，后续递增仍需独立同步机制
• 正确思路：单例负责实例创建，计数逻辑必须另配原子操作或互斥锁

sync/atomic 做计数器比 sync.Mutex 快在哪

底层直接映射到 CPU 的 LOCK XADD 等指令，无 goroutine 调度开销；而 sync.Mutex 在争抢激烈时可能触发休眠唤醒，延迟不可控。

• 适用场景：仅需整型增减、比较交换等简单操作，比如请求计数、开关状态位
• 参数差异：atomic.AddInt64(&counter, 1) 要求变量地址是 *int64，不能传值或接口类型
• 兼容性注意：32 位系统上 int64 非原子，必须用 atomic.Int64 类型（go 1.19+）或确保 64 位对齐

全局单例 + 原子计数的标准结构长什么样

单例本身应惰性初始化、线程安全，内部字段用 atomic.Int64 或原始类型配合 atomic 函数，避免暴露可变字段。

• 不要这样写：var Counter = &CounterStruct{val: 0} —— 包级变量初始化无同步保障
• 推荐结构：

var instance *Counter var once sync.Once  func GetCounter() *Counter {     once.Do(func() {         instance = &Counter{val: atomic.Int64{}}     })     return instance }  type Counter struct {     val atomic.Int64 }  func (c *Counter) Inc() int64 {     return c.val.Add(1) }

• 容易踩的坑：把 atomic.Int64 字段设为 public，外部直接调 c.val.Store() —— 破坏封装，且绕过业务逻辑校验

什么时候非得换 sync.Mutex 不可

当计数逻辑耦合条件判断、多字段联动或需要精确控制临界区范围时，atomic 就不够用了。比如“每 100 次请求触发一次日志”，涉及读取、判断、重置三步，无法用单个原子操作表达。

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

• 典型错误：用 atomic.LoadInt64 读值后做 if 判断，再用 atomic.StoreInt64 写回 —— 中间窗口期被其他 goroutine 修改，导致逻辑错乱
• 此时必须用 mutex.Lock()/Unlock() 包住整个复合操作
• 性能提示：若该分支极少触发（如万分之一），用 atomic.Load 先快速路径检查，命中后再加锁，能显著降低锁竞争

真正难的不是选原子还是锁，而是厘清“哪些操作必须视为一个不可分割单元”——这个边界一旦画错，再多的同步原语也救不回来。