A {@code RateLimiter} is defined primarily by the rate at which permitsare issued. Absent additional configuration, permits will be distributed at a fixed rate, defined in terms of permits per second. Permits will be distributed smoothly, with the delay between individual permits being adjusted to ensure that the configured rate is maintained.
It is possible to configure a {@code RateLimiter} to have a warmupperiod during which time the permits issued each second steadily increases until it hits the stable rate.
As an example, imagine that we have a list of tasks to execute, but we don't want to submit more than 2 per second:
{@code final RateLimiter rateLimiter = RateLimiter.create(2.0); // rate is "2 permits per second"}void submitTasks(List tasks, Executor executor) for (Runnable task : tasks) { rateLimiter.acquire(); // may wait executor.execute(task); } } } As another example, imagine that we produce a stream of data, and we want to cap it at 5kb per second. This could be accomplished by requiring a permit per byte, and specifying a rate of 5000 permits per second:
{@code final RateLimiter rateLimiter = RateLimiter.create(5000.0); // rate = 5000 permits per second}void submitPacket(byte[] packet) rateLimiter.acquire(packet.length); networkService.send(packet); } } It is important to note that the number of permits requested never affect the throttling of the request itself (an invocation to {@code acquire(1)}and an invocation to {@code acquire(1000)} will result in exactly the same throttling, if any),but it affects the throttling of the next request. I.e., if an expensive task arrives at an idle RateLimiter, it will be granted immediately, but it is the next request that will experience extra throttling, thus paying for the cost of the expensive task.
Note: {@code RateLimiter} does not provide fairness guarantees. @author Dimitris Andreou @since 13.0
| |
| |