Go atomic.Uint64 和 atomic.Int64 在溢出时怎么解释结果

Go 的 atomic.Uint64 累加越过最大值后会回到 0；atomic.Int64 从最大正数加 1 后会变成最小负数。这是整数运算规则，不是原子操作失效，也不会仅因这次溢出触发 panic。Add 返回本次操作产生的新值，随后调用的 Load 则可能读到其他 goroutine 已经更新的值。

这类问题应从数值边界判断，而不是仅看有没有加锁。本文围绕 sync/atomic 的两个 64 位类型解释结果，不展开性能排行或高并发架构。两个类型从 Go 1.19 起提供，零值可用，首次使用后不得复制。官方入口：https://pkg.go.dev/sync/atomic。

选择信号：零和负数分别意味着什么

Uint64 的范围是 0 到 18446744073709551615。无符号加法的结果按 2 的 64 次方取模，因此最大值加 1 得到 0。Int64 的范围是 -9223372036854775808 到 9223372036854775807；最大正数加 1 得到最小负数。两种类型都不会因为“atomic”而自动扩展位数。

有符号类型也允许运行时溢出，其结果由整数表示与运算规则确定。不能把“x + 1 总大于 x”作为跨越上界仍成立的假设。这里讨论的是整数运算，和浮点无穷大不是同一套机制。

解决的问题：用同一个示例比较加一与减一

下面的独立示例使用 fmt 与 sync/atomic。它把值主动设置到边界，便于推导行为，不需要真的累加数百亿次。代码后的输出为按规范推导的预期值。

package main

import (
    "fmt"
    "sync/atomic"
)

func main() {
    // 无符号最大值：64 位全部为 1。
    var u atomic.Uint64
    u.Store(^uint64(0))
    fmt.Println("unsigned:", u.Add(1))

    // 先右移无符号最大值，再转换为可表示的有符号最大值。
    var s atomic.Int64
    s.Store(int64(^uint64(0) >> 1))
    fmt.Println("signed:", s.Add(1))

    // 无符号加上全 1，相当于按模运算减一。
    var down atomic.Uint64
    fmt.Println("decrement zero:", down.Add(^uint64(0)))

    // 有符号类型可以直接传入负增量。
    var signed atomic.Int64
    fmt.Println("signed decrement:", signed.Add(-1))
}

unsigned: 0
signed: -9223372036854775808
decrement zero: 18446744073709551615
signed decrement: -1

Uint64.Add 的参数本身是 uint64，不能直接写 Add(-1)，因为常量 -1 不能表示为 uint64。用 ^uint64(0) 表示全 1 位的无符号值，才是这里的减一写法。它不是“禁止下溢”的特殊接口：从零减一仍会回到最大值。

还要区分常量表达式和运行时运算。把一个超出 int64 范围的常量强行赋给 int64，编译阶段就可能被拒绝；这与一个已经存入 atomic.Int64 的运行时值经 Add 发生溢出不同。不能用前者的编译错误证明后者会 panic。

受益场景：先看业务允许哪些值

做累计次数统计时，Uint64 的非负表示通常容易理解，但如果业务要求计数永远单调增长，就必须另外决定到达上界后的处理。做允许负增量的差值或库存变化统计时，Int64 更容易表达方向，但有符号不代表自动限制数值范围。

若用计数生成标识符，溢出后会重新进入旧数值范围，atomic 只解决并发更新，不能承诺永久不重复。余额或不能为负的库存同样不能仅靠选 Uint64 保证业务正确：从零减一得到最大值并不是一个有效余额。

风险：Add 的新值不等于随后 Load 必须读到同一个值

在 newValue := counter.Add(1) 中，newValue 属于这一回原子加法，它不会被别的 goroutine 追改。随后执行 observed := counter.Load()，则又进行了一次独立读取。在这两次操作之间，其他 goroutine 可能已经 Add 或 Store，所以 observed 与 newValue 不相等并不异常。

反过来，不能通过两个读数相同就推断期间没有更新：值可能被修改后又恢复，或在环绕后重新出现。同样不要把一次原子读取误解为一组字段的业务快照。本文只讨论这个整数变量的读取与加法语义。

“先 Load 判断小于上限，再 Add”也不是整体原子的边界检查。多个 goroutine 可以在检查后继续修改共享值。需要拒绝、饱和或重置等策略时，应把业务条件与更新设计为一个一致的协议；不要把普通的检查加累加当成已有保证。

采用路径：把边界写进计数器约定

先说明值是否允许为负、是否允许环绕、上限到达后要报错还是保持上限。再决定使用哪种整数表示，并规定消费者读取的是 Add 返回的新值，还是独立 Load 时的当前值。对报表或速率采样，还要明确差值计算遇到环绕后的解释，避免把下降直接当成丢失更新。

观察指标可以围绕“距离上界的余量”“是否出现业务禁止的负值”“重置与环绕次数”设置。这里不提供固定报警阈值：不同增量速度和生命周期需要不同余量。对无法容忍重复或回绕的业务，不能以“64 位很大”替代边界政策。

常见问题

原子操作会帮我检测溢出吗？

这两个 Add 方法返回新整数值，没有额外的溢出错误返回值。需要检测时应在业务更新协议中实现，不要期待 panic 提醒。

换成 Int64 能避免 Uint64 回到零吗？

不能。它改变的是可表示范围与溢出后的解释；正数上界还会更小，越界后变成负数。

Load 读到负数意味着读了一半吗？

对正确使用的 atomic.Int64，负数可能是正常存储值，也可能是运行时溢出的结果。仅凭符号不能判断读取损坏，应追查增量与边界。

参考：sync/atomic 官方类型与方法文档；Go 语言规范：整数溢出。