Sleeping at JVM Thread for a Very Short Period

This article explains why it is not possible to make a 1 nanosecond sleep in JVM. Instead, you may achieve an unguaranteed small pause which depends on the number of active threads.

Available options

The JVM offers various techniques to pause or delay a thread for a specified duration:

• Thread.yield();
• Thread.sleep(long millis) and Thread.sleep(long millis, int nanos);
• Thread.onSpinWait() since Java 9;
• Object.wait(long timeout) and Object.wait​(long timeout, int nanos);
• TimeUnit.sleep​(long timeout);
• LockSupport.parkNanos(long nanos).

After reviewing the implementation of all methods in the available code of OpenJDK 9, this list can be simplified:

• Object.wait​(0, x) is Object.wait(1);
• Thread.sleep(0, x) is Thread.sleep(0) when x less than 500,000 and Thread.sleep(1) otherwise;
• TimeUnit.sleep​(long timeout) is simple calling Thread.sleep(long millis, int nanos).

Benchmarking

The benchmark was run on an Apple laptop:

and a server running Debian Sid:

The anomalous behavior of LockSupport.parkNanos(1) requires further investigation with varying values.

It is evident that LockSupport.parkNanos(1) is highly unpredictable and dependent on the platform used. The only guarantee is that a larger value will result in a longer pause.

Benchmark Results

To summarize the benchmark results:

• Thread.onSpinWait() exists since Java 9 and takes only a few nanoseconds;
• Thread.yield() is faster than Thread.sleep(0) by approximately 13%, but it still takes a few hundred nanoseconds;
• Object.wait(0, 1) results in approximately 1 millisecond of sleep;
• LockSupport.parkNanos(x) has unpredictable behavior.

Based on these results, it can be concluded that the JVM cannot guarantee small pauses. There are two options available, but both of them depend on the machine and/or platform:

• either a small constant value such as Thread.onSpinWait(), Thread.yield(), or Thread.sleep(0);
• or to suggest a pause, by LockSupport.parkNanos(x), but keep in mind that its behavior cannot be guaranteed.

Multithreaded environment

I analyzed the benchmark in a clean environment with only one thread. However, the benchmark can be run with a desired number of concurrent threads. The log of the multithreaded benchmark was run on Debian on an Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz.

This demonstrates that the pause time depends on the number of active threads:

• Thread.onSpinWait() causes a pause of 2.5 nanoseconds for 1 thread, 22.3 nanoseconds for 64 threads, and 72 nanoseconds for 256 threads;
• on the other hand, Thread.yield() causes a pause of 170 nanoseconds for 1 thread, approximately 8 microseconds for 64 threads, and 35 microseconds for 256 threads;
• and finally, the relation between Thread.sleep(0) and Thread.yield() holds the assumption.

Is it possible to predict? No. According to the documentation, Thread.activeCount() returns an estimated number of active threads, and the returned value may change dynamically while the method traverses internal structures. This means that it is seemingly impossible to compute in advance the number of required Thread.onSpinWait() or Thread.yield() calls to achieve the desired pause.

Conclusion

The JVM cannot guarantee sleep for very short periods of time.

The best available option is Thread.onSpinWait(), which was introduced in Java 9. It compiles into a CPU instruction similar to PAUSE if the target CPU supports it, and into nothing if it doesn’t. When it’s supported, the resulting pause depends on the number of active threads, but it is on the dozen-nanoseconds scale.

The second usable option is Thread.yield(), which works like a hint to the scheduler that this thread should be skipped. It may ignore or follow the instruction. Doing so requires context switching, which can take microseconds in real-life applications.