滑动窗口限流器实战：Java实现与高并发避坑指南

限流这个词，做后端的朋友应该都不陌生。我最初接触限流是因为一次线上事故：某个活动接口在开售瞬间被超高并发流量打穿，数据库连接池直接耗尽，整个服务雪崩。复盘的时候发现，当时网关虽然配了一个固定的每秒请求限制，但那个限制在临界点附近等于形同虚设。后面我花了一个晚上，手写了一个单机滑动窗口限流器，替换掉原来的固定窗口方案，才彻底解决尖峰流量穿透的问题。今天就把这个限流器的设计思路、Java实现细节和落地时踩过的一堆坑完整记录下来，给需要自己做限流的同学一个参考。

这篇内容适合正在做服务端开发的同学，尤其是接口保护、秒杀系统、API网关这类对瞬时流量敏感的场景。文章不会只给一个能跑的最小实现，而是会把“为什么用滑动窗口”“怎么选桶的数量”“并发竞争怎么处理”这些关键问题讲透。

1. 限流是必须要做，但选对算法更关键

1.1 什么样的场景需要单机限流

限流的本质是“在容量不足时保护系统”，而不是“精确统计请求数量”。单机限流解决的是单个服务实例的自我保护问题。比如说，你的服务部署了10个节点，前面有负载均衡分发流量，但某一天某个热点商品出了问题，流量偏偏就集中打到了其中的一个实例上。这时候，网关的全局限流拦不住它，因为全局限流关注的是总量，而不是单台机器的负载。

单机限流器在这种场景下是最后一道防线，保证任何一个实例都不会因为瞬时超载而被打垮。常见的触发场景包括：外部回调流量异常、爬虫没有遵守规则地高频抓取、代码缺陷导致循环调用、还有秒杀开始的那一刻流量突然暴涨。这些场景有一个共同点：你无法提前准确预测流量峰值，必须靠本地的限流组件兜底。

1.2 为什么滑动窗口比固定窗口更靠谱

先看固定窗口算法。它的逻辑很简单：把时间切成固定大小的片段，比如每1秒一个窗口，每个窗口最多放行N个请求，窗口切换时计数清零。这个方案实现简单、性能极好，但有一个臭名昭著的临界突刺问题。

具体来说：假设你限制每秒100个请求。在第1秒的最后100毫秒，来了100个请求，全部放行。然后紧跟着第2秒开始的最初100毫秒，又来了100个请求，固定窗口因为计数清零了，所以也全部放行。结果就是，在短短200毫秒的时间窗内，实际通过了200个请求，是设定阈值的两倍。如果恶意请求方精确踩在窗口切换点上打流量，固定窗口限流完全丧失意义。

滑动窗口算法解决这个问题的思路很直接：窗口不是从自然秒的边界开始，而是从每个请求到达的时间往前回溯。例如限制1秒100个请求，那么任意一个请求到达时，它往回看1秒内的请求数量如果已经达到100，就拒绝这个请求。这样窗口边界是跟着时间连续滑动的，临界点的突刺被摊平了。

1.3 滑动窗口、令牌桶、漏桶的适用边界

后端常见的限流算法有固定窗口、滑动窗口、令牌桶和漏桶。我用一张表整理一下它们在单机场景下的表现。

令牌桶允许一定程度的突发流量，比如桶里积攒了N个令牌，高峰期可以一次性消耗，适合很多对毛刺不敏感的业务。漏桶则强制恒定速率，实现上往往是队列加调度器，本质上会引入排队延迟。滑动窗口则是追求“短时间内不能超过某个阈值”的精确控制，尤其适合活动秒杀这种对集中流量非常敏感的场景。我最后选了滑动窗口，就是因为活动场景最怕的不是速率不稳，而是某一个瞬间突然涌入超出负载能力的流量。

2. 单机滑动窗口限流器的设计与实现

2.1 核心数据结构：窗口是怎么“滑”的

