滑动窗口计数器用std::atomic+环形数组实现，以单调时钟计算槽位、延迟清理避免突变，读写无锁且线程安全。
用 std::atomic + 环形数组实现基础滑动窗口
滑动窗口计数器本质是统计最近 N 秒内请求次数，C++ 没有现成的线程安全滑动窗口容器，得自己搭。核心思路是：固定大小数组存每秒计数，用原子变量滚动更新——既避免锁竞争，又保证读写可见性。
常见错误是直接用 std::vector<int></int> 配 std::mutex，一来每次访问都要锁，二来窗口滑动时清零整段内存，性能差；更糟的是，若清零和累加没同步，会出现计数丢失或重复。
- 窗口长度建议用编译期常量（如
constexpr size_t WINDOW_SIZE = 60），避免运行时动态分配 - 数组类型必须是
std::atomic<int></int>，不能是int数组再套锁——否则fetch_add不原子 - 时间槽索引用
timestamp % WINDOW_SIZE，但注意：系统时间可能回跳，生产环境应使用单调时钟（如clock_gettime(CLOCK_MONOTONIC, ...)）
示例关键片段：
std::array<std::atomic<int>, 60> counts;
int get_current_slot() {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return ts.tv_sec % 60;
}
窗口滑动时如何避免计数突变？
“滑动”不是移动数据，而是逻辑上切换当前活跃槽位。问题在于：旧槽清零时机不对，会导致短时间计数归零（比如刚切到新槽，就立刻把上一秒的槽置 0，但上一秒的请求还没全写完）。
立即学习“C++免费学习笔记（深入）”；
根本解法是「延迟清理」：不主动清零，而是在读总数时，只累加最近 WINDOW_SIZE 个槽的值；写操作永远只改当前槽。这样读写完全无锁，且天然容忍写入延迟。
- 读操作（如判断是否限流）必须遍历全部槽位，不能只读当前槽——否则会漏掉前几秒的请求
- 遍历时用
.load()显式读取每个std::atomic<int></int>，别依赖隐式转换 - 如果窗口很大（如 3600 秒），遍历开销明显，此时应换分层结构（如按分钟聚合），但那是另一层权衡
std::shared_mutex 在什么情况下值得引入？
纯原子操作适合读多写少、窗口小（≤100）、精度要求为秒级的场景。一旦需要毫秒级窗口、或支持动态调整窗口大小、或要导出各时间槽明细，std::atomic 就不够用了——因为无法原子地更新多个槽+元信息。
这时可降级用读写锁：std::shared_mutex 允许多读单写，比普通 std::mutex 更友好。但要注意：写操作（如重置窗口、调参）仍是阻塞的，不能在高频请求路径里触发。
- 仅当有外部管理需求（如运维接口动态改限流阈值）才加
std::shared_mutex - 读路径仍优先走无锁原子版本；加锁只用于非常规操作
- 别用
std::shared_timed_mutex（C++14）——它在某些旧 libc++ 上性能反不如普通 mutex
为什么不要用 std::chrono::system_clock 做槽索引？
因为系统时间会被 NTP 或手动校正，出现跳变。比如 system_clock::now().time_since_epoch().count() 突然倒退 2 秒，你的槽索引就会乱跳，导致同一秒的请求被写进两个不同槽，或某槽被跳过。
单调时钟（CLOCK_MONOTONIC）不随系统时间调整，只随真实流逝增加，是唯一可靠选择。Linux/macOS 都支持，Windows 可用 QueryPerformanceCounter 替代。
- 别试图用
system_clock加补偿逻辑——时钟跳变检测本身就有竞态 - 获取时间戳必须在写入计数前完成，且不能缓存多次写入共用一个时间戳
- 如果进程需跨机器协同限流（如分布式场景），那本地滑动窗口就不适用了，得换 Redis + Lua 或专用服务
真正麻烦的从来不是怎么写对，而是怎么让多个线程对“当前属于哪一秒”的认知始终一致——时钟源选错，后面全白搭。
