system.currenttimemillis()可实现轻量级单机限流：固定窗口法用时间戳取整确定窗口键，map计数；滑动窗口法用列表记录时间戳并动态清理超时记录。
用 System.currentTimeMillis() 实现限流，核心是利用时间戳判断请求是否在允许的时间窗口内，适合轻量级、单机场景，不需要额外依赖。
固定窗口限流（最简实现）
把时间划分为固定长度的窗口（比如 1 秒），统计每个窗口内的请求数。每次请求到来时，检查当前窗口的计数是否超限。
- 用
currentTimeMillis()计算当前窗口起始时间：比如窗口 1 秒，就用timestamp / 1000 * 1000得到当前秒级时间戳 - 用 Map 存储窗口 → 请求次数，key 是窗口开始时间（如 1717023600000），value 是计数
- 超过阈值（如 10 次/秒）就拒绝，否则计数 +1
- 注意：窗口边界切换时不会自动清零，需靠 key 自然轮换，或手动清理过期 key（可选）
滑动窗口的简易模拟
严格滑动窗口需维护多个时间桶，但用 currentTimeMillis() 可低成本近似：保留最近 N 个时间点，每次请求时剔除超时记录。
- 用
ArrayList<long></long>或LinkedList记录每次成功请求的时间戳 - 请求到来时，先遍历并移除早于
currentTime - windowSizeMs的时间戳 - 再判断剩余数量是否
- 优点是逻辑清晰、无外部依赖；缺点是高并发下 list 遍历开销略大，适合 QPS 不高的服务
令牌桶的简化版（按需生成）
不维护独立线程填充令牌，而是每次请求时根据时间差“算出”应有令牌数，再决定是否发放。
- 记录上一次更新时间和当前令牌数
- 新请求来时，计算距上次更新的毫秒差，按速率（如 10 个/秒 → 1 个/100ms）折算新增令牌
- 取整后累加到当前令牌池，上限为桶容量；若令牌 ≥ 1，则消耗 1 个并放行
- 关键：所有计算基于
System.currentTimeMillis()，无锁操作，线程安全靠原子变量或 synchronized 块
注意事项与优化点
单纯依赖系统时间可能存在隐患，实际使用中需留心：
- 服务器时间跳变（如 NTP 校准）会导致窗口错乱或令牌突增，可加入时间单调性校验（如对比前后两次调用是否倒退）
- 高频调用
currentTimeMillis()开销极小，但避免在循环内反复调用，提取一次复用 - 单机限流无法跨进程生效，集群场景需结合 Redis 等共享存储，此时
currentTimeMillis()仅用于客户端本地辅助判断 - 测试时注意 JVM 时钟精度（尤其旧版本），必要时用
System.nanoTime()辅助做相对时间测量