滑动窗口的朴素实现是在内存里记录每个请求的时间戳，每次新请求进来时，把窗口之前的旧时间戳全部移除，然后统计剩余数量。这个做法叫滑动日志，准确是准确，但有两个问题：一是时间戳列表会随着并发量增大占用大量内存，二是移除旧时间戳是O(N)操作，高并发下会成为瓶颈。

所以工程上更通用的做法是分桶。把整个窗口切成K个小格子，每个格子记录这个小时间段内的请求数量。比如窗口是1000毫秒，切成10个格子，每个格子代表100毫秒。窗口滑动的时候，实际上就是把已经过期的小格子的计数丢弃，再在当前时间对应的小格子里累加。

要理解滑动窗口的核心，必须先理解“桶序号”这个概念。假设桶的大小是100毫秒，那么从1970年开始到现在，按100毫秒一个单位切分，每个请求都落在某个整数编号的桶里。现在时间为T，我们只需要关心编号从T/100 - K + 1到T/100这K个桶，凡是编号更早的桶，它们的数据已经滑出窗口，直接忽略。

2.2 第一版：滑动日志实现（原理演示）

先写一个最直观的版本。用双端队列保存每个请求的时间戳，每次请求进来时，把队头已经超出窗口的时间戳清掉。

public class SlidingLogRateLimiter { private final Deque<Long> requests = new LinkedList<>(); private final long windowSizeMillis; private final int maxRequests; public SlidingLogRateLimiter(long windowSizeMillis, int maxRequests) { this.windowSizeMillis = windowSizeMillis; this.maxRequests = maxRequests; } public synchronized boolean tryAcquire() { long now = System.currentTimeMillis(); long windowStart = now - windowSizeMillis; while (!requests.isEmpty() && requests.peekFirst() < windowStart) { requests.pollFirst(); } if (requests.size() >= maxRequests) { return false; } requests.addLast(now); return true; } }

这个版本逻辑清晰，适合理解滑动窗口的含义。但它的缺陷也很明显：每一个放行的请求都会在内存里留下一个时间戳对象；在QPS上万的时候，这个队列的写入、淘汰、加锁开销非常可观。而且它统计的是精确数量，如果窗口是1000毫秒、限制1000个请求，就意味着要维护一个长度最高1000的队列，内存和GC压力全都上来了。生产环境我一般不建议直接用这个写法，除非限制的QPS很低，比如每秒几十的级别。

2.3 第二版：分桶环形数组实现（生产首选）

分桶方案用固定长度的数组替代动态增长的队列，内存占用恒定，统计速度也稳定。核心思想是：用一个长度为K的数组保存K个桶的计数，另外用一个数组保存每个桶对应的起始时间戳。当请求进来时，先计算出当前时间属于哪个桶，然后判断窗口内所有未过期桶的总数是否超限。

public class SlidingWindowRateLimiter { private final int bucketCount; private final long windowSizeMillis; private final int maxRequests; private final long bucketSizeMillis; private final long[] buckets; private final long[] bucketStartTimes; public SlidingWindowRateLimiter(int bucketCount, long windowSizeMillis, int maxRequests) { this.bucketCount = bucketCount; this.windowSizeMillis = windowSizeMillis; this.maxRequests = maxRequests; this.bucketSizeMillis = windowSizeMillis / bucketCount; this.buckets = new long[bucketCount]; this.bucketStartTimes = new long[bucketCount]; Arrays.fill(bucketStartTimes, -1); } public synchronized boolean tryAcquire() { long now = System.currentTimeMillis(); long nowBucket = now / bucketSizeMillis; long windowLowerBound = nowBucket - bucketCount + 1; int currentIndex = (int) (nowBucket % bucketCount); long total = 0; for (int i = 0; i < bucketCount; i++) { if (bucketStartTimes[i] >= windowLowerBound) { total += buckets[i]; } } if (bucketStartTimes[currentIndex] != nowBucket) { bucketStartTimes[currentIndex] = nowBucket; buckets[currentIndex] = 0; } if (total >= maxRequests) { return false; } buckets[currentIndex]++; return true; } }

解释几个关键细节。

