Thread.sleep() VS Executor.scheduleWithFixedDelay()

rudgirello picture rudgirello · Nov 16, 2012 · Viewed 14.2k times · Source

Goal: Execute certain code every once in a while.

Question: In terms of performance, is there a significant difference between:

while(true) {
    execute();
    Thread.sleep(10 * 1000);
}

and

executor.scheduleWithFixedDelay(runnableWithoutSleep, 0, 10, TimeUnit.SECONDS);

?

Of course, the latter option is more kosher. Yet, I would like to know whether I should embark on an adventure called "Spend a few days refactoring legacy code to say goodbye to Thread.sleep()".

Update: This code runs in super/mega/hyper high-load environment.

Answer

Steven Schlansker picture Steven Schlansker · Nov 16, 2012

You're dealing with sleep times termed in tens of seconds. The possible savings by changing your sleep option here is likely nanoseconds or microseconds.

I'd prefer the latter style every time, but if you have the former and it's going to cost you a lot to change it, "improving performance" isn't a particularly good justification.

EDIT re: 8000 threads

8000 threads is an awful lot; I might move to the scheduled executor just so that you can control the amount of load put on your system. Your point about varying wakeup times is something to be aware of, although I would argue that the bigger risk is a stampede of threads all sleeping and then waking in close succession and competing for all the system resources.

I would spend the time to throw these all in a fixed thread pool scheduled executor. Only have as many running concurrently as you have available of the most limited resource (for example, # cores, or # IO paths) plus a few to pick up any slop. This will give you good throughput at the expense of latency.

With the Thread.sleep() method it will be very hard to control what is going on, and you will likely lose out on both throughput and latency.

If you need more detailed advice, you'll probably have to describe what you're trying to do in more detail.