推荐使用 sync.Once 实现单例,它本质是安全高效的双重检查锁;手动 DCL 需用 atomic.pointer 和 mutex 配合,易出错;纯 mutex 方式性能差,应避免。

在 go 中实现双重检查锁(double-Checked Locking)单例模式,核心是用 sync.Once 或手动结合 sync.Mutex 与原子读写,确保线程安全且避免重复初始化。但要注意:Go 的内存模型和编译器优化让“经典 java 风格”的双重检查锁容易出错,不推荐手写 volatile + mutex 组合,而应优先使用 sync.Once —— 它本质就是安全、高效、已验证的双重检查锁实现。
✅ 推荐方式:用 sync.Once(最简洁、最安全)
sync.Once 内部已做内存屏障和原子控制,保证 Do 中的函数只执行一次,且对所有 goroutine 可见。无需手动加锁或判断 nil。
示例:
package singleton import "sync" type Config struct { Host string Port int } var ( configInstance *Config once sync.Once ) func GetConfig() *Config { once.Do(func() { configInstance = &Config{ Host: "localhost", Port: 8080, } }) return configInstance }
⚠️ 谨慎尝试:手动双重检查锁(仅作理解,生产环境慎用)
若坚持模拟经典 DCL(如学习目的),必须配合 sync/atomic 控制初始化状态,并确保写入实例前完成内存可见性。Go 不支持 Java 的 volatile,需用 atomic.StorePointer 和 atomic.LoadPointer 配合 unsafe.Pointer。
立即学习“go语言免费学习笔记(深入)”;
- 用
atomic.Value或atomic.Pointer(Go 1.19+)存储实例指针 - 第一次读为 nil → 加锁 → 再次检查是否仍为 nil → 初始化并原子写入
- 必须用原子操作读写指针,否则可能看到部分写入的脏数据
简化版(Go 1.19+):
var ( config atomic.Pointer[Config] mu sync.Mutex ) func GetConfigDCL() *Config { p := config.Load() if p != nil { return p } mu.Lock() defer mu.Unlock() if p = config.Load(); p != nil { return p } newConfig := &Config{Host: "localhost", Port: 8080} config.Store(newConfig) return newConfig }
❌ 常见错误:纯 mutex + nil 判断(性能差、不必要)
每次调用都加锁再判断,失去“双重检查”意义,变成单锁单例,吞吐量低。尤其高并发下,mu.Lock() 成为瓶颈。
错误写法示例:
func GetConfigBad() *Config { mu.Lock() // ❌ 每次都锁! defer mu.Unlock() if configInstance == nil { configInstance = &Config{...} } return configInstance }
? 补充建议:支持初始化参数或错误处理
如果单例创建可能失败(如加载配置文件、连接数据库),可扩展 sync.Once 方式,用额外变量保存 Error:
var ( dbInstance *sql.DB dbErr error dbOnce sync.Once ) func GetDB() (*sql.DB, error) { dbOnce.Do(func() { dbInstance, dbErr = sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test") }) return dbInstance, dbErr }
不复杂但容易忽略:单例对象本身也需考虑并发安全。例如 *sql.DB 是并发安全的,但自定义结构体若含非同步字段(如 map、slice),仍需额外保护。