关于环形数组的复用安全性：因为数组下标是nowBucket % bucketCount，当前桶序号和同一个下标上一次存储的桶序号之间，必然相差K的整数倍。在正常单调递增的时间流中，上一个存储的桶序号一定是nowBucket - K，而这个值一定小于windowLowerBound = nowBucket - K + 1，也就是说它已经滑出了窗口，可以安全清零。这个性质决定了代码里那步if (bucketStartTimes[currentIndex] != nowBucket)的重置是安全的，不会误删还在窗口内的计数。

关于为什么用synchronized：这个判断和更新的过程是“读多个桶、求和、判断、更新当前桶”，整个过程必须作为一个原子操作。如果多个线程同时读到total未满，然后同时自增，最终实际放行的数量就会超过阈值。用synchronized虽然粗暴，但在限流这个场景下完全够用，因为限流本身就是在请求链路上加一道快速拦截，单次加锁的纳秒级开销和网络请求动辄几毫秒的耗时相比不值一提。

关于为什么用long[]而不是AtomicLong[]：既然已经用了锁，数组元素就是单线程访问的，根本不需要原子类。原子类还会引入额外的CAS开销和对象头内存占用。写代码要区分“并发环境”和“锁内环境”，锁内变量用普通数组反而更清爽。

2.4 平滑限流的延伸：叠加小窗口

滑动窗口能解决边界突刺，但它管的是“窗口内总量”。有些场景还需要另一个维度：在更细粒度的时间片上也要限制流量。比如某活动接口要求“单机每秒最多1000次，且任意100毫秒内不超过200次”。这种需求靠单一窗口实现不了，因为1秒窗口允许的1000个请求可能集中在窗口开头的100毫秒内。

解决方案是用多个不同粒度的限流器叠加，形成一个“二级窗口”结构。一个窗口设1000毫秒、阈值1000，另一个窗口设100毫秒、阈值200，两个限流器都放行才放行，任何一个拒绝就拒绝。

public boolean tryAcquire() { return secondWindow.tryAcquire() && hundredMsWindow.tryAcquire(); }

这个结构的本质是给限流增加一个“短时抖动约束”。我实测下来，光是控制总量的滑动窗口，还不足以应对那种“全部流量集中在极短时间”的极端请求；叠加一个粒度更细的窗口后，尖峰明显被削平了。如果你遇到类似的需求，不需要自己去改算法，组合多窗口就够了。

3. 并发安全、性能优化与参数调优

3.1 并发安全三件套：锁、原子操作、时间片

限流器核心的并发安全点有三个：当前桶计数的累加、窗口总请求数的统计、过期桶的重置。任何一步出现竞态，都会导致限流失效或者误杀。

第二版代码用一把大锁把三个操作串行化，最简单也最正确。但如果你对性能有极致追求，可以分析一下这把锁里最耗时的是什么。遍历所有桶求和是O(K)，当K=10~20时其实很快；耗时更明显的是System.currentTimeMillis()的系统调用。高并发下频繁调用它会有不小的开销，可以用缓存时间戳的类来优化，但代价是时间精度下降，限流的窗口边界会有一两毫秒的误差。

工程上我的建议是：先用简单的锁版本，压测确认真的成为瓶颈了再优化。限流器通常不会是服务的热点。如果确实要优化，可以考虑用ReentrantReadWriteLock，把“统计窗口总数”这个读操作并发化，但要注意写锁需要保证互斥，实现复杂度会高出不少。

3.2 为什么不能用 HashMap 存桶

有人会想，为什么不用HashMap<Long, Long>来存桶，键是时间戳，值是该时间片的计数。第一个问题是哈希碰撞，虽然桶数组不大，但HashMap的扩容、链表、红黑树都要时间。第二个问题是桶的淘汰：你需要额外记录窗口起点，每次前进时找到对应的key删除，HashMap的元素增删会带来GC压力。第三个问题是遍历时不安全：高并发下边遍历边修改会抛ConcurrentModificationException，你依然得加锁。

