Go语言Sync.Once用法与源码解析

sync.Once 是 Go 语言中实现“只执行一次”逻辑的唯一可靠方案，它通过原子操作（atomic.CompareAndSwapUint32）与互斥锁（sync.Mutex）的精妙协同，在保证强一致性的同时避免竞态——无论多少 goroutine 并发调用 Do，目标函数仅执行一次，其余调用者自动阻塞等待完成，且全程无忙等、低开销、零版本兼容风险；但需警惕常见陷阱：Do 必须传入无参无返回的函数字面量（闭包需注意变量捕获），不可重置、不传播 panic、无超时机制，正确使用它能安全高效地支撑全局配置加载、单例初始化等关键场景。

为什么 sync.Once 是唯一靠谱的“只执行一次”方案

手动加锁 + 布尔标记看似能实现，但极易漏掉竞态：两个 goroutine 同时读到 done == false，都进临界区。而 sync.Once 底层用原子操作 + 互斥锁双重保障，确保无论多少 goroutine 并发调用 Do，函数最多执行一次，且所有调用者都会等到它完成（哪怕自己没触发执行）。

常见错误现象：sync.Once 的 Do 参数必须是 func()，传入带参数或返回值的函数会编译报错；误以为 Once 能重置（它不能，一旦执行过，后续调用直接返回）。

• 使用场景：全局配置加载、单例初始化、信号处理注册、DB 连接池首次建立
• 性能影响极小：未执行前只是原子读，执行后变成普通内存读；比手写锁更轻量
• 兼容性无风险：自 Go 1.0 起稳定存在，无版本差异

sync.Once.Do 的参数陷阱和正确写法

你不能直接把带参函数塞进去，比如 once.Do(loadConfig("prod")) —— 这会立刻执行 loadConfig，且结果被忽略（因为返回值不匹配 func() 类型）。必须传一个闭包或无参函数字面量。

正确做法是把逻辑包在匿名函数里，参数通过闭包捕获：

once.Do(func() {
    loadConfig("prod")
})

如果需要捕获变量，注意闭包变量生命周期。别这么写：

for _, env := range []string{"dev", "prod"} {
    once.Do(func() { loadConfig(env) }) // ❌ env 总是最后一个值
}

应该显式传参或复制变量：

env := env
once.Do(func() { loadConfig(env) }) // ✅

并发调用 sync.Once.Do 时，谁在等？等多久？

所有未触发执行但已进入 Do 的 goroutine，会阻塞直到那个“幸运 goroutine”完成传入函数。不是轮询，也不是忙等，而是走 Go runtime 的同步原语（底层是 futex 或 semaphore），完全交由调度器管理。

这意味着：如果你的初始化函数耗时 2 秒，那么在这 2 秒内所有其他 goroutine 在 Do 处挂起，2 秒后全部唤醒并继续执行——没人重复执行，也没人跳过等待。

• 不会 panic：即使初始化函数 panic，sync.Once 仍视为“已执行”，后续调用不再执行，也不会传播 panic
• 无法区分失败：没有暴露执行是否成功的状态，失败需靠外部变量或 error 返回值自行记录
• 没有超时控制：不支持 context，超时需在外层封装（比如用 sync.Once + sync.Mutex + 手动状态标记）

源码里真正关键的那行原子操作

sync.Once 核心就靠一个 uint32 字段 done 和 atomic.CompareAndSwapUint32。第一次调用时，尝试把 done 从 0 改成 1；成功者获得执行权，失败者去等 done 变成 1。

真正容易被忽略的是：这个原子操作只决定“谁来执行”，不负责“执行完通知”。通知靠的是 sync.Mutex —— 执行者执行完会 unlock，所有等待者才能继续。所以它其实是原子操作 + 锁的组合，不是纯无锁。

这也解释了为什么不能靠反复读 done 来判断是否完成：没有内存屏障保证可见性，必须依赖锁的释放-获取语义。

终于介绍完啦！小伙伴们，这篇关于《Go语言Sync.Once用法与源码解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！