先判断是否能在指定超时时间内获取到令牌，通过 nextFreeTicketMicros <= timeoutMicros + nowMicros 是否为true来判断，即可取令牌时间早于当前时间加超时时间则可取（预消费的特性），否则不可获取。
如果不可获取，立即返回false。
如果可获取，则调用 reserveAndGetWaitLength(permits, nowMicros) 来更新下次可取令牌时间点与当前存储的令牌数，返回等待时间（逻辑与前面相同），并阻塞等待相应的时间，返回true。
源码如下所示
public boolean tryAcquire(int permits, long timeout, TimeUnit unit) { long timeoutMicros = max(unit.toMicros(timeout), 0); checkPermits(permits); long microsToWait; synchronized (mutex()) { long nowMicros = stopwatch.readMicros(); if (!canAcquire(nowMicros, timeoutMicros)) { //判断是否能在超时时间内获取指定数量的令牌 return false; } else { microsToWait = reserveAndGetWaitLength(permits, nowMicros); } } stopwatch.sleepMicrosUninterruptibly(microsToWait); return true; } private boolean canAcquire(long nowMicros, long timeoutMicros) { return queryEarliestAvailable(nowMicros) - timeoutMicros <= nowMicros; //只要可取时间小于当前时间+超时时间，则可获取（可预消费的特性！） } @Override final long queryEarliestAvailable(long nowMicros) { return nextFreeTicketMicros; }以上就是 SmoothBursty 实现的基本处理流程。注意两点：
RateLimiter 通过限制后面请求的等待时间，来支持一定程度的突发请求——预消费的特性。
RateLimiter 令牌桶的实现并不是起一个线程不断往桶里放令牌，而是以一种延迟计算的方式（参考resync函数），在每次获取令牌之前计算该段时间内可以产生多少令牌，将产生的令牌加入令牌桶中并更新数据来实现，比起一个线程来不断往桶里放令牌高效得多。（想想如果需要针对每个用户限制某个接口的访问，则针对每个用户都得创建一个RateLimiter，并起一个线程来控制令牌存放的话，如果在线用户数有几十上百万，起线程来控制是一件多么恐怖的事情）
总结本文介绍了限流的三种基本算法，其中令牌桶算法与漏桶算法主要用来限制请求处理的速度，可将其归为限速，计数器算法则是用来限制一个时间窗口内请求处理的数量，可将其归为限量（对速度不限制）。Guava 的 RateLimiter 是令牌桶算法的一种实现，但 RateLimiter 只适用于单机应用，在分布式环境下就不适用了。虽然已有一些开源项目可用于分布式环境下的限流管理，如阿里的Sentinel，但对于小型项目来说，引入Sentinel可能显得有点过重，但限流的需求在小型项目中也是存在的，下一篇文章就介绍下基于 RateLimiter 的分布式下的限流实现。
[转载请注明出处]
作者：雨歌
欢迎关注作者公众号：半路雨歌，查看更多技术干货文章