固定数组为什么好：长度恒定，分配的是一整块连续内存；下标通过模运算直接定位，没有任何哈希寻址的成本；过期桶不需要删除，只需在访问到它时重置；遍历求和时数据都在CPU缓存行里，K个long加起来就是几纳秒的事。这些都是HashMap给不了的。

3.3 关键参数怎么定：窗口长度、桶数、阈值

窗口长度取决于业务容忍度。比如接口要求“1秒内不超过1000次”，窗口长度就是1000毫秒。要求“10秒内不超过5000次”，窗口长度就是10000毫秒。

桶数的选择直接影响平滑度和性能。

桶数太少，滑动窗口就退化成固定窗口，临界突刺问题回来了。桶数太多，单次请求需要遍历求和的次数变多，虽然K=100时也就几百纳秒，但没必要。经验法则：桶数取10到20之间是比较均衡的。对极敏感的场景可以适当加粗，但不建议超过100，除非你有特殊理由。

阈值怎么定：先对单机做压测，找到服务的真实容量上限，然后取这个上限的70%~80%作为限流阈值。留出20%的余量是因为线上流量和压测流量模式不一样，GC暂停、慢SQL、下游抖动都可能导致同样的请求量产生更高的负载。直接拍脑袋取一个数字是最容易出事的。

4. 写一个可直接落地的滑动窗口限流器

4.1 基础配置：从配置中心动态读取

生产环境里，限流参数不太可能一次定死。活动大促时要临时提高阈值，平时要收紧。比较好的做法是把窗口大小、桶数、阈值放到配置中心里，限流器在每次执行时动态读取。注意不要每次都从配置中心拉取远程内容，那样会有网络开销和故障点；应该是配置中心变更时推送到本地缓存，限流器直接读本地值。

一个简单的动态配置载体：

public class RateLimiterConfig { private volatile int maxRequests; private volatile int bucketCount; private volatile long windowSizeMillis; public RateLimiterConfig(int maxRequests, int bucketCount, long windowSizeMillis) { this.maxRequests = maxRequests; this.bucketCount = bucketCount; this.windowSizeMillis = windowSizeMillis; } // getter / setter 省略 }

用volatile保证线程可见性。限流器每次调用tryAcquire时优先读取配置引用，这样参数调整在下次请求时立即生效，不需要重启服务。

4.2 完整限流器实现：支持动态配置和实时统计

把前面的分桶版本升级一下，让它支持动态配置，同时暴露出窗口内的实时请求数，方便监控和排查。

public class DynamicSlidingWindowRateLimiter { private final int bucketCount; // 固定，不建议运行时变化 private volatile RateLimiterConfig config; // 动态阈值和窗口长度 private final long[] buckets; private final long[] bucketStartTimes; private final long bucketSizeMillis; public DynamicSlidingWindowRateLimiter(RateLimiterConfig config) { this.config = config; this.bucketCount = config.getBucketCount(); this.bucketSizeMillis = config.getWindowSizeMillis() / config.getBucketCount(); this.buckets = new long[bucketCount]; this.bucketStartTimes = new long[bucketCount]; Arrays.fill(bucketStartTimes, -1); } public synchronized boolean tryAcquire() { RateLimiterConfig cfg = this.config; long now = System.currentTimeMillis(); long nowBucket = now / bucketSizeMillis; long windowLowerBound = nowBucket - bucketCount + 1; int currentIndex = (int) (nowBucket % bucketCount); long total = 0; for (int i = 0; i < bucketCount; i++) { if (bucketStartTimes[i] >= windowLowerBound) { total += buckets[i]; } } if (bucketStartTimes[currentIndex] != nowBucket) { bucketStartTimes[currentIndex] = nowBucket; buckets[currentIndex] = 0; } if (total >= cfg.getMaxRequests()) { return false; } buckets[currentIndex]++; return true; } public synchronized long currentRequestsInWindow() { long now = System.currentTimeMillis(); long nowBucket = now / bucketSizeMillis; long windowLowerBound = nowBucket - bucketCount + 1; long total = 0; for (int i = 0; i < bucketCount; i++) { if (bucketStartTimes[i] >= windowLowerBound) { total += buckets[i]; } } return total; } }

注意一个细节：bucketSizeMillis用的是创建时的窗口长度除以桶数，所以窗口长度可以动态调整，但是调整时桶的大小不会跟着变。如果你需要动态修改窗口长度，最好连桶数一起重建限流器。我的经验是：窗口长度这种参数很少需要频繁调整，真正频繁调整的是阈值maxRequests，日常大促改这一个参数就够了。

4.3 接入Spring Boot拦截器，三分钟搞定

单机限流器在业务代码里常见的接入方式是用Spring的HandlerInterceptor，在请求进入Controller之前拦截。写一个限流拦截器：

public class RateLimitInterceptor implements HandlerInterceptor { private final DynamicSlidingWindowRateLimiter rateLimiter; public RateLimitInterceptor(DynamicSlidingWindowRateLimiter rateLimiter) { this.rateLimiter = rateLimiter; } @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (rateLimiter.tryAcquire()) { return true; } response.setStatus(429); response.getWriter().write("{\"code\":429,\"message\":\"Too Many Requests\"}"); return false; } }

注册到WebMvcConfigurer：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new RateLimitInterceptor(new DynamicSlidingWindowRateLimiter( new RateLimiterConfig(500, 10, 1000)))) .addPathPatterns("/api/**") .excludePathPatterns("/actuator/**"); } }

