Golang单例模式为何用sync.Once实现

对于一个Golang开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《Golang单例模式为何用sync.Once实现》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

Go单例必须用sync.Once而非简单加锁，因其通过原子状态+互斥锁确保初始化函数仅执行一次且完全完成；若Do内panic，状态仍标记为已执行，后续调用直接返回，可能导致nil指针解引用。

为什么 Go 单例必须用 sync.Once 而不是简单加锁

因为仅靠 mutex.Lock() 无法避免「双重检查失败」导致的多次初始化。常见错误是：先判断指针是否为 nil，再加锁、再判断、再创建——但两个 goroutine 可能在第一次判断后同时进入临界区，造成重复执行 new() 或初始化逻辑。

sync.Once 的核心价值不是“加锁”，而是“确保函数只执行一次且完全完成后再返回”，它内部用原子状态 + 互斥锁组合，天然规避了竞态窗口。

sync.Once 初始化函数里 panic 会怎样

如果传给 once.Do() 的函数 panic，sync.Once 会把状态标记为“已执行”，后续调用 Do() 不再执行该函数，也不会重试，直接返回。这意味着单例对象可能未成功构造，后续使用该对象大概率触发 nil pointer dereference 或其他异常。

• 务必在 Do() 包裹的函数内做完整错误处理，不要让 panic 泄露出去
• 推荐模式：

  var once sync.Once
  var instance *Config
  var err error
  
  func GetConfig() (*Config, error) {
      once.Do(func() {
          instance, err = loadConfig() // 返回 (*Config, error)
      })
      return instance, err
  }

不用 sync.Once 的替代方案有哪些？为什么不推荐

有人用 atomic.Value + CompareAndSwapPointer 手动实现，或用 init() 函数——但都有硬伤：

• init() 只能在包加载时运行，无法延迟初始化（比如依赖配置文件、网络连接等）
• 手动原子操作极易出错：漏掉内存屏障、忘记处理 ABA 问题、或误判指针比较结果
• 全局 mutex + double-check 模式在高并发下性能差，且仍需仔细设计判断顺序，稍有不慎就失效

sync.Once 是标准库经过长期验证的最小可行抽象，代码少、语义明确、无额外依赖。

多个单例共用一个 sync.Once 实例会怎样

不能复用。每个单例必须配独立的 sync.Once 字段或变量。因为 sync.Once 的状态是绑定到「某次 Do() 调用」的，不是绑定到类型或值的。

下面这段是错的：

var once sync.Once
var a *ServiceA
var b *ServiceB

func GetA() *ServiceA {
    once.Do(func() { a = new(ServiceA) })
    return a
}

func GetB() *ServiceB {
    once.Do(func() { b = new(ServiceB) }) // 这里永远不会执行！
    return b
}

第二个 Do() 直接跳过——once 已被标记为 done。线程安全的前提是「一单一例一 Once」。

本篇关于《Golang单例模式为何用sync.Once实现》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！