滑动窗口统计不能直接用大量goroutine，因其缺乏时间边界控制，易致内存暴涨和竞态；应采用中心化结构（如分桶+原子计数）配合少量goroutine定时刷新，并严格管理goroutine生命周期。
滑动窗口统计为什么不能直接用 goroutine 堆数量
goroutine 本身不提供时间窗口或数据边界控制能力。你起 1000 个 goroutine，它们各自独立运行，没法自动“过期”或“聚合最近 N 秒的数据”。真这么干，不仅内存暴涨，还会因调度开销和竞态导致结果错乱。
真正可行的方案是：用一个中心化的滑动窗口结构（比如环形缓冲区或时间分桶），配合少量 goroutine 做定时清理、写入或查询 —— goroutine 是工具，不是窗口本身。
用 time.Ticker 驱动周期性窗口刷新
适合固定时间窗口（如“每 5 秒统计一次过去 30 秒的请求数”）。关键在于避免每次 tick 都遍历全量数据，而是用分桶（bucket）+ 原子计数减少锁竞争。
- 把总窗口切分为多个等长子区间（例如 30 秒窗口分 6 个 5 秒 bucket），每个 bucket 存原子计数器
- 用
time.Ticker每 5 秒推进一次当前写入位置，并清零最老 bucket - 统计时只加总当前活跃的 bucket（不用锁，读是并发安全的）
type SlidingWindow struct {
buckets []int64
mu sync.RWMutex
idx int
ticker *time.Ticker
}
func (w *SlidingWindow) Inc() {
w.mu.Lock()
atomic.AddInt64(&w.buckets[w.idx], 1)
w.mu.Unlock()
}
func (w *SlidingWindow) Sum() int64 {
w.mu.RLock()
defer w.mu.RUnlock()
var total int64
for i := range w.buckets {
total += atomic.LoadInt64(&w.buckets[i])
}
return total
}
// 启动刷新 goroutine
go func() {
for range w.ticker.C {
w.mu.Lock()
atomic.StoreInt64(&w.buckets[w.idx], 0)
w.idx = (w.idx + 1) % len(w.buckets)
w.mu.Unlock()
}
}()
用 sync.Map + 过期时间做请求级滑动窗口
当需要按单个 key（如用户 ID）做独立窗口，且窗口基于“最近 N 次”或“最近 N 秒内”事件时，sync.Map 配合时间戳字段更灵活。但注意：sync.Map 不支持自动驱逐，必须自己处理过期。
- 存键值对：
key → struct{ ts time.Time; count int } - 每次访问先检查
ts是否超时，超时则删掉（用LoadAndDelete） - 写入新事件时更新
ts和count，用LoadOrStore避免重复初始化 - 不要在每次查询时遍历全量 map 清理 —— 改为另起一个低频 goroutine（如每秒一次）扫描并删除过期项
高频写入场景下，这种方案比全局锁分桶更省内存，但查询延迟略高，且无法精确保证“严格最后 N 秒”，因为过期检查是懒执行的。
goroutine 泄漏风险：别让窗口管理 goroutine 永不退出
上面所有例子都隐含一个关键点：窗口生命周期必须可控。如果 ticker 或清理 goroutine 启动后没提供关闭机制，服务重启或配置变更时就会累积 goroutine。
- 给
SlidingWindow加Close()方法，调用ticker.Stop()并等待 goroutine 退出（可用sync.WaitGroup或context.WithCancel） - 避免在 http handler 里临时起 goroutine 做窗口操作 —— 它们可能随请求结束但 goroutine 还在跑
- 用
pprof/goroutine定期检查异常增长，尤其上线后突增的runtime.gopark数量
滑动窗口真正的复杂点不在“怎么算”，而在“怎么收口”—— 时间精度、内存水位、goroutine 生命周期，三者必须同时考虑，漏掉任何一个，线上就容易出毛刺或 OOM。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