如果不想网关所有接口共用一个阈值，可以按接口维度创建多个限流器实例，放在一个Map里，拦截器根据请求路径取对应的实例。注意这个Map本身要用ConcurrentHashMap保证并发安全，并且实例的创建要控制好生命周期，别在请求路径上每次new一个。

4.4 压测与效果对比

我用单机4核8G的配置，用JMeter模拟并发请求做了一个对比测试。场景是限制每秒500个请求，用100线程持续灌入流量。

固定窗口限流器的表现：在窗口切换的瞬间，瞬时放行量可以冲到800甚至1000，因为临界前后两个窗口的配额被同时耗尽。滑动窗口限流器（10个桶）的表现：瞬时放行量最大值稳定在530以内，虽然因为线程并发和统计时机存在少量超调，但相比固定窗口有了质的改善。

这里有个值得说的点：滑动窗口限流允许非常小的超调。因为请求瞬间多个线程同时通过检查并自增，在synchronized锁内顺序执行时，确实能保证严格不超过阈值。但这个测试里的超调，我后来排查发现是JMeter统计口径和限流器内部状态之间存在时间差，实际上限流器内部放行量是严格的。这个时间差告诉我们，压测观察到的“瞬时QPS”和限流器统计的“窗口请求量”不是同一个概念。

5. 常见问题与工程避坑记录

5.1 时间边界条件与并发竞态

高并发下最经典的坑是：多个线程在同一个毫秒到达，落到同一个桶里。这个没问提，因为synchronized保证了它们串行执行，桶计数会正确累加。容易出问题的是系统时间毫秒级波动导致桶序号反复横跳。

比如某个请求的now / bucketSizeMillis计算出100，累加到桶100；下一个请求因为时间戳回退，计算出99，那么它在求total时看到的窗口下界可能就不连续。这种波动很小的时候不必担心；如果波动较大，会导致同一个窗口的请求被错误地分到两个桶里。

5.2 系统时钟回拨的噩梦

单机限流器本质上依赖系统时间，一旦系统时钟发生回拨，窗口就会出现逻辑错乱。比如说当前桶序号是100，下一个请求因为时钟拨回去，变成了95。95对应的数组下标和100不同，它可能清零了一个本该属于窗口内的时间片，导致限流被绕过，也可能把窗口起点拖后，导致短时间内大量请求被放行。

线上常见的是NTP校时导致的轻微回拨，比如几十毫秒。这种级别基本不会触发明显异常，因为限流器窗口至少是几百毫秒。真正要防御的是人为改时间或者极端情况下的校时，偏差可能达到数秒。一个简单的防御是在代码里记录上一次的桶序号，发现当前桶序号变小且小于windowLowerBound时，直接拒绝请求或重置整个窗口。

