What is the advantage of using a library like Guava RateLimiter over simple Thread.sleep?

Question

Assuming all I want to do is call a service at a particular rate, say 1 per second, what advantages does Guava RateLimiter offer over simple Thread.sleep(1000) ?

Answer 1

The point of RateLimiter is you make it part of the service (or wrap the service) being called, so it can protect itself from being called too frequently. Your Thread#sleep alternative would have to be used by the client of the service, so you're comparing two different things.

Here's a good article on what you can do with RateLimiter.

Answer 2

The difference is latency.

The simplest approach of calling Thread.sleep(1s) every request would then slow every request down by at least 1s..

The Guava rate limiter will check how many requests have been seen before deciding to block. Thus many calls may get through with relatively no latency.

Of course, a smarter implementation can be written than the naive approach that blocks every request using Thread.sleep. However at that point, one would be re-inventing the Guava approach.

Answer 3

Use RateLimiter since it fits your use case of limiting access to a service exactly. Except from the JavaDoc:

Rate limiters are often used to restrict the rate at which some physical or logical resource is accessed.

Of course, you could use Thread.sleep instead, but you either have to program the functionality that tracks when your service was last called yourself, or you have to block every execution of your service indiscriminately (possibly blocking unnecessarily on first or last execution).

Answer 4

I'm not a RateLimiter expert, but here's a few points I'd like to make anyway:

1. One of the main benefits of RateLimiter is its ability to control the rate of requests when requests are being made (or coming in) from multiple places, typically on multiple threads.
2. If you're making all the calls to this service sequentially on a single thread, RateLimiter probably isn't necessary... that's a much simpler case than it's designed for.
3. Still, (as others have mentioned) it's going to do a better job at accurately limiting you to one request per second than Thread.sleep(1000) will, since that sleep isn't taking into account the time it takes to do any work that's done when making the request.
4. It's unclear to me whether you're actually trying to rate limit your calls to the service or if what you actually want is a scheduled task that happens once per second. If it's the latter, something like ScheduledExecutorService or ListeningScheduledExecutorService might be preferable.