Go sync.Map.CompareAndSwap 返回 false 时怎么判断值已被谁改写

sync.Map.CompareAndSwap 返回 false，不能直接告诉你“被谁改写”。它只报告这次条件替换没有成功：键可能不存在，或者当前值与传入的 old 不相等。标准库不会返回改写者身份、失败时的当前值或修改历史。

如果业务需要排查写入来源，我会把版本、业务写入者和操作标识放进同一份不可变值，再记录期望值和失败后的观察值。这里的写入者由应用维护，不是 Go 自动识别的 goroutine 身份；后续 Load 也不能当成 CAS 失败瞬间的快照。

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

先限定 false 能证明什么

设想一个任务状态从 pending 改成 running，调用方先 Load 了 pending，再拿它作为 old 发起条件替换。返回 false 后立刻断言“另一个 worker 抢走任务”，这个结论就超出了接口提供的信息。键被删除、old 的动态类型不对，或者调用方本来就拿错了预期值，都可能让判断偏离真实问题。

我的排查顺序是先保存本次请求的 key、old、new 以及调用方操作标识，再看后续观察是否存在、类型是否正确、版本是否变化。这样得到的是可解释的诊断线索，不是根据一个布尔值猜写入者。

本文只讨论比较失败与并发更新的关系，不设计自旋锁、重试循环或任务调度算法。条件更新是否应继续尝试，需要业务另外决定，不能从 false 自动推导出来。

把期望值、实际观察与写入身份分开

这几个字段需要分别命名。把后续 Load 结果叫 observedAfter，比命名为 actualAtFailure 更准确；把日志中的 Writer 叫业务写入者，比声称拿到了“竞争胜出的 goroutine ID”更符合事实。

在不可变值中保存版本和写入者

下面的 record 只包含字符串和无符号整数，因此整个结构体可比较。State 是业务状态，Revision 是应用版本，Writer 标记写入来源，Operation 标记具体业务操作。字段整体参与相等比较，不能只修改 State 却认为其他字段无关。

package main

import (
    "fmt"
    "sync"
)

type record struct {
    State     string
    Revision  uint64
    Writer    string
    Operation string
}

func main() {
    var m sync.Map
    const key = "task-17"
    initial := record{"pending", 1, "initializer", "create-17"}
    m.Store(key, initial)

    raw, ok := m.Load(key)
    if !ok {
        fmt.Println("首次读取时键不存在")
        return
    }
    expected, ok := raw.(record)
    if !ok {
        fmt.Printf("值类型不符: %T\n", raw)
        return
    }

    // 用顺序代码明确构造值已变化的场景，不伪装成并发压测。
    changed := record{"assigned", 2, "scheduler-B", "assign-92"}
    m.Store(key, changed)
    proposed := record{"running", 2, "worker-A", "start-31"}
    swapped := m.CompareAndSwap(key, expected, proposed)
    fmt.Println("本次是否替换:", swapped)

    if !swapped {
        // 这是 CAS 之后的观察，不是失败瞬间的原子快照。
        later, exists := m.Load(key)
        if !exists {
            fmt.Println("后续观察: 键不存在")
            return
        }
        observed, ok := later.(record)
        if !ok {
            fmt.Printf("后续观察类型异常: %T\n", later)
            return
        }
        fmt.Printf("期望版本=%d 后续版本=%d 写入者=%q 操作=%q\n",
            expected.Revision, observed.Revision,
            observed.Writer, observed.Operation)
    }
}

这个原创示例有意使用顺序代码：先读取旧值，再明确写入另一份记录，最后用旧值尝试 CAS。按代码语义，本次替换应失败，后续观察记录携带 scheduler-B 与 assign-92。它展示的是信息如何保存，不是已经执行的并发实验，也不代表生产环境里的每次失败都由同一种原因造成。

在真实调用中，proposed 的版本应根据已读取版本和业务约定生成，处理计数溢出及删除重建问题。示例固定为 2 只是为了展示两个候选都从同一旧版本提出更新；这里没有提供生产级版本分配器。