public synchronized boolean tryAcquire() { long now = System.currentTimeMillis(); long nowBucket = now / bucketSizeMillis; if (nowBucket < lastBucket) { // 时间回拨超过一个桶，直接按拒绝处理，等待下一个正常时间片 return false; } // 后续逻辑 }

5.3 长窗口下的遍历开销与优化

当窗口长度拉长到10秒、桶数设为100时，每个请求进来都要遍历100个桶求和。虽然单次只有几百纳秒，但如果你的限流器被调到请求链路上非常前置的位置，每一微秒都值得优化。

优化方案是维护一个total变量，窗口每次滑过过期桶时，从total里减掉过期桶的计数，这样统计总数的时间从O(K)变成O(1)。代价是逻辑变复杂，因为你需要精确追踪窗口滑过了几个桶。

public synchronized boolean tryAcquire() { long now = System.currentTimeMillis(); long nowBucket = now / bucketSizeMillis; long windowLowerBound = nowBucket - bucketCount + 1; int currentIndex = (int) (nowBucket % bucketCount); // 推进窗口，把滑出边界的桶从 total 中扣掉 while (headBucket < windowLowerBound) { total -= buckets[headIndex]; buckets[headIndex] = 0; headIndex = (headIndex + 1) % bucketCount; headBucket++; } if (bucketStartTimes[currentIndex] != nowBucket) { bucketStartTimes[currentIndex] = nowBucket; buckets[currentIndex] = 0; } if (total >= config.getMaxRequests()) { return false; } if (bucketStartTimes[currentIndex] != nowBucket) { bucketStartTimes[currentIndex] = nowBucket; } buckets[currentIndex]++; total++; return true; }

这种优化版我在项目里也用过，确实性能更好，但代码里有好几个关联变量（headBucket、headIndex、total），稍不留神就会写错。对于大多数业务场景，K=20以内的遍历足够快了，不要为了省这点时间把正确性搞复杂。只有你确认限流器在热路径上且桶数很多时，再上这个优化。

5.4 单机限流的边界与多实例问题

最后必须说清楚单机限流的边界。单机限流器只能保证“一个进程内”的请求不超过阈值，它管不了多实例部署下的全局总量。假设你部署了4个实例，每个限500，那么全局总量最高可以到2000。如果你的系统设计依赖全局2000这个上限，单机限流是给不了这个保证的。这时候需要引入分布式限流，或者把阈值按实例数做预算分配，但要注意线上流量不一定均匀分布，保守一点的方案是给每台实例留出冗余量。

我实际项目里的做法是：分布式限流管总量，单机限流管自我保护。两层都配，缺一不可。

至于要不要把单机限流做成可插拔的注解，看团队规范。有的团队喜欢@RateLimit注解直接标在Controller方法上，由AOP切面统一处理。这种方案可读性好，但要注意AOP切面的执行时机在拦截器之后，如果你的拦截器已经做了限流，AOP里的限流器可以只针对个别方法做更细粒度的控制，两者不冲突。

在实际操作中还有一个小点：限流后的响应设计。直接返回429状态码是最标准的做法，但很多调用方对这个状态码不熟悉，会误认为请求失败重试，反而加重系统负担。比较好的做法是返回一个明确的业务错误码，比如{"code":42901,"message":"系统繁忙，请稍后再试"}，同时在响应头里带上Retry-After，告诉调用方多久之后再试。

我在生产上跑这个滑动窗口限流器已经很久了。最大的体会是：限流器的代码本身不难，难的是对边界条件的理解和参数的调优。网上很多文章只贴一个实现就完事，但真正放到高并发环境里，时钟回拨、桶复用安全、并发原子性、动态配置、压测调参，这些才是决定它能不能稳定运行的关键。希望这篇文章能把那层窗户纸捅破，让你在需要限流的时候，不必再重复踩我踩过的坑。