currenttimemillis仅提供毫秒级时间戳，精度有限，不能直接精准控制滑动窗口；精准实现需结合队列管理、统一时间快照、过期清理逻辑及边界定义等设计。
currentTimeMillis 本身不能精准控制滑动窗口，它只是提供毫秒级时间戳；真正实现精准滑动窗口需要结合逻辑设计、状态管理和合理的时间计算。
理解 currentTimeMillis 的定位
System.currentTimeMillis() 返回自 1970-01-01 00:00:00 UTC 起的毫秒数，精度受系统时钟影响（通常为 10~15ms），不是高精度计时器。它适合粗粒度时间判断（如“过去 1 分钟内”），但不适合亚毫秒级或强实时性场景。
滑动窗口的核心是：维护一个动态的时间范围（如最近 60 秒），并持续剔除过期事件。关键不在“获取时间”，而在“如何用时间做边界判定和清理”。
基于 currentTimeMillis 实现滑动窗口的典型方式
常见做法是用队列（如 ConcurrentLinkedQueue 或 ArrayDeque）+ 时间戳标记，配合 currentTimeMillis 做实时过滤：
- 每来一个事件，记录其到达时间（用 currentTimeMillis() 打标）并入队
- 每次需统计/触发时（如检查窗口内请求数），从队头开始遍历，用
currentTimeMillis() - event.timestamp > windowSizeMs判断是否过期，过期则出队 - 剩余队列长度即为当前窗口内有效事件数
示例（简化版）：
private final Queue<long> window = new ArrayDeque();
private final long windowSizeMs = 60_000; // 60秒
<p>public void onEvent() {
window.offer(System.currentTimeMillis());
// 清理过期事件
long now = System.currentTimeMillis();
while (!window.isEmpty() && now - window.peek() > windowSizeMs) {
window.poll();
}
}</p>
<p>public int countInWindow() {
return window.size();
}</p></long>
提升“精准性”的实用要点
所谓“精准”，实际指窗口边界行为可预期、无明显漂移。注意以下细节：
-
避免在循环中反复调用 currentTimeMillis()：多次调用可能返回不同值，导致逻辑不一致。应先缓存一次
long now = System.currentTimeMillis()，后续判断统一用它 -
窗口边界定义要明确：是“最后 N 毫秒内”还是“以当前时刻为右端点的闭区间”？推荐后者，即只保留
timestamp >= now - windowSizeMs的事件 - 高频写入时考虑性能：若每毫秒进百个事件，频繁遍历队列开销大。可改用分段桶（如按秒切片）、或引入定时清理线程（但需注意线程安全）
-
注意时钟回拨风险：系统时间被手动或 NTP 调整后退，会导致大量事件误判为“未过期”。生产环境建议用
System.nanoTime()做相对耗时，或引入单调时钟库（如 net.time4j.base.WallTime）
什么情况下不该用 currentTimeMillis 做窗口？
当有以下需求时，应换更合适的方案：
- 需要亚毫秒精度（如微秒级限流）→ 改用
System.nanoTime()+ 自定义基准时间 - 跨进程/分布式窗口 → 需借助 Redis ZSET（按时间戳排序）或 Flink / Kafka Streams 等流处理引擎
- 严格按固定周期滚动（如每分钟整点清零）→ 用定时任务对齐时间边界，而非纯依赖事件时间戳
不复杂但容易忽略。
