Go atomic.Int64 统计并发指标的读取一致性

Go atomic.Int64 能保证单次 Add、Load 等操作的原子性，但连续读取多个计数器不会自动得到同一时刻的整体快照。并发指标可以按字段采样；如果要严格维持“已开始减已结束等于正在执行”等跨字段关系，就必须额外协调所有相关写入和读取，而不是只把字段换成 atomic.Int64。

官方文档：https://pkg.go.dev/sync/atomic

先做一个只有三个指标的小程序

设想一个任务执行器，需要知道累计开始数、累计结束数和当前执行数。它们看起来可以互相推导，但更新发生在不同位置，采样又可能与工作goroutine交错。小项目的目标就是区分两件事：单个计数器不会因为并发加法而丢失更新，不代表三个读数必然满足同一个瞬间的业务等式。

准备一个支持atomic.Int64的Go工具链，该类型从Go 1.19起提供。代码只依赖标准库，不需要数据库、HTTP服务或第三方监控平台。三个字段的零值可以直接使用，累计计数只做正向加法，active在任务进入和退出时加减。

所有goroutine共享同一个Metrics指针

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

type Metrics struct {
    started  atomic.Int64
    finished atomic.Int64
    active   atomic.Int64
}

type Sample struct {
    Started  int64
    Finished int64
    Active   int64
}

// 使用指针共享同一个指标对象，首次使用后不要复制Metrics。
func (m *Metrics) task() {
    m.started.Add(1)
    m.active.Add(1)
    defer m.active.Add(-1)

    // 这里是教学用任务占位，不代表实际业务、耗时或成功率。
    m.finished.Add(1)
}

func (m *Metrics) sample() Sample {
    // 每次Load各自原子；这三个读取不构成同一时刻的整体快照。
    started := m.started.Load()
    finished := m.finished.Load()
    active := m.active.Load()
    return Sample{Started: started, Finished: finished, Active: active}
}

func main() {
    metrics := &Metrics{}
    var wg sync.WaitGroup
    const workers, jobs = 8, 125

    for i := 0; i 

把这段原创示例保存为main.go后，可以在终端执行下面的命令。本文未运行代码，也不提供伪造的运行截图或性能数据。

# 在示例文件所在目录运行，观察运行期采样与结束后统计的区别
go run main.go

程序启动8个工作goroutine，每个执行125次计数任务。依据代码，正常完成且没有整数溢出时，等待结束后的累计开始和累计结束都应为1000，active应为0。这是预期结果，不是本机实测输出。第一行采样可能发生得很早，也可能在工作已全部完成后发生，不能要求它必定出现某组中间数字。

task中的defer使正常返回路径上的active减法与加法配对。这里finished只表示教学任务走到结束计数点，不代表真实业务成功。如果以后添加错误返回，要先规定“结束”是否包含失败，并把计数位置放到符合该定义的地方；原子操作不会替你定义指标口径。

为什么采样值可能不满足字段等式

sample按顺序读取started、finished、active，每次Load都只对自己的字段负责。假设采样先取得started为5，随后工作goroutine又开始并结束一个任务，接着采样取得finished为6，这一对读数就不能当作同一瞬间的数据。它不需要发生数据竞争，也不意味着某个原子值被“读坏”了。

Go内存模型为原子操作提供顺序一致的语义，但这不是把多个Load自动合并成一次事务。另一个限制来自写入本身：task先更新started再更新active，两次操作之间同样存在可被观察的间隔。因此，仅改变读取顺序，或者先读一遍再读一遍，都不能在没有完整协议的情况下保证整体快照。

如果看板只是展示趋势，接受这种逐字段观察通常比较直接。若业务逻辑必须依据一组严格一致的字段做决策，就不能把看板采样值直接当成扣费、配额或结算依据。应让所有相关更新与整体读取遵守同一把锁，或者交给单一拥有者集中管理；只给读取者加锁、写入者仍然各自原子更新，并没有建立共同保护范围。

累计计数怎样用于周期采样

累计finished适合在两个采样点之间取差，增量除以两个实际采样时间之间的秒数，得到该观察区间的平均完成速率。定时器不是精确的业务时钟，采集和调度会引入间隔变化，不应永远用配置中的“1秒”硬除。采样时间最好与读数一起保存，并说明它是观察点，不是整个任务集合的精确边界。

如果后一次值小于前一次值，先检查进程重启、指标对象替换、主动重置或溢出等原因，不要直接报告负吞吐。累计计数也不适合每次采样后清零，尤其当多个采集器共享同一个字段时，一个采集器的重置会改变其他采集器的含义。

确实需要单个区间计数器时，Swap(0)可以把取旧值和置零作为一次原子操作；Load后再Store(0)则可能覆盖两者之间的新增加法。但Swap只解决一个字段的取数清零，两个字段分别Swap仍然不是共同区间快照。本文的示例保持累计值不重置，避免把不同采样契约混在一起。

接入服务前要保留哪些约束

atomic.Int64首次使用后不能复制，所以Metrics使用指针接收者，工作goroutine共享同一个指针；采样返回的是只含普通int64的Sample副本，而不是复制原子对象。集成到实际服务时，指标对象应具有清晰的进程或组件生命周期，不要每个请求都重新创建，也不要在map或切片重组过程中误复制已使用的指标实例。

还要区分可观测性与性能承诺：原子计数没有让程序自动获得吞吐提升，高争用的共享计数器也有成本。本文未给出性能对比，不由“使用了atomic”推导它必然优于其他同步方式。Int64也不是无限大的计数器，应根据运行时长和增长规模考虑溢出与重启口径。

常见问题

把Load结果加一再Store回去可以吗？

并发累加应使用Add(1)。分开的读取和写入即便各自原子，也可能让多个写入者覆盖彼此计算出的结果。

运行期finished大于started一定是错误吗？

先看是否把不同采样时刻的字段拼成了一组。本文的读取顺序允许这种观察组合；如果停止所有写入后仍违背预期，再检查更新口径、对象复制或其他逻辑。

用race检测能证明快照一致吗？

不能。数据竞争和跨字段业务一致性是不同问题；全部使用原子操作，也仍需要明确多字段观察契约。

这个小程序最终要留下的不是三个“线程安全”的字段名，而是两套清楚的语义：运行期逐字段采样用于观察，所有写入结束后的统计用于核对最终计数。需要更强的一致性时，再为整个状态设计共同的同步边界。

Go内存模型：https://go.dev/ref/mem。