package main

import (
	"fmt"
	"sync"
)

type Config struct {
	Server string
	Port   int
}

var (
	once   sync.Once
	config *Config
)

func InitConfig() *Config {
	once.Do(func() {
		fmt.Println("mock init ...") // 模拟初始化代码
	})

	return config
}

func main() {
	// 连续调用 5 次初始化方法
	for i := 0; i < 5; i++ {
		_ = InitConfig()
	}
}

$ go run main.go

# 输出如下
mock init ...

package sync

import (
	"sync/atomic"
)

// Once 是一个只执行一次操作的对象
// Once 一旦使用后，便不能再复制
//
// 在 Go 内存模型术语中，once.Do(f) 中函数 f 的返回值会在 once.Do() 函数返回前完成同步
type Once struct {
	done uint32
	m    Mutex
}

// 当且仅当第一次调用实例 Once 的 Do 方法时，Do 去调用函数 f
// 换句话说，调用 once.Do(f) 多次时，只有第一次调用会调用函数 f，即使 f 函数在每次调用中有不同的参数值

// 并发调用 Do 函数时，需要等到其中的一个函数 f 执行之后才会返回
// 所以函数 f 中不能调用同一个 once 实例的 Do 函数 (递归调用)，否则会发生死锁
// 如果函数 f 内部 panic, Do 函数同样认为其已经返回，将来再次调用 Do 函数时，将不再执行函数 f
// 所以这就要求我们写出健壮的 f 函数
func (o *Once) Do(f func()) {
    // 下面是一个错误的实现
    // if atomic.CompareAndSwapUint32(&o.done, 0, 1) {
    //   f()
    // } 
	
    // 错误原因分析: 
    // 这里以数据库连接场景为例，在并发调用情况下，假设其中 1 个 goroutine 正在执行函数 f (初始化连接)，
	// 此时其他的 goroutine 将不会等待这个 goroutine 执行完成，而是会直接返回，
    // 如果连接发生了一些延迟，导致函数 f 还未执行完成，那么此时连接其实还未建立，
	// 但是其他的 goroutine 认为函数 f 已经执行完成，连接已建立，可以开始使用了
	// 最后当其他 goroutine 使用未建立的连接操作时，产生报错

	// 要解决上面的问题， 就需要确保当前函数返回时， 函数 f 已经执行完成，
	// 这就是 slow path 退回到互斥锁的原因，以及为什么 atomic.StoreUint32 需要延迟到函数 f 返回之后
	if atomic.LoadUint32(&o.done) == 0 {
		o.doSlow(f) // slow-path 允许内联
	}
}

func (o *Once) doSlow(f func()) {
	// 并发场景下，可能会有多个 goroutine 执行到这里
    o.m.Lock()  // 但是只有 1 个 goroutine 能获取到互斥锁
    defer o.m.Unlock()
	
	// 注意下面临界区内的判断和修改
	
    // 在 atomic.LoadUint32 时为 0 ，不等于获取到锁之后也是 0，所以需要二次检测
	// 因为已经获取到互斥锁，根据 Go 的同步原语约束，对于字段 done 的修改需要在获取到互斥锁之前同步
	// 所以这里直接访问字段即可，不需要调用 atomic.LoadUint32 方法
	// 如果有其他 goroutine 已经修改了字段 done，那么就不会进入条件分支，没有任何影响 
	if o.done == 0 {
		// 只要函数 f 成功执行过一次，就将 o.done 修改为 1
		// 这样其他 goroutine 就不会再执行了，从而保证了函数 f() 只会执行一次，
		// 这里必须使用 atomic.StoreUint32 方法来满足 Go 的同步原语约束
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}