17370845950

Go中不能直接用全局变量当单例，因未

加锁的懒加载会导致多goroutine并发创建多个实例；必须用sync.Once保证初始化仅执行一次且线程安全。

为什么 Go 里不能直接用全局变量当单例

很多人写完 var instance *ResourceManager 就以为是单例了，但没加初始化保护，多 goroutine 并发调用时可能创建多个实例。Go 的包级变量初始化只在 init() 里安全执行一次，而运行时按需构造必须靠同步机制。

• 未加锁的懒加载会触发竞态：两个 goroutine 同时判断 instance == nil 都为真，各自 new 一份
• sync.Once 是官方推荐方案，它底层用原子操作+互斥锁，保证 Do() 内函数仅执行一次且完全同步
• 不要用 init() 做带参数或依赖外部状态的初始化——它无法传参，也无法处理失败重试

用 sync.Once 实现线程安全的懒加载单例

这是最常用、最稳妥的方式。关键点在于把构造逻辑封装进匿名函数，交由 once.Do() 托管。

var (
    instance *ResourceManager
    once     sync.Once
)

type ResourceManager struct {
    db *sql.DB
    mu sync.RWMutex
}

func GetResourceManager() *ResourceManager {
    once.Do(func() {
        // 这里可以做任意复杂初始化：连接 DB、读配置、校验权限等
        db, err := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
        if err != nil {
            panic(err) // 或记录日志后 os.Exit(1)
        }
        instance = &ResourceManager{db: db}
    })
    return instance
}

• once.Do() 内部已处理并发安全，无需额外加锁
• 返回指针而非值，避免复制结构体；若结构体含 mutex 字段（如本例），复制会导致 panic
• 构造失败时 panic 是常见做法，因为单例不可用通常意味着程序无法继续——你也可以改用返回 error + 全局 error 变量，但调用方必须显式检查

带参数的单例初始化怎么处理

如果单例依赖运行时参数（比如配置文件路径、环境名），就不能把初始化逻辑硬编码在 once.Do() 里。需要提前保存参数，并在首次调用时消费。

• 定义私有初始化函数，接收参数并返回实例，同时设一个 sync.Once 控制调用时机
• 用函数变量替代固定初始化逻辑：var initFunc func(string) *ResourceManager
• 更实用的做法是：提供 SetConfig() 方法，在 main 初始化阶段调用，再由 GetResourceManager() 触发构造

var (
    instance *ResourceManager
    once     sync.Once
    config   struct {
        DSN string
        TTL time.Duration
    }
)

func SetConfig(dsn string, ttl time.Duration) {
    config.DSN = dsn
    config.TTL = ttl
}

func GetResourceManager() *ResourceManager {
    once.Do(func() {
        db, _ := sql.Open("mysql", config.DSN)
        instance = &ResourceManager{
            db: db,
            mu: sync.RWMutex{},
        }
    })
    return instance
}

单例对象里的资源要不要手动 Close

要。Go 没有析构函数，单例持有的资源（如 *sql.DB、*http.Client、文件句柄）不会自动释放。常见错误是只管 New 不管 Close。

• 对外暴露 Close() 方法，并在 main() 退出前显式调用（例如用 defer resource.Close() 或 os.Interrupt 信号捕获）
• 不要在 GetResourceManager() 里做 defer instance.Close() —— 它属于获取行为，不是生命周期终结点
• 如果单例内部用了 sync.Pool 或缓存 map，也要在 Close() 中清空，防止内存泄漏

真正容易被忽略的是：单例一旦被创建，它的生命周期就和整个进程绑定，任何未关闭的底层连接、goroutine 泄漏、timer 未 stop，都会持续占用资源直到进程结束。