Go sync.Map LoadOrStore 怎样避免并发重复初始化

先给结论：sync.Map.LoadOrStore 能保证同一个键最终只保存一个值，但它不会阻止传入参数在调用前被多个 goroutine 重复构造。下面这种写法看起来像“只初始化一次”，实际上 buildConfig() 可能已经执行了多次：

// 容易误解的写法：函数参数会先求值，再进入 LoadOrStore
actual, _ := configs.LoadOrStore(name, buildConfig(name))
_ = actual

如果要避免昂贵初始化重复执行，应先用 LoadOrStore 抢一个按键共享的条目，再在条目内部用 sync.Once 执行初始化。这样允许多个 goroutine 同时到达，但真正的初始化函数只由一个条目执行。

官方地址：https://pkg.go.dev/sync#Map.LoadOrStore

LoadOrStore 负责“谁拿到共享条目”，sync.Once 负责“共享条目里的初始化只做一次”。把这两层职责分开，排查重复初始化会清楚很多。

先判断重复初始化发生在哪一层

线上看到重复连接、重复加载配置或重复注册时，先区分两种情况：

• 候选值重复构造：LoadOrStore(key, build()) 中的 build() 在调用前就会执行，多个 goroutine 可能各自构造一个候选值。
• 实际初始化重复执行：多个 goroutine 都进入真正的初始化函数，造成连接、文件读取或外部注册等副作用重复发生。

第一种情况可能只浪费临时分配；第二种情况才是需要优先处理的并发故障。LoadOrStore 的返回值是 (actual, loaded)：已有值时返回已有值并把 loaded 设为 true；没有值时保存传入值并把 loaded 设为 false。

用 LoadOrStore 只抢一个初始化条目

正确的第一步不是把初始化函数塞进参数，而是为每个键创建一个轻量条目。条目可以暂时没有结果，真正的结果由它自己的 sync.Once 填充：

package main

import (
    "fmt"
    "sync"
)

type Config struct {
    Name string
}

type configEntry struct {
    once  sync.Once
    value *Config
    err   error
}

func (e *configEntry) get(name string) (*Config, error) {
    // 同一个条目只允许一个 goroutine 执行昂贵初始化。
    e.once.Do(func() {
        e.value, e.err = buildConfig(name)
    })
    return e.value, e.err
}

func buildConfig(name string) (*Config, error) {
    // 真实项目中这里可以读取配置或创建连接；示例不做外部副作用。
    return &Config{Name: name}, nil
}

var configs sync.Map

func GetConfig(name string) (*Config, error) {
    // 候选条目很轻，先竞争共享条目，再进入条目内部的 once。
    candidate := &configEntry{}
    actual, _ := configs.LoadOrStore(name, candidate)
    return actual.(*configEntry).get(name)
}

func main() {
    value, err := GetConfig("payments")
    if err != nil {
        // 初始化失败要向调用方返回真实错误，避免把失败悄悄当成成功。
        panic(err)
    }
    fmt.Println(value.Name)
}

这里即使有 100 个 goroutine 同时调用 GetConfig("payments")，也只有一个 configEntry 会被放入 map。其他 goroutine 拿到的是同一个 actual 指针，并在同一个 once.Do 上等待。

让错误、删除和重试策略保持明确

sync.Once 会把第一次执行的完成状态固定下来，因此初始化返回错误时，后续调用也会读到同一个错误。这适合“失败后短时间内不应反复冲击依赖”的场景，但不适合所有业务。若要重试，不能直接重置已经使用过的 sync.Once；应在确认没有读者依赖旧条目后删除整个键，再让下一次调用创建新条目。

func RefreshConfig(name string) {
    // 删除表示放弃旧条目的结果；下一次 GetConfig 会创建新的 once。
    configs.Delete(name)
}

func GetConfigChecked(name string) (*Config, error) {
    value, err := GetConfig(name)
    if err != nil {
        // 这里只记录或转换错误，不在同一个请求里盲目重复初始化。
        return nil, fmt.Errorf("load config %q: %w", name, err)
    }
    return value, nil
}

删除是策略动作，不是通用的“失败自动修复”。如果初始化结果已经被其他业务持有，删除 map 中的条目并不会撤销旧对象的副作用；连接关闭、资源回收和新旧版本切换仍需要单独设计。

现场排查：触发信号、处理步骤与回滚边界

当监控发现同一个键短时间出现多次初始化日志，可以按运行手册顺序检查：

1. 快速判断：在初始化函数入口记录键和调用次数，先确认重复来自 build() 参数求值，还是来自条目内部的初始化函数。
2. 处理步骤：把昂贵函数移出 LoadOrStore 参数，改为“轻量条目 + sync.Once + 共享结果”。
3. 回滚路径：先恢复到旧实现或关闭新键空间；不要通过并发重置 sync.Once 来强行重试。
4. 告警确认：观察初始化次数、失败次数和资源创建数是否与唯一键数恢复一致，避免只看请求成功率。
5. 复盘项：确认错误是否应该缓存、删除条目是否会留下旧资源、以及同一个逻辑键是否在不同格式下被重复表示。

还要记住，sync.Map 不是所有场景的默认容器。Go 官方文档说明，它主要适合写入一次、读取多次的缓存，或不同 goroutine 操作互不重叠键集合的场景。若业务还需要维护多个字段之间的不变量，普通 map 配合明确的锁可能更容易维护。

几个常见问题

LoadOrStore 会让 value 表达式只执行一次吗？

不会。Go 会先求值函数参数，再调用 LoadOrStore。因此 LoadOrStore(key, build()) 仍可能让多个 goroutine 执行 build()，只是最终 map 里只保留一个值。

为什么不用 loaded 为 false 的 goroutine 执行初始化？

如果把初始化放在调用返回之后，其他 goroutine 可能已经拿到尚未完成的条目或自行走出流程。把 sync.Once 放在共享条目里，才能让所有调用者对同一个完成点建立一致约束。

初始化失败后是否一定要 Delete？

不一定。错误缓存可以保护下游依赖，避免故障期间不断重试；只有业务明确需要重试，并且已经设计好旧资源处理、退避和并发删除边界时，才把 Delete 作为恢复动作。

能否把 configEntry 按值存进 sync.Map？

不建议。包含 sync.Once 的条目应保持稳定身份，使用指针存储更容易确保所有调用者共享同一个同步对象，也避免复制同步原语。

总结：LoadOrStore 解决的是同一个键的原子占位和取值，不能自动包住参数里的初始化函数。用它保存每个键唯一的条目，再在条目内部用 sync.Once 执行真正初始化，才能避免并发重复副作用；错误缓存、删除和重试则必须作为单独的运维策略明确下来。