不安全。go语言中手动实现的延迟加载双重检查锁（dcl）因缺乏内存屏障和字段级可见性保证，存在指令重排与未初始化对象暴露风险；唯一安全方案是使用sync.once，它内置原子操作、互斥锁及内存屏障，确保初始化完成前所有写入对后续goroutine全局可见。
不安全。Go语言中手动实现的延迟加载双重检查锁（DCL）存在指令重排和内存可见性风险，无法保证返回的是完全初始化的对象。
为什么 Go 的 DCL 不像 Java 那样加 volatile 就能安全
Go 没有 volatile 关键字，也不提供类似语义的字段修饰符。即使你用 sync.Mutex 包裹第二次判空后的初始化逻辑，编译器和 CPU 仍可能对结构体字段的写入顺序做重排——比如先将指针赋值给全局变量 c，再填充其字段。此时另一个 goroutine 可能拿到非 nil 的 c，但读到零值字段甚至引发 panic。
- Go 规范不承诺未同步写操作的跨 goroutine 可见顺序
-
defer mu.Unlock()不能替代内存屏障 - 仅靠
mu.Lock()+ 两次判空，无法建立严格的 happens-before 关系
用 sync/atomic 手动模拟 DCL 依然危险
有人尝试用 atomic.StorePointer 和 atomic.LoadPointer 替代普通指针读写，以为能规避问题。但这是错觉：原子操作只保证读写本身不撕裂，不保证对象内部字段已初始化完毕。如果初始化函数里有多个字段赋值，它们仍可能被重排或延迟刷出到其他 goroutine 的缓存视图中。
-
atomic.StorePointer(&ptr, unsafe.Pointer(inst))只同步指针值，不同步*inst的字段状态 - 没有配套的内存栅栏（如
atomic.MemoryBarrier），Go 运行时不会插入 full barrier - 实际测试中，这种写法在高并发下偶现
nil字段或未初始化字段读取
真正安全且标准的做法只有 sync.Once
sync.Once 是 Go 标准库专为“只执行一次”场景设计的原语，它内部组合了原子操作、互斥锁和内存屏障，确保初始化函数执行完成前，所有写入对后续 goroutine 全部可见。
- 声明即用：
var once sync.Once，无需初始化，零值有效 - 懒加载天然支持：
once.Do(func(){ instance = &Singleton{...} }) - 首次调用有轻量锁开销，之后全是原子读，性能优于手写 mutex DCL
- 哪怕初始化函数 panic，
Do也不会重复执行，行为可预测
别试图绕过 sync.Once 去复刻 DCL；Go 的内存模型决定了手写方案注定是脆弱的。真正容易被忽略的点是：不是“加了锁就线程安全”，而是“必须让所有写入对所有读取者同时可见”——这个保证，只有 sync.Once 能交给你。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
