Go sync.Map.Clear 适合什么时候用：批量清空与并发读写的代价

服务切换租户配置时，最容易出现一种“旧值还在”的错觉：代码已经把缓存整体失效，下一次读取却仍然命中旧条目。Go 的 sync.Map.Clear 适合处理这种明确的批量清空场景，但它不是低成本的“刷新按钮”，也不会替你等待所有并发读取结束。

当一批缓存条目需要整体失效，而且后续读取允许重新加载时，可以用 sync.Map.Clear；如果只是淘汰一个键，继续用 Delete，不要为单键操作清空整张并发映射。

sync.Map.Clear 解决的是整批失效，不是单键删除

先看一个很小的配置缓存：

var tenantConfig sync.Map

tenantConfig.Store("tenant:42", "v1")
tenantConfig.Store("tenant:73", "v1")

tenantConfig.Clear()

调用 Clear 后，映射中当前保存的条目会被整体移除。它适合“配置版本已经切换，旧租户值全部需要重新加载”的场景。若只有 tenant:42 变更，写成 tenantConfig.Delete("tenant:42") 更准确，影响面也更小。

图 1：Store 写入条目，Clear 让整批条目失效，后续 Load 再走缓存未命中路径。

用 Load 的结果确认清空后的可见状态

不要只在日志里打印“已清空”。把读取结果写成可以复查的断言：

func loadConfig(key string) (string, bool) {
	value, ok := tenantConfig.Load(key)
	if !ok {
		return "", false
	}
	return value.(string), true
}

tenantConfig.Store("tenant:42", "v1")
tenantConfig.Clear()

value, ok := loadConfig("tenant:42")
fmt.Println(value, ok) // "" false

这里真正要验收的是 Load 返回的布尔值。Clear 只负责移除映射条目，缓存未命中后的数据库查询、配置中心读取和回填逻辑仍然要由调用方完成。

还有一个容易误判的地方：如果另一个 goroutine 在 Clear 之后重新调用 Store，随后再 Load 到新值并不代表清空失败，而是新的写入已经发生。

并发场景下，先画出 Store、Clear、Load 的关系

批量失效通常不是孤立的一行代码。一个请求可能在清空前读到旧值，另一个请求在清空后重新写入新值。排查时至少要记录操作发生的阶段，而不是把所有读取结果都归因于 Clear。

go func() {
	tenantConfig.Store("tenant:42", "v2")
}()

tenantConfig.Clear()

if value, ok := tenantConfig.Load("tenant:42"); ok {
	fmt.Println("cache hit", value)
}

这个例子故意没有给出“必然命中”或“必然未命中”的结论：并发调度顺序会影响观察结果。若业务要求清空和回填之间形成严格的批次边界，需要在上层增加版本号、读写协调或请求代际判断，不能把 sync.Map 当成事务。

用基线实验判断 Clear 是否值得

性能问题不要从 API 名字推断。可以先为条目数量和读写比例设定一组可复现的基线，再把 Clear 放进同一个基准中观察。下面的代码关注调用路径，不预设某台机器的固定耗时：

func BenchmarkClear(b *testing.B) {
	for i := 0; i 

测试时逐步增加条目数，并分别观察“只做 Load”“循环 Delete”“直接 Clear”三条路径。重点记录条目规模、并发读写比例和回填耗时。一次本地运行的纳秒数只属于当前环境，不应直接写成线上承诺。

图 2：BenchmarkClear 用 Store、Clear、Load 串起一次可复现的测量路径。

这几个信号说明不该直接调用 Clear

• 只改一个键：用 Delete，避免让无关租户同时失效。
• 回填很昂贵：整体清空会制造一批缓存未命中，先评估数据库或配置服务能否承受突发读取。
• 需要快照遍历：Range 与并发写入之间不提供业务快照；要一致快照应换用明确的版本化数据结构。
• 清空与写入存在严格先后：加上代际或版本判断，把旧请求写回新缓存的问题挡在业务层。

相关问题

Clear 和 Delete 有什么区别？

Delete 删除一个指定键，Clear 移除当前映射中的全部条目。前者是局部失效，后者是批量失效。

Clear 会阻塞所有 Load 吗？

不能把它理解成业务级停顿闸门。并发读取是否在清空前后发生，仍取决于调度和调用时序；需要批次边界时要在应用层协调。

为什么 Clear 后又能 Load 到值？

常见原因是其他 goroutine 在清空后重新执行了 Store，或者读取发生在清空之前。给写入和读取附带版本信息，通常比猜测时序更可靠。

把选择写进代码评审清单

评审一处 sync.Map.Clear 时，可以顺手问四个问题：这次是整批失效还是单键变化？清空后谁负责回填？并发写入是否可能把旧值重新写回？真实条目规模下的基线测过没有？四个问题都能回答，再决定使用 Clear；否则先缩小失效范围，或者补上版本协调。