我倾向于先让所有写入口遵守“替换整份 record”的约定，再考虑日志排查。若某个入口仍然 Store 一个裸字符串，或者绕过版本规则写回旧记录，Writer 和 Revision 都会失去原本的解释范围。

失败后读取的信息属于后续观察

CAS 返回到再次 Load 之间，还可能发生多次更新。失败时的值可能由 B 写入，后续观察到的却已经是 C；也可能失败时键存在，Load 时键已经删除。因此观察值中的 Writer 只能说明这份值携带谁的标记，不能单独证明谁使前一次 CAS 失败。

反过来也一样：CAS 失败后 Load 又看见与 old 相等的值，不代表前次比较必定出错。中间值可能变化后又被写回，或者键经历删除重建。只比较业务状态字符串，会看不见这些中间变化。

引入版本可以帮助区分代次，但前提是所有写入入口遵守不回退、不重复使用旧代次的规则；如果删除后又从版本 1 开始，旧请求仍可能混淆新旧对象。需要严格归因时，还应记录删除、重建与成功更新对应的业务操作，并选择能满足一致性要求的记录方案。

“CAS 成功后再写一条普通日志”也不是原子审计：更新与日志之间存在间隔，日志还可能失败。对于完整历史要求，我会把它视作独立的数据设计问题，而不会宣传给 sync.Map 多加几个字段就完成了可靠审计。

排除类型不一致和对象原地修改

接口值比较还包含动态类型。比如 Map 中存的是 int(7)，old 却是 int64(7)，即使打印都像数字 7，也不相等。排查时应保留类型信息，先确认 key 和 old 来自同一个业务表示约定，再讨论并发竞争。

old 必须是可比较类型。切片、映射、函数等不能因为装进 any 就获得可比较性；结构体里放入不可比较成员同样会破坏比较条件。不可比较值触发的运行时问题不应被当成普通的 swapped=false。

若 Map 存储的是指针，比较通常针对指针身份，并不是自动比较指向对象的全部字段。另一处原地修改对象，可能根本没有替换 Map 中的那个指针；CAS 不能因此自动发现字段级变化。sync.Map 保护自身映射操作，也不会替被指向对象提供字段同步。

这也是本文选用无可变引用成员的值结构体的原因：读取后得到一份字段值副本，更新通过整份替换表达。它使示例的比较对象更清楚，但不能代替业务对其他共享对象的同步设计。

给排查记录设定可解释的范围

• 记录本次 key、old 的类型与版本，以及 proposed 的业务操作标识。
• 失败后的读取标为后续观察，区分“键不存在”和“值类型不符”。
• Writer 记录业务来源，不假定标准库提供 goroutine 身份。
• 版本协议覆盖 Store、CAS、删除与重建入口，避免旧值回写破坏含义。
• 需要完整改写历史时另行设计可靠记录，单个当前值不承担历史职责。

对我来说，这种记录适合定位“拿着过期期望值发起更新”的问题。它的收益是诊断字段清楚，代价是需要统一写入协议。若应用只要当前状态且不关心来源，没必要把它包装成复杂的审计系统；若必须准确还原每次修改，则应从一致性要求重新选择存储与记录方式。

失败后看到 Writer=B，能确认就是 B 改坏了吗？

不能。你只能确认后续读到的记录带有 B 标记。是否是 B 导致该次失败，需要结合操作记录与一致性约定，不能靠这一次 Load 下结论。

键不存在，old 传 nil 会自动插入吗？

不会。CompareAndSwap 不是缺失时插入接口。键不存在和键存在但值为 nil 是不同情况，读取时应保留 Load 的 ok 标记。

CAS 成功能证明期间没有任何其他修改吗？

不能。成功说明条件比较成立并完成这次替换；如果值曾变化后又恢复为相等值，仅凭该次成功无法识别中间历史。业务版本与对象代次可以帮助表达这类区别，但必须有统一维护规则。

参考：Go sync.Map 官方接口说明、Go 语言规范：相等比较与可比较类型。本文场景、代码及诊断字段设计为原创。