Go 问答：sync.Once 为什么能保证只执行一次，多协程下怎么复用

Go 里经常会遇到一个问题：多个协程同时调用初始化函数，怎么保证这段逻辑只跑一次？如果自己加锁，写起来不难，但容易把性能和可读性都写乱。`sync.Once` 就是专门为这个场景准备的。

这篇问答不从源码细节硬啃，而是从实际开发角度回答三个问题：它到底保证了什么、内部大概怎么工作、在配置加载和单例初始化时应该怎么用。

适合人群

本文适合刚开始写 Go 后端、已经会用 `sync.Mutex` 和 `sync.WaitGroup`，但还没把 `sync.Once` 用顺手的开发者。你只需要理解函数闭包和并发调用即可。

目录

• sync.Once 解决的到底是什么问题
• 多个协程同时调用会发生什么
• 常见用法：配置加载、单例和懒初始化
• 常见坑位和验证方式
• 总结

sync.Once 解决的到底是什么问题

先看需求：某个初始化函数可能被很多协程同时调用，但真正只希望它执行一次。比如数据库连接池初始化、配置文件加载、缓存客户端创建、全局埋点初始化。

如果每个请求都去跑一次初始化，轻则浪费资源，重则出现重复注册、重复创建连接、重复写全局状态。`sync.Once` 的作用就是把“只执行一次”这件事交给标准库处理。

多个协程同时调用会发生什么

最关键的点是：第一次进来的协程会执行函数，其他协程会等待或者快速返回，最终都能看到同一个初始化结果。

package main

import (
	"fmt"
	"sync"
)

var once sync.Once
var cfg map[string]string

func initConfig() {
	cfg = map[string]string{
		"env": "prod",
		"mode": "fast",
	}
	fmt.Println("init config")
}

func getConfig() map[string]string {
	once.Do(initConfig)
	return cfg
}

func main() {
	var wg sync.WaitGroup
	for i := 0; i 

这个例子里，不管有多少个协程并发调用 `getConfig`，`initConfig` 只会执行一次。

常见用法：配置加载、单例和懒初始化

1. 配置加载

启动时读取配置文件，并在后续请求里复用结果，是 `sync.Once` 最常见的用法之一。它比在每个请求里重复读文件更稳，也更省资源。

2. 单例创建

比如日志客户端、消息客户端、第三方 SDK 的全局实例，通常都适合放进 `once.Do`。这样可以避免多次创建和状态不一致。

3. 懒初始化

如果某个资源不一定会被用到，可以等第一次真正访问时再初始化。`sync.Once` 很适合做这种延迟加载。

常见坑位和验证方式

1. 把可能失败的逻辑直接塞进 Once

`once.Do` 一旦执行过，后续不会再重跑。也就是说，如果初始化函数第一次失败，后面不会自动再尝试。需要重试的场景，应该把失败状态单独设计出来，而不是直接把重试责任交给 `Once`。

2. 在 Do 里写太重的逻辑

`once.Do` 适合做一次性初始化，不适合塞大量业务逻辑。逻辑太重会让首个访问请求变慢。

3. 忽略结果同步

如果初始化结果要被多个协程读到，最好把结果保存到全局变量或结构体里，并确保读写时序清晰。`Once` 只保证执行次数，不替你设计数据结构。

4. 误以为 Do 会重复执行

`sync.Once` 不是“每次都判断一下再决定是否执行”的普通开关，它更接近一个带原子状态的门闩。执行过一次后，后面会直接跳过。

总结

`sync.Once` 解决的是“多个协程同时进入时，只需要一份初始化结果”的问题。它最适合配置加载、单例创建、懒初始化这类一次性逻辑。实际使用时要记住两点：它只保证执行一次，不保证失败重试；它适合初始化，不适合塞复杂业务流程。