Go sync/atomic.Uint64 计数器怎么做并发统计：读写边界、溢出与快照一致性

接口请求量从每秒几百涨到几万后，把一个普通整数塞进共享结构体，最先出问题的往往不是计算，而是并发读写。Go 的 sync/atomic.Uint64 能把这个场景压缩成几行清楚的代码：写入用 Add，读取用 Load，需要取走当前值并重新计数时用 Swap。它解决的是单个数值的原子性，不会自动让一组指标变成同一时刻的事务快照。

高并发计数为什么先从一个 Uint64 开始

假设服务只需要记录收到的请求数。用普通 uint64 配合 counter++，多个 goroutine 会同时读出旧值、各自加一，再把结果写回去，最终计数小于真实请求数。给它加互斥锁可以修复竞争，但每次请求都要经过锁；如果这个数字只用于轻量观测，原子计数通常更合适。

package main

import "sync/atomic"

type RequestStats struct {
	total atomic.Uint64
}

func (s *RequestStats) Inc() {
	s.total.Add(1)
}

func (s *RequestStats) Total() uint64 {
	return s.total.Load()
}

这里的重点是让 RequestStats 只暴露行为，不把内部字段交给调用方。Inc 每次原子加一，Total 读到的是某个时刻已经完成的值；它不是“暂停所有写入后拍照”，所以读取期间仍可能有新请求到达。

从单机统计扩展到按时间窗口取数

如果监控每分钟需要取出这一分钟的请求量，单纯 Load 会拿到进程启动以来的累计值。此时可以用 Swap(0)：它一次性返回旧值，并把计数器置零。新请求不会因为清零而被抹掉，它们会落入下一个窗口。

type WindowCounter struct {
	hits atomic.Uint64
}

func (c *WindowCounter) Hit() {
	c.hits.Add(1)
}

func (c *WindowCounter) Take() uint64 {
	return c.hits.Swap(0)
}

要注意窗口边界：Take 返回的数字只代表“交换发生前已经完成的加法”。如果业务要求严格按自然分钟对齐，还需要在采集端记录交换时间，并接受边界瞬间的归属规则；不要把它误写成精确的分布式分钟统计。

计数器方法与规模化取舍

单个指标用一个原子值很轻；当指标扩展为成功数、失败数、耗时总和三个字段时，三个 Load 之间可能被请求插入。若消费方只需要趋势图，这种近似快照通常够用；若要做计费或对账，应该把状态放进互斥保护的结构，或设计带版本号的发布协议。

并发验收：确认没有竞争和意外回绕

测试不要只在单 goroutine 下比较结果。让多个 goroutine 各自增加固定次数，最后用 Load 与理论总数比较，并使用竞态检测器运行测试。

func TestRequestStats(t *testing.T) {
	const workers, each = 8, 10000
	var stats RequestStats
	var wg sync.WaitGroup
	for i := 0; i 

验收时至少跑一次 go test -race ./...。竞态检测器能发现普通字段的并发读写，但它不能证明你的窗口边界符合业务定义，也不能替你判断多字段快照是否可用于结算。

uint64 快到上限时怎么办

Uint64 的最大值是 18446744073709551615。继续 Add 后会回到较小的数，这是语言层面的无符号回绕，不会抛异常。长时间运行的服务不应等到监控图突然归零才处理，可以在读取时设阈值，或按窗口用 Swap(0) 把累计量控制在较小范围。

如果业务必须得到永不回绕的总量，就不要让原子值承担无限增长的语义：接近上限时停止累加并记录告警，或者把多个窗口值交给支持大整数/持久化的统计层。只把 uint64 换成带锁的大整数并不能自动解决跨进程、重启和落盘问题。

相关问题

Load 能不能同时读取多个计数器？

可以分别读取，但多个结果不保证来自同一个瞬间。需要严格一致时，应把它们放到统一的同步协议里。

Swap(0) 会不会漏掉交换瞬间的请求？

不会漏掉已经完成的原子加法；交换之后发生的加法会进入新窗口。边界归属需要在业务上明确。

atomic.Uint64 能替代所有互斥锁吗？

不能。它适合独立数值的原子读写，涉及多个字段、条件检查加修改或复杂不变量时仍应使用锁或更高层协议。

把计数器留在它擅长的范围

把 atomic.Uint64 封装成少量明确方法，再用 Load 或 Swap 对齐读数目的，代码通常就足够稳。真正需要警惕的是把一个轻量观测工具误当成事务快照、持久化总账或跨节点聚合器；边界写进接口和测试，后续扩展指标时才不会悄悄改变统计含义。