Go sync.Map Swap 怎样识别首次写入

sync.Map.Swap 适合处理“把某个键的值换成新值，同时判断它是不是第一次出现”这类并发更新。它一次完成替换，并返回 previous 和 loaded：loaded=false 表示写入前没有这个键，loaded=true 表示之前已经存在，不需要再用一次 Load 去猜测。

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

判断首次写入要看 loaded，判断旧内容才看 previous。即使旧值本身是一个包装后的 nil，也不要把 previous == nil 当成“键不存在”的唯一证据。

Swap 的两个返回值分别代表什么

先把 API 的语义拆开。调用 m.Swap(key, newValue) 后，newValue 会成为这个键的新值；previous 是替换前的值；loaded 专门回答“替换前是否存在这个键”。官方文档把这个方法标记为 Go 1.20 新增。

因此，下面两种状态要分开处理：

用 loaded 识别首次写入

假设服务维护一张并发状态表：第一次看到任务 ID 时建立状态，后续请求只更新状态并留下变更记录。用 loaded 分支比“先查有没有、再决定怎么写”更直接。

package main

import (
	"fmt"
	"sync"
)

func recordState(states *sync.Map, taskID string, next string) {
	// Swap 在一次并发操作中完成替换，并返回旧值和键是否存在。
	previous, loaded := states.Swap(taskID, next)
	if !loaded {
		// loaded=false 才表示这是这个 taskID 的首次写入。
		fmt.Printf("first write: key=%s value=%v\n", taskID, next)
		return
	}

	// loaded=true 时，previous 才是覆盖前的业务值。
	fmt.Printf("overwrite: key=%s previous=%v current=%v\n", taskID, previous, next)
}

func main() {
	var states sync.Map
	recordState(&states, "task-7", "queued")
	recordState(&states, "task-7", "running")
}

这段代码的判断重点是返回值，而不是新值是否为空。若业务值需要携带更多状态，建议存入结构体指针，并让结构体中的版本号、来源和更新时间承担业务判断。

为什么不要先 Load 再 Store

常见但不稳妥的写法是先 Load，发现没有后再 Store。在两个 goroutine 同时处理同一个新键时，它们都可能在写入前看到缺失，于是都执行“首次初始化”。读取和写入之间的窗口让“首次”变成了两个 goroutine 各自的判断。

// 这种组合不能把“首次写入”判断和写入绑定成一个原子动作。
if _, ok := states.Load(taskID); !ok {
	// 另一个 goroutine 可能在这里同时通过了相同判断。
	states.Store(taskID, "queued")
}

// 需要判断首次写入时，把判断交给 Swap 的 loaded 返回值。
previous, loaded := states.Swap(taskID, "queued")
_ = previous // loaded=true 时可用于审计覆盖前的值
_ = loaded

Swap 并不会替你完成业务层面的去重、权限或幂等设计，但它把“替换并拿到旧值”的动作收拢到同一个同步操作中。若后续还需要基于旧值做条件更新，应该继续评估 CompareAndSwap 是否更符合需求，而不是把多个无条件操作拼在一起。

把 loaded 接到审计和覆盖保护

安全场景里，首次写入和覆盖写入往往有不同的审计意义。例如状态键来自请求参数时，要先确认键的来源已经过业务校验；写入本身完成后，再根据 loaded 记录“创建状态”还是“替换状态”。不要把 sync.Map 当作权限系统，也不要把它存储的值直接当作可信身份。

type TaskState struct {
	Status string
	Version uint64
}

func replaceTask(states *sync.Map, taskID string, next *TaskState) (string, bool) {
	// taskID 应在进入这里前完成格式和权限校验；Swap 只负责并发替换。
	previous, loaded := states.Swap(taskID, next)
	if !loaded {
		return "created", false // 首次写入：记录创建审计事件
	}

	old, ok := previous.(*TaskState)
	if !ok || old == nil {
		return "replaced-with-unexpected-old-value", true // 保留异常信号供审计
	}
	return "replaced", true // 覆盖写入：可比较 old.Version 与 next.Version
}

示例把状态存成指针，是为了让旧值和新值拥有清晰的字段边界。真实系统还应限制 taskID 的格式、控制状态迁移方向，并决定异常旧值是拒绝、告警还是进入修复队列。

复查时重点看这五项

1. 是否真的需要“替换并拿到旧值”：只需要无条件写入时，Store 更简单。
2. 是否用 loaded 判断键存在：不要把 previous == nil 当作完整判断。
3. 是否把业务值设计成可比较、可审计的结构：多个 goroutine 共享的状态不要依赖模糊的 nil 语义。
4. 是否存在先 Load 再 Store 的首次写入逻辑：有就检查是否可以合并为 Swap 或条件更新。
5. 是否把权限、输入校验和状态迁移放在并发容器之外明确处理：sync.Map 只提供并发访问能力。

相关问题

loaded=true 能说明 previous 一定不是 nil 吗？

不能。loaded 表示键存在；如果应用曾经存入可表示 nil 的值，previous 仍可能为 nil，所以需要同时维护键存在语义和业务值语义。

只想首次写入时应该用 Swap 还是 LoadOrStore？

如果已有值时要拿到旧值并无条件替换，用 Swap；如果已有值时必须保留旧值、不允许覆盖，用 LoadOrStore 更直接。

Swap 能代替所有并发状态更新吗？

不能。它适合无条件替换并读取旧值；需要“旧值满足条件才更新”时，应考虑 CompareAndSwap，并为状态迁移设计清晰的版本和失败处理。