本文介绍如何在高并发场景下，针对不同 key 独立、安全地实现“每 key 仅执行一次”的逻辑，避免使用全局 sync.once 的误用，并提供基于互斥锁 + 原子标记映射的完整可运行解决方案。
本文介绍如何在高并发场景下，针对不同 key 独立、安全地实现“每 key 仅执行一次”的逻辑，避免使用全局 sync.once 的误用，并提供基于互斥锁 + 原子标记映射的完整可运行解决方案。
在 Go 并发编程中，sync.Once 是一个非常有用的工具，但它设计初衷是全局单次执行（即整个程序生命周期内只执行一次），无法按 key 维度隔离执行状态。若直接在函数内部声明 var once sync.Once（如问题代码所示），每次调用 Get(key) 都会创建新的 Once 实例，完全失去“once”语义；而若将其声明为全局变量，则所有 key 共享同一执行状态，导致不同 key 的请求被串行阻塞或相互覆盖——这显然不符合“各 key 独立触发、并发执行”的需求。
正确的做法是：为每个 key 维护独立的执行标记，并保证对该标记的读写具备线程安全性。推荐采用 map[string]bool + sync.Mutex 的组合方案，其核心逻辑如下：
- 使用互斥锁保护对共享 map 的访问；
- 检查当前 key 是否已标记为“已执行”；
- 若未执行，则立即标记并启动 goroutine 执行业务逻辑（如
fetchDataInBackground()）； - 若已执行，则跳过，不重复调度。
以下是优化后的完整示例（含错误处理提示与生产建议）：
package main
import (
"fmt"
"sync"
"time"
)
// 全局状态：key → 是否已触发后台加载
var (
once = make(map[string]bool)
onceMu sync.RWMutex // 使用 RWMutex 提升读多写少场景性能
refetch = true // 模拟刷新条件（实际中建议用 atomic.Bool 或配置驱动）
)
func Get(key string) {
fmt.Printf("→ Requested for key: %s\n", key)
if !refetch {
return
}
// 快速读取：检查是否已触发（乐观读）
onceMu.RLock()
exists := once[key]
onceMu.RUnlock()
if exists {
return // 已触发，无需重复操作
}
// 竞争写入：加写锁，双重检查后设置标记并触发
onceMu.Lock()
defer onceMu.Unlock()
if once[key] { // 再次确认，防止竞态（double-check）
return
}
once[key] = true
// 启动异步加载（注意：此处应包含错误处理和上下文控制）
go func(k string) {
fmt.Printf("✅ Background fetch started for key: %s\n", k)
// fetchDataInBackground(k) // 替换为真实逻辑，建议传入 context.Context
time.Sleep(100 * time.Millisecond) // 模拟耗时操作
fmt.Printf("✔️ Background fetch completed for key: %s\n", k)
}(key)
}
func main() {
// 模拟 20 个并发请求（含重复 key）
keys := []string{"user:101", "user:102", "post:55", "user:101", "config:db"}
fmt.Println("? Starting concurrent Get calls...")
var wg sync.WaitGroup
for _, key := range keys {
wg.Add(1)
go func(k string) {
defer wg.Done()
Get(k)
}(key)
}
wg.Wait()
fmt.Println("? All operations processed.")
}
⚠️ 关键注意事项：
-
禁止在 map 中存储指针或复杂结构体作为 value：本例仅存
bool，安全高效；若需存储更丰富状态（如加载中/失败/完成），建议封装为结构体并统一管理。 - 避免长时间持有写锁：业务逻辑（如网络请求）必须在 goroutine 中执行，切勿在锁内阻塞。
-
考虑内存泄漏风险：长期运行服务中，
oncemap 会持续增长。建议配合 TTL 缓存（如sync.Map+ 定时清理）或使用golang.org/x/sync/singleflight（更优解，见下文扩展）。 -
生产环境进阶推荐：对于高频、低延迟要求场景，强烈推荐使用
singleflight.Group，它不仅能去重，还能合并相同 key 的并发请求，返回统一结果，天然支持上下文取消与错误传播。
✅ 总结：sync.Once 不适用于 per-key 场景；通过 sync.RWMutex + map[string]bool 可以简洁、正确地实现“每 key 最多触发一次”的并发控制，兼顾可读性与可靠性。在实际工程中，请根据规模、SLA 和维护成本选择基础方案或 singleflight 这类成熟库。
