Golang 内存滑动窗口计数器实现

本文深入剖析了Golang中滑动窗口计数器的正确实现原理，直击用map+定时清理这一常见方案在并发安全、时间精度、内存管理上的致命缺陷——如panic、锁争用、整点对齐导致的统计失真和隐性内存泄漏；并权威推荐基于环形数组与原子操作的高性能真滑动方案，强调预分配槽位、懒清理机制、严格整除的时间分片设计，以及单机/多实例场景下的合理演进路径（分片原子计数器或Redis+ZSET），尤其警示slotDuration选取、时间戳比对等易被忽视却极易引发静默错误的关键细节，为高可靠限流、监控与统计系统提供扎实落地指南。

滑动窗口计数器不能靠 map + 定时清理凑合，否则任意时刻往前推 N 秒的统计值必然不准——漏掉的时间段不会自己跳出来。

为什么 map[string]int + time.Ticker 不行

看似简单：每秒清一次过期 key，新请求往 map 里塞。但问题扎堆：

• 多个 goroutine 并发写 map 直接 panic：concurrent map read and map write
• 加 sync.RWMutex 后，高并发下锁争用严重，实测 QPS 断崖下跌
• 定时清理是“整点对齐”，比如窗口 60 秒、清理在整秒触发，那 1717023400～1717023449 这 50 秒的请求全被提前删掉，新请求还没来得及归入当前窗口
• time.Now() 作 key 会导致内存持续增长，不清理就 OOM；清理又不准，本质是把滑动窗口降级成了固定窗口

用环形数组 + 原子操作实现低开销真滑动

核心是预分配、免锁、懒清理。推荐结构体字段：slots []uint64、timestamps []int64、slotDur（毫秒）、windowDur（毫秒）。

• 数组长度 = windowDur / slotDur，必须整除；例如 60 秒窗口配 1 秒分片 → 长度 60
• 每个 slot 存该时间片内的请求数，用 atomic.AddUint64(&c.slots[i], 1) 更新，禁止直接 c.slots[i]++
• shift() 不在每次 Inc() 里遍历全部 slot，而是只检查当前 slot 是否已过期；过期则归零、更新时间戳、移动索引
• timestamps[c.currentIndex] 必须存该 slot 的起始时间戳（非 now），用于和 now - windowDur 比较判断是否过期
• 并发安全靠 sync.RWMutex 包住 shift() 和索引更新，atomic 管计数，别全锁整个结构体

什么时候该换方案：单机扛不住或要跨实例

纯内存环形数组适合单实例、QPS ≤ 5k 场景。超了或需多实例共享状态，就得换：

• 单机高频（>10k QPS）且维度少：改用分片原子计数器 —— 开 N 个 int64 变量（N ≈ CPU 核心数），按 key 哈希取模写入对应分片，读时遍历求和
• 多实例部署：必须上 Redis + ZSET，用 Lua 脚本保证原子性；ZCOUNT + ZADD + ZREMRANGEBYSCORE 三步不可拆，且所有时间戳必须用 redis.call("TIME") 获取服务端时间，禁用客户端 time.Now()
• 别碰 sync.Map 存时间片 —— 它为读多写少设计，滑动窗口频繁更新+遍历，性能反不如分片 map + 独立 sync.RWMutex

真正难的不是写对逻辑，而是 slotDuration 选多细、windowDur 和 slotDur 整除关系是否严格满足、以及 shift 里时间比较是否用绝对时间戳而非相对索引差——这三个点线上出问题几乎都是静默错，压测不出，只在特定时间点漏统计。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang 内存滑动窗口计数器实现》文章吧，也可关注golang学习网公众号了解相关技术文章。